46.4 Managing Token Service Partner Profiles

The following topics describe Token Service Partner Profiles.

46.4.1 About Managing Partner Profiles

The following topics describe elements in the following pages:

46.4.1.1 Requester Profile: General

The Requester Profile page has the General tab that contains General elements for all profile types.

Figure 46-4 shows a completed Requester Profile page, with both a General tab and Token and Attributes tab.

Figure 46-4 Requester Profile: General

Description of Figure 46-4 follows
Description of "Figure 46-4 Requester Profile: General"

Table 46-7 describes the General elements for all profile types.

Table 46-7 Profile: General

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:

  • Return error for missing claims.

    Indicates whether or not Security Token Service will return an error if the issued token does not contain claims that were requested by the client.

    Since the Relying Party Partner Profile defines the list of attributes/claims that can be included in the issued token, it is possible that some claims requested by the client cannot be returned.

  • Allow unmapped claims.

    Claims listed in a WS-Trust request are specified in a dialect that will be translated to map to local attributes using the Token and Attributes section.

    This flag indicates whether or not claims that cannot be translated should be referenced as is. This allows to control which claims can be requested by the client.

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:

  • SAML 1.1

  • SAML 2.0

  • Username

  • Custom

Check the box beside Download Policy to associate a policy with the token. When checked, 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, 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.

46.4.1.2 Requester Profile: Token and Attributes

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 46-5 illustrates the Token and Attributes tab and accompanying tables for the Requester profile.

Figure 46-5 Requester Profile: Token and Attributes

Description of Figure 46-5 follows
Description of "Figure 46-5 Requester Profile: Token and Attributes"

Table 46-8 describes Requester Profile Token and Attributes elements and controls.

Figure 46-6 illustrates the Token and Attributes defined for a Relying Party Profile.

Table 46-8 Requester Profile: Token and Attributes

Element Description

Token Type Configuration

Click the + above the table to display a dialog box and then make one selection from each of the following drop down lists:

  • 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 Security Token Service maps a claim, represented by its name and optional Format/Namespace, to a local attribute.

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:

  • Incoming Attribute: surname

  • Local Attribute: sn

Another mapping could be:

  • Incoming Attribute: givenname

  • Local Attribute: givenname

Another mapping could be:

  • Incoming Attribute: emailaddress

  • Local Attribute: mail

46.4.1.3 Relying Party Profile: Token and Attributes

An Administrator can 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 46-6 illustrates the Token and Attributes defined for a Relying Party Profile.

Figure 46-6 Relying Party Profile Token and Attributes

Description of Figure 46-6 follows
Description of "Figure 46-6 Relying Party Profile Token and Attributes"

Table 46-9 describes the elements needed for the Relying Party Profile.

Table 46-9 Relying Party Profile Requirements

Element Descrip[tion

Token Type Configuration

Click the + above the table to display a dialog box and then make one selection from each drop down 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:

  • Attribute Name: Indicates the name of the attribute.

  • Store Type: Indicates the source of the attribute:

    Userstore: the default User Identity Store where the LDAP user record will be used to retrieve the attribute value.

    Incoming Token: the attribute will reference an element of the incoming token.

    Static: the value will be specified in the Value field.

  • Include in Token: Indicates whether or not the attribute should always be included in the issued token. If unchecked, the attribute will only be included if the client requested this attribute.

  • Encrypt: Indicates whether or not the attribute should be encrypted.

    Note: only supported for SAML 2.0. Also, the Encryption Certificate must be set in the Relying Party Partner entry, or it must be present in the WS-Trust request.

  • Value: Contains the value to be used if the Store Type is static value.

See Also: "Relying Party Profile Attributes".

46.4.1.4 Relying Party Profile Attributes

You can define attributes of a Relying Party profile and indicate the source and value of the attribute.

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:

STS_SUBJECT_ID

Contains the subject identifier (username for Username token, NameID Value for SAML assertions, Subject DN for X.509 certificates)

STS_NAMEID_FORMAT

Contains the SAML NameID Format.

STS_NAMEID_QUALIFIER

Contains the SAML NameID Format.

STS_SPNAME_QUALIFIER

Contains the SAML NameID Qualifier.

STS_SP_PROVIDED_ID

Contains the SAML NameID SP Qualifier

STS_SESSION_INDEX

Contains the session index.

STS_AUTHENTICATION_INSTANT

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).

