This chapter provides the following topics describing management of Token Service Partners and Partner Profiles:
"Introduction to Oracle Security Token Service"
Chapter 17, "Oracle Security Token Service Implementation Scenarios"
Any task you can perform using the Oracle Access Manager Console can also be performed using the
See Also:
Oracle Fusion Middleware WebLogic Scripting Tool Command Reference
This section provides the following topics:
A Token Service partner represents a partner trusted by the STS Server. There are three types of partners:
Requester, which represents a Web Service Client interacting directly with Oracle Security Token Service in order to issue or validate tokens
Relying Party, which references a Web Service Provider that will be the recipient of tokens issued by the Oracle Security Token Service server.
Issuing Authority, which represents an Assertion issuer. When validating an Assertion, its issuer must be a known Issuing Authority Partner entry in Oracle Security Token Service.
The Security Token Service is capable of interacting with two types of clients:
Web Service Client modules, defined as requester partners in Oracle Security Token Service (typically SOAP clients)
End users, not defined as requester partners, but possibly present in the User Identity Store.
A Partner Profile contains configuration properties that are common to a set of partners, and each partner entry is associated to a Partner Profile. Similar to the partners, there are three types of partner profiles: Requester, Relying Party and Issuing Authority Partner Profiles.
A partner entry will contain the following information:
Signing and Encryption Certificates
Partner name, unique identifier and description
Reference to a Partner Profile
For Requester, also contains Username Token credentials, and Identification strings used to map incoming data to a requester.
A partner profile entry will contain the following information, depending on the type of profile:
Requester
Claims Mappings
WS-Trust Validation Templates used to validate tokens present in the OnBehalfOf element
Relying Party
Attributes to be sent to RP
Issuance Templates to be used
Issuing Authority
Attribute Name/Value Mapping settings
Specific Mapping Actions Rules used to map an incoming token to a partner/user
This section provides the following topics.
When you choose to create a new partner, a fresh page appears for the specific Partner Type you selected. Figure 21-1 shows the New Requester partner page in the Oracle Access Manager Console, which includes all Partner elements.
While most elements are common to all partners (name, description, and whether this partner is trusted), certain elements depend upon the specific partner type. For instance:
Requester partners: Can specify an encryption certificate and a signing certificate.
Relying Party partners: Can specify only an encryption certificate
Issuing Authority partners: Can specify only a signing certificate
Table 21-1 describes elements for Oracle Security Token Service partners. Unless explicitly stated otherwise, all elements apply to every partner type.
Table 21-1 Elements for Oracle Security Token Service Partners
Element | Description |
---|---|
Partner Name |
Enter a name for this partner. |
Partner Type |
Uneditable description, depending upon the type of partner you are creating or editing:
|
Partner Profile |
Choose from those listed for your chosen partner type. |
Description |
Optional. |
Trusted |
Check this box to indicate whether or not the partner is trusted. If not checked, the Oracle Security Token Service server will report an error when a request involves such an entry. |
Load Certificate |
Browse for and upload the requested certificates, which depend on partner type:
|
Username Token Authentication Requester only |
Values can be entered for the following for Username Token Authentication:
New Requester Partner Identification Attributes can be defined in the STS Settings section and will appear in the requester partner Identity Attributes table. Note: the username and password data will be used to validate the credentials of a username token. It is also possible to only enter a username and no password, when the data will be used only to map an incoming token to this requester partner using the username. |
Identity Attributes Requester only |
At runtime, Oracle Security Token Service will use the data defined in the section to map an incoming request to a requester partner entry, using:
New mappings can be added in the Relying Party Partner section as follows: http://relying.party.test.com/testing.service. At runtime, the Oracle Security Token Service server will use those URLs to map the AppliesTo service location contained in a WS-Trust request to a Relying Party Partner. |
Resource URL Relying Party only |
Enter the resource URL in the resource pattern column of the table, and enter a description beside it. For instance: Pattern: http://relying.party.test.com/testing/service The resource URL listed in the table will be used when mapping the AppliesTo location element from the WS-Trust request to this Relying Party Partner. The AppliesTo location value will be mapped to this Relying Party Partner:
|
Figure 21-2 shows a Requester Partner page that is filled in.
Users with valid Administrator credentials can use the following procedure to create, find, edit, or delete a token service partner using Oracle Access Manager Console.
A partner profile of the type of partner that will be created needs to be exist.
To manage a token service partner
From the Oracle Access Manager Console, open the:
Under the Partners node, double-click the desired partner type and proceed with following steps as needed.
Requesters
Relying Parties
Issuing Authorities
New Partner:
Click the New PartnerType button to display a fresh page for your definition.
Enter general information for the chosen partner type (Table 21-1).
Trusted: Click to select (or leave blank if this is not a trusted partner).
Certificates: Load any necessary certificates.
Relying Party: Enter Resource URLs, if needed.
Requester: Enter Username Token credentials, if needed.
Click Save to submit (or click Cancel to dismiss the page) and then dismiss the confirmation window.
Refine a Partner Search: "Refining Partner Searches"
Perform Steps 1 and 2.
Define your query and click the Search button.
In the Search Results table, click the name of partner to view, edit, or remove.
Edit a Partner:
In the Search Results table, click the name of partner to edit and click the Edit button (or choose Edit from the Actions menu).
Make desired changes to partner information (Table 21-1).
Click Apply to submit the changes (or Revert to cancel changes) and then dismiss the confirmation window.
Remove a Partner: Use the Search controls to refine and submit your query, as needed.
In the Search Results table, highlight the row containing the partner to remove.
Click the Delete (X) button (or choose Delete Selected from the Actions menu), then dismiss the confirmation window.
As with other System Configuration components, when you open the Partner node, all Partner type nodes become available. When you choose a specific Partner node, relevant Search controls, and the Search Results table, become available.
Figure 21-3 illustrates a Requester Partner, where only the results differ from that of other Partner Types.
From the Search page you can simply select a name in the Search Results table, or use the controls to refine your search to locate a specific Partner or Partners with specific characteristics.
This section provides information about Token Service Partner Profiles.
Figure 21-4 shows a completed Requester Profile page, with both a General tab and Token and Attributes tab.
Table 21-2 describes the General elements for all profile types.
Element | Description |
---|---|
Profile ID |
A unique identifier for this profile |
Description |
Optional. |
Profile Type |
Type of profile, which cannot be edited: Requester, Relying Party or Issuing Authority. |
Default Relying Party Profile Requester Partner Profile Only |
References the Relying Partner Profile to use, if the WS-Trust request does not reference the Relying Party (for example, the AppliesTo element is missing), or if the AppliesTo element could not be mapped to a known Relying Party Partner Profile. Choose a Relying Party profile to use as the default and enable or disable the following characteristics as needed:
|
Default Token to Issue Relying Party Only |
This table indicates which Issuance Template to use to issue a token for Relying Parties linked to this profile. Choose a token type as the default for this profile:
Check the box beside Download Policy to associate a policy with the token. When checked, Oracle Security Token Service will download at runtime the WS-Security policy of the Relying Party referenced by the AppliesTo element in the RST. If present, Oracle Security Token Service will use that URL to download the policy, and then determine the type of token to return based on the information located in the policy. |
Requester Profile: Token and Attributes
Figure 21-5 illustrates the Token and Attributes tab and accompanying tables for the Requester profile. The Token Type Configuration section indicates which WS-Trust Validation Template to use to validate tokens contained in the OnBelhalfOf element of the WS-Trust request, based on the token type. This section defines mappings between WS-Trust claims requested by the client and local attribute names
Figure 21-5 Requester Profile: Token and Attributes
Table 21-3 describes Requester Profile Token and Attributes elements and controls.
Table 21-3 Requester Profile: Token and Attributes
Element | Description |
---|---|
Token Type Configuration |
Click the + above the table to display the following dialog box and then make one selection from each list: ![]() Token Type list provides all supported (and custom) token types deployed. Validation Template list contains all currently defined WS-Trust validation templates. |
Attribute Name Mapping |
This table defines how OSTS will map a claim, represented by its name and optional Format/Namespace, to a local attribute. Oracle Security Token Service supports the Infocard Claims dialect. To translate Infocard claims to local attributes, a mapping will need to be defined where the Incoming Attribute will contain the claim name and the Local Attribute will contain the local name (The Format/Namespace column will be empty). For example, one mapping could be:
Another mapping could be:
Another mapping could be:
|
Relying Party Profile: Token and Attributes
Figure 21-6 illustrates the Token and Attributes defined for a Relying Party Profile. This section allows the administrator to define which Issuance Template should be used to issue a token for a Relying Party associated with this profile.
Also, it lists the attributes that might be included in an issued token, by their names, the source of those attributes, and whether or not the attributes should be included in the issued token only if requested by the client or always.
On this page, Relying Party Profiles require an Issuance Template in addition to the token type. Also, the attribute types differ from other profiles.
Figure 21-6 Relying Party Profile Token and Attributes
Table 21-4 describes the elements needed for the Relying Party Profile.
Table 21-4 Relying Party Profile Requirements
Element | Descrip[tion |
---|---|
Token Type Configuration |
Click the + above the table to display the following dialog box and then make one selection from each list: ![]() Token Type list provides all supported (and custom) token types deployed. Issuance Template list contains all currently defined Issuance Templates. |
Attributes |
The attributes that might be included in an issued token:
See Also: "Relying Party Profile Attributes". |
Relying Party Profile Attributes
When defining an attribute, you can indicate:
The attribute source: User Store (LDAP), Incoming Token Data or static value.
Whether or not to include the attribute in the token only if requested by the client or in all tokens.
Whether or not to encrypt the attribute (only SAML 2.0; requires the Relying Party Encryption Certificate).
The value of the attribute if this is a static attribute.
Example: To include the mail attribute retrieved from LDAP in all outgoing tokens:
Attribute Name: mail
Store Type: User Store
Include in Token: checked
Encrypt: unchecked
Value: empty
Example: To include the username element of an incoming Username Token in all outgoing tokens
Attribute Name: STS_SUBJECT_ID
Store Type: Incoming Token
Include in Token: checked
Encrypt: unchecked
Value: empty
Example: To include a static attribute in all outgoing tokens:
Attribute Name: rp-version
Store Type: Static
Include in Token: checked
Encrypt: unchecked
Value: 2.0
The following attributes are available from the incoming token data. The SAML attributes referenced by their names are also available as incoming token data:
Contains the subject identifier (username for Username token, NameID Value for SAML assertions, Subject DN for X.509 certificates)
Contains the SAML NameID Format.
Contains the SAML NameID Format.
Contains the SAML NameID Qualifier.
Contains the SAML NameID SP Qualifier
Contains the session index.
Contains the authentication instant (current after Username token credentials validation, from the authentication statement for SAML Assertions, current for X.509 validation, current for Kerberos Validation, authentication instant for OAM Session Propagation tokens).
Contains the session expiration time if set (applies to SAML assertions and OAM Session Propagation tokens if present).
Contains the CN component of the X.509 Certificate's Subject DN
Contains the OU component of the X.509 Certificate's Subject DN.
Contains the O component of the X.509 Certificate's Subject DN.
Contains the L component of the X.509 Certificate's Subject DN.
Contains the ST component of the X.509 Certificate's Subject DN.
Contains the C component of the X.509 Certificate's Subject DN.
Contains the DC component of the X.509 Certificate's Subject DN.
Contains the component identified by * of the X.509 Certificate's Subject DN.
Contains the version attribute of the X.509 Certificate.
Contains the issuer DN of the X.509 Certificate.
Contains the not after attribute of the X.509 Certificate.
Contains the not before attribute of the X.509 Certificate.
Contains the subject DN of the X.509 Certificate.
Contains the subject alternative name extension value of the X.509 Certificate.
Contains the serial number of the X.509 Certificate.
Contains the last access time of the OAM Session Propagation Token.
Contains the last update time of the OAM Session Propagation Token.
Contains the creation time of the OAM Session Propagation Token.
Contains the Principal Short value of the Kerberos Token.
Contains the Principal Full value of the Kerberos Token.
Contains the Principal No Domain value of the Kerberos Token.
Contains the AssertionID of the SAML Assertion.
Contains the Subject DNS attribute of the SAML Assertion.
Contains the Subject IP Address attribute of the SAML Assertion.
Contains the Issuer of the SAML Assertion.
Contains the authentication instant of the SAML Assertion.
Contains the authentication method of the SAML Assertion.
Issuing Authority Profile: Token and Attributes
The Issuing Authority Partner Profile defines settings that can be common to different Issuing Authority Partners.
The Token and Attributes section, as shown in Figure 21-7, allows the administrator to define mapping rules that will be used to translate the name and value of attributes to local names and values.
Figure 21-7 Token and Attributes: Issuing Authority
Table 21-5 describes the Token and Attributes elements for Issuing Authority. It is possible to define attribute mapping rules that will be applied to the attributes included in the Assertion, when extracting them from the token. There are two different sets of rules:
Attribute name mapping where the name of a SAML Attribute can be translated to a local name (for example, firstname could be translated to givenname).
Attribute value mapping where the value of a SAML Attribute can be translated to a local value (for example, President to CEO).
Table 21-5 Token and Attributes Elements: Issuing Authority
Element | Description |
---|---|
Attribute Name Mapping |
Define an optional mapping between the name of a SAML Attribute and the local name of an attribute. The mapping is optional. If an attribute does not have a mapping defined, then its SAML attribute name will be used.
|
Value Mapping |
Define an optional value mapping for a SAML attribute. This will indicate how to translate an attribute value to a local value, if needed. Note: This attribute value mapping applies to an Attribute Name mapping. In order to define an attribute mapping for an attribute, it is required to first define an attribute name mapping for that attribute.
|
Issuing Authority Profile: Token Mapping
Using the Token Mapping tab, shown in Figure 21-8, Administrators can override the Mapping Rules defined in a SAML Validation Template with the ones defined in an Issuing Authority Partner Profile. This way, Oracle Security Token Service can map SAML Assertions based on rules specific to a set of Assertion Issuers.Table 21-5 describes the Token Mapping elements for the Issuing Authority.
Table 21-6 Issuing Authority Token Mapping Elements
Element | Description |
---|---|
Override Token Mapping |
Indicates whether or not the Mapping Rules defined in this section should override the ones listed in the SAML Validation Template used to process the assertion. This allows OSTS to use Mapping Rules that are specific to the Assertion Issuer. If true, all the Mapping Rules will be overridden by the settings listed in this section. |
Override Simple User Mapping |
Simple user mapping consists of mapping the incoming token to a user record by using a single token attribute and matching it against a single user record attribute.
|
Override User Name Identifier Mapping |
When enabled, define a NameID user mapping operation, which consists of mapping the incoming SAML Assertion to a user record by mapping the NameID Value to a single user record attribute, based on the NameID format. When enabled, Oracle Security Token Service will evaluate the NameID format, and based on the Name Identifier mapping table which user record attribute should be matched against the Name ID value contained in the Assertion. The Name Identifier mapping table holds the user record attributes to be used for the mapping operation. It contains standard NameID formats, but it can be customized to define custom Name ID formats.
|
Override Attribute Based User Mapping |
An Attribute Based User Mapping operation consists of mapping the incoming token to a user record by using an LDAP query and token attributes. The format of the LDAP query defines the mapping rule and specifies the token attributes to be used by their names, surrounded by % character. For example, an LDAP query that will map a token based on two token attributes (firstname and lastname) would be: (&(sn=%lastname)(givenname=%firstname%)) STS_SUBJECT_ID contains the NameID Value. STS_NAMEID_FORMAT contains the NameID Format STS_NAMEID_QUALIFIER contains the NameID Qualifier STS_SAML_ASSERTION_ISSUER contains the Issuer of the Assertion Attributes present in the Assertion's AttributeStatement |
Override Simple Partner Mapping |
A simple partner mapping operation consists of mapping the incoming token to a partner requester by using a single token attribute and matching it against a partner identification attributes.
|
Override Partner Name Identifier Mapping |
When enabled, define the following: A NameID user mapping operation consists of mapping the incoming SAML Assertion to a user record by mapping the NameID Value to a single requester partner identification attribute, based on the NameID format. When enabled, OSTS will evaluate the NameID format, and based on the Name Identifier mapping table which partner identification attribute should be matched against the Name ID value contained in the Assertion. The Name Identifier mapping table holds the requester partner identification attributes to be used for the mapping operation. It contains standard NameID formats, but it can be customized to define custom Name ID formats.
|
Users with valid Administrator credentials can use this procedure to create, locate, view, edit, or remove a token service partner profile.
The prerequisites for Requester Partner Profiles are:
A Relying Party Partner Profile must exist, in order to be able to set the default Relying Partner Profile.
WS-Trust Validation Templates must exist in order to set the templates that will be used to validate tokens located in the OnBehalfOf element.
The prerequisites for Relying Partner Profiles are:
Issuance Template must exist in order to configure which templates to use for token issuance operations.
There are no prerequisites for Issuing Authority Partner Profiles.
To create, find, edit, or remove a partner profile
From the Oracle Access Manager Console, open the:
Under the Partner Profiles node, double-click the desired profile type and proceed with following steps as needed.
Requester Profiles
Relying Party Profiles
Issuing Authority Profiles
New Profile:
Click the New ProfileType button to display a fresh page for your definition.
Enter general information for the chosen profile type (Table 21-2) and click the Next Button.
Token and Attributes: Use the appropriate table to provide details for the chosen profile type:
Requester Profile Table 21-3
Relying Party Profile Table 21-4
Issuing Authority Profile Table 21-5
Click Save to submit (or click Cancel to dismiss the page) and then dismiss the confirmation window.
Refine a Profile Search: "Refining a Profile Search"
Perform Steps 1 and 2.
Define your query and click the Search button.
In the Search Results table, click the name of partner to view, edit, or remove.
Edit a Profile:
In the Search Results table, click the name of profile to edit and click the Edit button (or choose Edit from the Actions menu).
Make desired changes to partner information.
Requester Profile Table 21-3
Relying Party Profile Table 21-4
Issuing Authority Profile Table 21-5
Click Apply to submit the changes (or Revert to cancel changes) and then dismiss the confirmation window.
Remove a Profile: To remove a profile, it is required not to be referenced anywhere else.
To remove a Requester Partner Profile, it is required that:
No Requester Partner references the profile.
No WS-Security Validation Template references the profile
To remove a Relying Party Partner Profile, it is required that:
No Relying Party Partner references the profile.
No Requester Partner Profile references the profile.
To remove an Issuing Authority Partner Profile, it is required that:
No Issuing Authority Partner references the profile
If these prerequisites are met, proceed as follows:
In the Search Results table, highlight the row containing the profile to remove.
Click the Delete (X) button (or choose Delete Selected from the Actions menu), then dismiss the confirmation window.
As with Partner definitions, when you open the Partner Profiles node, all Partner Profiles nodes become available. When you choose a specific type of Partner Profile node, relevant Search controls, and the Search Results table, become available.
Figure 21-3 illustrates a typical Search Profiles page. This one is for a Requester Profile. However, all controls are the same; only the results differ for different profile types.
Figure 21-9 Search Profiles Page: Requester
From the Search page you can simply select a name in the Search Results table to view or edit the Profile, or use the controls to refine your search to locate a specific Profile or a Profile with specific characteristics.