36 Managing Token Service Partners and Partner Profiles

This chapter provides the following topics describing management of Token Service Partners and Partner Profiles:

36.1 Prerequisites

"Introduction to Oracle Access Management Security Token Service"

Chapter 32, "Security Token Service Implementation Scenarios"

Any task you can perform using the Oracle Access Management Console can also be performed using the

See Also:

Oracle Fusion Middleware WebLogic Scripting Tool Command Reference

36.2 Introduction Token Service Partners and Partner Profiles

This section provides the following topics:

36.2.1 About Token Service Partners

A Token Service partner represents a partner trusted by the Security Token Service. Table 36-1 describes the partner types.

Table 36-1 Security Token Service Partners

Partner Type Description

Requester

Represents a Web Service Client interacting directly with Security Token Service in order to issue or validate tokens

Relying Party

References a Web Service Provider that will be the recipient of tokens issued by the Security Token Service server

Issuing Authority

Represents an Assertion issuer. When validating an Assertion, its issuer must be a known Issuing Authority Partner entry in Security Token Service


The Security Token Service is capable of interacting with client types described in Table 36-2.

Table 36-2 Security Token Service Clients

Client Type Description

Web Service Client

Modules defined as requester partners in Security Token Service (typically SOAP clients).

End users

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


36.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, and Issuing Authority Partner Profiles.

  • Requester Profile

  • Relying Party Profile

  • Issuing Authority Partner Profile

36.2.2.1 About Partner Entries

A partner entry contains the information in Table 36-3:

Table 36-3 Security Token Service Partner Entry

Partner Entry Description

Certificates

Signing and Encryption Certificates

Reference

Reference to a Partner Profile

Requester only

When the partner is a Requester, the partner entry also contains Username Token credentials, and Identification strings used to map incoming data to a requester.


36.2.2.2 About Partner Profile Data

A partner profile entry contains the information in Table 36-4, depending on the type of profile.

Table 36-4 Security Token Service Partner Profile Data

Client Type Description

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


36.3 Managing Token Service Partners

This section provides the following topics.

36.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 36-1 shows the New Requester partner page in the Oracle Access Management Console, which includes all Partner elements.

Figure 36-1 New Requester Partner Page

Description of Figure 36-1 follows
Description of "Figure 36-1 New Requester Partner Page"

While most elements are common to all partners (name, description, and whether this partner is trusted), certain elements depend upon the specific partner type, as described in Table 36-5.

Table 36-5 Partner Elements for Partner Types

Partner Type Description

Requester partners

Can specify an encryption certificate and a signing certificate, as well as Token Authentication and Identity Attributes.

Relying Party partners

Can specify only an encryption certificate and Resource URLs.

See Figure 36-2

Issuing Authority partners

Can specify only a signing certificate.


Figure 36-2 New Relying Party Partners Page

Surrounding text describes Figure 36-2 .

Table 36-6 describes elements for Security Token Service partners. Unless explicitly stated otherwise, all elements apply to every partner type.

Table 36-6 Elements for Security Token Service Partners

Element Description

Partner Name

Enter a name for this partner.

Issuer ID

Issuing Authority Only

Unique identifier used in SAML Assertion Issuer field referencing this Issuing Authority.

Partner Type

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

  • Requester

  • Relying Party

  • Issuing Authority

Partner Profile

Choose from the profiles listed to define your chosen partner.

Description

Optional.

Trusted

Check this box to indicate whether or not the partner is trusted. If not checked, the 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, 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 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/


Figure 36-3 shows a Requester Partner page that is filled in.

Figure 36-3 Defined Requester Partner

Description of Figure 36-3 follows
Description of "Figure 36-3 Defined Requester Partner "

36.3.2 Managing a Token Service Partner

Users with valid Administrator credentials can use the following procedure to create, find, edit, or delete a token service partner using Oracle Access Management Console.

Prerequisites

A partner profile must be defined for the type of partner you will create.

To manage a token service partner

  1. From the Oracle Access Management Console, open the:


    System Configuration tab
    Security Token Service section
    Partners node
  2. Under the Partners node, double-click the desired partner type and proceed with following steps as needed.

    • Requesters

    • Relying Parties

    • Issuing Authorities

  3. New Partner:

    1. Click the New PartnerType button to display a fresh page for your definition.

    2. Enter general information for the chosen partner type (Table 36-6).

    3. Trusted: Click to select (or leave blank if this is not a trusted partner).

    4. Certificates: Load any necessary certificates.

    5. Relying Party: Enter Resource URLs, if needed.

    6. Issuing Authority: Enter the Issuer ID of this Authority.

    7. Requester: Enter Username Token credentials, if needed.

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

  4. Refine a Partner Search: "Refining Partner Searches"

    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.

  5. Edit a Partner:

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

    2. Make desired changes to partner information (Table 36-6).

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

  6. Remove a Partner: Use the Search controls to refine and submit your query, as needed.

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

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

36.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 36-4 illustrates a Requester Partner, where only the results differ from that of other Partner Types.

Figure 36-4 Partner Search Controls

Description of Figure 36-4 follows
Description of "Figure 36-4 Partner Search Controls"

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.

36.4 Managing Token Service Partner Profiles

This section provides information about Token Service Partner Profiles.

36.4.1 About Managing Partner Profiles

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

Figure 36-5 Requester Profile: General

Description of Figure 36-5 follows
Description of "Figure 36-5 Requester Profile: General"

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

Table 36-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.


Requester Profile: Token and Attributes

Figure 36-6 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 36-6 Requester Profile: Token and Attributes

Description of Figure 36-6 follows
Description of "Figure 36-6 Requester Profile: Token and Attributes"

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

Table 36-8 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:

Add Token Type Configuration to Requester Profile

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


Relying Party Profile: Token and Attributes

Figure 36-7 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 36-7 Relying Party Profile Token and Attributes

Description of Figure 36-7 follows
Description of "Figure 36-7 Relying Party Profile Token and Attributes"

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

Table 36-9 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:

Add Token Type Configuration to Requester Profile

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


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:

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.

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 36-8, 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 36-8 Token and Attributes: Issuing Authority

Description of Figure 36-8 follows
Description of "Figure 36-8 Token and Attributes: Issuing Authority "

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


Issuing Authority Profile: Token Mapping

Using the Token Mapping tab, shown in Figure 36-9, Administrators can override the Mapping Rules defined in a SAML Validation Template with the ones defined in an Issuing Authority Partner Profile. This way, Security Token Service can map SAML Assertions based on rules specific to a set of Assertion Issuers.Table 36-10 describes the Token Mapping elements for the Issuing Authority.

Figure 36-9 Issuing Authority Profile: Token Mapping Tab

Surrounding text describes Figure 36-9 .

Table 36-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.


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

There are no prerequisites for Issuing Authority Partner Profiles.

To create, find, edit, or remove a partner profile

  1. From the Oracle Access Management Console, open the:


    System Configuration tab
    Security Token Service section
    Partner Profiles node
  2. 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

  3. New Profile:

    1. Click the New ProfileType button to display a fresh page for your definition.

    2. Enter general information for the chosen profile type (Table 36-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 36-8

      Relying Party Profile Table 36-9

      Issuing Authority Profile Table 36-10

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

  4. Refine a Profile Search: "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.

  5. 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 36-8

      Relying Party Profile Table 36-9

      Issuing Authority Profile Table 36-10

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

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

36.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 36-4 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 36-10 Search Profiles Page: Requester

Description of Figure 36-10 follows
Description of "Figure 36-10 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.