STS_AUTHENTICATION_TIMEOUT

Contains the session expiration time if set (applies to SAML assertions and OAM Session Propagation tokens if present).

STS_X509_CN

Contains the CN component of the X.509 Certificate's Subject DN

STS_X509_OU

Contains the OU component of the X.509 Certificate's Subject DN.

STS_X509_O

Contains the O component of the X.509 Certificate's Subject DN.

STS_X509_L

Contains the L component of the X.509 Certificate's Subject DN.

STS_X509_ST

Contains the ST component of the X.509 Certificate's Subject DN.

STS_X509_C

Contains the C component of the X.509 Certificate's Subject DN.

STS_X509_DC

Contains the DC component of the X.509 Certificate's Subject DN.

STS_X509_*

Contains the component identified by * of the X.509 Certificate's Subject DN.

STS_X509_VERSION

Contains the version attribute of the X.509 Certificate.

STS_X509_ISSUER_X500_PRINCIPAL_NAME

Contains the issuer DN of the X.509 Certificate.

STS_X509_NOT_AFTER

Contains the not after attribute of the X.509 Certificate.

STS_X509_NOT_BEFORE

Contains the not before attribute of the X.509 Certificate.

STS_X509_SUBJECT_X500_PRINCIPAL_NAME

Contains the subject DN of the X.509 Certificate.

STS_X509_SUBJECT_ALTERNATIVE_NAMES

Contains the subject alternative name extension value of the X.509 Certificate.

STS_X509_SERIAL_NUMBER

Contains the serial number of the X.509 Certificate.

STS_OAM_LAST_ACCESS_TIME

Contains the last access time of the OAM Session Propagation Token.

STS_OAM_LAST_UPDATE_TIME

Contains the last update time of the OAM Session Propagation Token.

STS_OAM_CREATION_TIME

Contains the creation time of the OAM Session Propagation Token.

STS_KERBEROS_PRINCIPAL_SHORT

Contains the Principal Short value of the Kerberos Token.

STS_KERBEROS_PRINCIPAL_FULL

Contains the Principal Full value of the Kerberos Token.

STS_KERBEROS_PRINCIPAL_NODOMAIN

Contains the Principal No Domain value of the Kerberos Token.

STS_SAML_ASSERTION_ID

Contains the AssertionID of the SAML Assertion.

STS_SAML_SUBJECT_DNS

Contains the Subject DNS attribute of the SAML Assertion.

STS_SAML_SUBJECT_IP_ADDRESS

Contains the Subject IP Address attribute of the SAML Assertion.

STS_SAML_ASSERTION_ISSUER

Contains the Issuer of the SAML Assertion.

STS_SAML_AUTHN_INSTANT

Contains the authentication instance of the SAML Assertion.

STS_SAML_AUTHN_METHOD

Contains the authentication method of the SAML Assertion.

46.4.1.5 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 allows the Administrator to define mapping rules that is used to translate the name and value of attributes to local names and values.

Figure 46-7 show the Token and Attributes: Issuing Authority section.

Figure 46-7 Token and Attributes: Issuing Authority

Description of Figure 46-7 follows
Description of "Figure 46-7 Token and Attributes: 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 46-10 describes the Token and Attributes elements for Issuing Authority.

Table 46-10 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.

  • Incoming Attribute: Contains the external name of the attribute as it will appear in the Assertion.

  • Local Attribute: Contains the local name of the attribute.

  • Format or Namespace: Contains an optional Format or Namespace. If missing, the namespace value for mapping purposes will be assumed to be urn:oracle:security:fed:attrnamespace for SAML 1.1 Assertions or the format value for mapping purposes will be assumed to be urn:oasis:names:tc:SAML:2.0:attrname-format:basic for SAML 2.0 Assertions

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.

  • External Value: Contains the value of the SAML Attribute.

  • Local Value: Contains the local value that will be set, if the SAML attribute value matches the External Attribute/Local Null fields.

  • External Null: Represents a null SAML attribute value.

  • Local Null: Indicates if the local value should be null, if the SAML attribute value matches the External Attribute/Local Null fields.

  • Ignore Case: Indicates whether or not Security Token Service should ignore case when comparing the attribute value to the Local Attribute field.

