End users, not defined as requester partners, but possibly present in the User Identity Store.

21.2.2 About Partner Profiles

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.

21.2.3 About Partner and Profile Data

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

21.3 Managing Token Service Partners

21.3.1 About Managing Token Service Partners

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.

Uneditable description, depending upon the type of partner you are creating or editing:

Requester

Relying Party

Issuing Authority

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:

Encryption and signing certificates

Encryption certificate

Signing certificate

Username Token Authentication

Requester only

Values can be entered for the following for Username Token Authentication:

Username

Password

Confirm Password

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:

The token data or binding data such as the SSL Client Certificate's Subject DN if present, or HTTP Basic Authentication username.

The identity attributes present in each requester partner entry.

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:

A Resource URL matches exactly the AppliesTo location value. For example, the AppliesTo location is http://relying.party.test.com/testing/service and the Resource URL is also http://relying.party.test.com/testing/service).

Or, a Resource URL is the parent of the AppliesTo location value. For example, the AppliesTo location is http://relying.party.test.com/testing/service and the Resource URL is http://relying.party.test.com/testing, or Resource URL is http://relying.party.test.com/

21.3.3 Refining Partner Searches

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.

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

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:

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

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.

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.

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 Oracle Security Token Service should ignore case when comparing the attribute value to the Local Attribute field.

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.

Figure 21-8 Issuing Authority Profile: Token Mapping Tab

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.

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

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

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.

21.4.2 Managing a Token Service Partner Profile

Users with valid Administrator credentials can use this procedure to 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.

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

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.

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.

Scripting on this page enhances content navigation, but does not change the content in any way.