46.4.1.6 Issuing Authority Profile: Token Mapping

Administrators can override the Mapping Rules defined in a SAML Validation Template with the ones defined in an Issuing Authority Partner Profile. Then the Security Token Service can map SAML Assertions based on rules specific to a set of Assertion Issuers.

Using the Token Mapping tab, Administrator can override the mapping rules. See Figure 46-8for more details.

Table 46-10 describes the Token Mapping elements for the Issuing Authority.

Figure 46-8 Issuing Authority Profile: Token Mapping Tab

Description of Figure 46-8 follows
Description of "Figure 46-8 Issuing Authority Profile: Token Mapping Tab"

Table 46-11 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 Security Token Service 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.

  • User Token attribute references an attribute from the incoming token that will be matched against the Datastore attribute (defined below) of a user record. The values can be STS_SUBJECT_ID for the NameID Value, or the name of an Attribute contained in the Assertion's AttributeStatement

  • Datastore attribute references the user record attribute that will be matched against the User token attribute referenced above

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, 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.

  • To add custom NameID format, click the add button on the Name Identifier mapping table, and enter the custom URI.

  • To set an attribute for a specific NameID format to be used for mapping operation, set the user record attribute on the line for that format.

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.

  • Partner Token attribute references an attribute from the incoming token that will be matched against the Partner Datastore attribute (defined below) of a Requester Partner. The values can be STS_SUBJECT_ID for the NameID Value, or the name of an Attribute contained in the Assertion's AttributeStatement.

  • Partner Datastore attribute references the partner identification attribute that will be matched against the Partner token attribute referenced above.

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, Security Token Service 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.

  • To add custom NameID format, click the add button on the Name Identifier mapping table, and enter the custom URI.

  • To set an attribute for a specific NameID format to be used for mapping operation, set the requester partner identification attribute on the line for that format.

46.4.2 Managing a Token Service Partner Profile

Users with valid Administrator credentials can use create, locate, view, edit, or remove a token service partner profile.

Prerequisites

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

  1. In the Oracle Access Management Console, click Federation at the top of the window.

  2. In the Federation console, select Partner Profiles from the View drop-down menu in the Security Token Service section.

  3. Select the desired profile type tab and proceed with following steps as needed.

    • Requester Profiles

    • Relying Party Profiles

    • Issuing Authority Profiles

  4. New Profile:

    1. Click the New [Profile Type] button to display a fresh page for your definition.

    2. Enter general information for the chosen profile type (Table 46-7) and click the Next button.

    3. Token and Attributes: Use the appropriate table to provide details for the chosen profile type:

      Requester Profile Table 46-8

      Relying Party Profile Table 46-9

      Issuing Authority Profile Table 46-10

    4. Click Save to submit (or click Cancel to dismiss the page) and then dismiss the confirmation window.

  5. Refine a Profile Search:

    See Refining a Profile Search.

    1. Perform Steps 1 and 2.

    2. Define your query and click the Search button.

    3. In the Search Results table, click the name of partner to view, edit, or remove.

  6. Edit a Profile:

    1. In the Search Results table, click the name of profile to edit and click the Edit button (or choose Edit from the Actions menu).

    2. Make desired changes to partner information.

      Requester Profile Table 46-8

      Relying Party Profile Table 46-9

      Issuing Authority Profile Table 46-10

    3. Click Apply to submit the changes (or Revert to cancel changes) and then dismiss the confirmation window.

  7. 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:

    1. In the Search Results table, highlight the row containing the profile to remove.

    2. Click the Delete (X) button (or choose Delete Selected from the Actions menu), then dismiss the confirmation window.

46.4.3 Refining a Profile Search

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.

This one is for a Requester Pofile. However, all controls are the same; only the results differ for different profile types.

Figure 46-3 illustrates a typical Search Profiles page.

Figure 46-9 Search Partner Profiles Page: Requester Profiles

Description of Figure 46-9 follows
Description of "Figure 46-9 Search Partner Profiles Page: Requester Profiles"

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.