Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.1) Part Number E15478-07 |
|
|
PDF · Mobi · ePub |
This chapter provides the following information for Oracle Security Token Service.
Both the Oracle Access Manager and Oracle Security Token Service services must be running, as described in "Enabling and Disabling Oracle Security Token Service".
Oracle Security Token Service supports control of who can access WSPs by defining Application Domains that provide access to resources based on policies. Application domains identify Web Services, along with authorization rules that determine who can request a security token based on the WSPs.
The following functionality is established by Trust Issuance Policies, which can be managed through Application Domain under the Policy Configuration tab of the Oracle Access Manager Console.
Resource of type TokenServiceRP representing Relying Parties or Web Service Providers.
Token Issuance Policy defining a policy for a set of resources of type TokenServiceRP.
Constraint defining the identities of the clients that are allowed or denied issuance of tokens for the resources listed in the policy. The clients can either be Requester Partners or User from the Default Identity Store.
Oracle Security Token Service supports the creation of Relying Party Partner, representing a remote Web Service Provider that will be the consumer of a security token issued by Oracle Security Token Service.
For each Relying Party Partner, it is possible to define URLs that will be mapped to the partner, so that WS-Addressing endpoint specified in a WS-Trust Request can be mapped to an Oracle Security Token Service Relying Party Partner.
At runtime, when a client requests a token to be issued, Oracle Security Token Service will evaluate the Trust Issuance Policies to determine whether or not the token can be issued:
The client will be identified either as a Requester Partner or as an end user
If an AppliesTo element was present in the WS-Trust Request and was mapped to a Relying Party Partner, then the TokenServiceRP resource for the Trust Issuance Policy evaluation will be the Partner ID of that Oracle Security Token Service Relying Partner.
If an AppliesTo element was present in the WS-Trust Request and could not be mapped to a Relying Party Partner, then the TokenServiceRP resource for the Trust Issuance Policy evaluation will be the UnknownRP defined in the OAM Suite Application Domain.
If an AppliesTo element was missing in the WS-Trust Request, then the TokenServiceRP resource for the Trust Issuance Policy evaluation will be the MissingRP defined in the OAM Suite Application Domain.
Oracle Security Token Service requires the following items (at a minimum) to process a request and issue a token based on an incoming request (RST):
EndPoints
One Issuance Template
One Validation Template
One Requester Partner Profile that contains the token
One Relying Party Partner Profile
Note:
Partners might need to be provisioned.
An LDAP server is required for the Oracle Security Token Service to map the Username token that references the user to an LDAP User record, and then use that record to populate the outgoing token. Partners might need to be provisioned before they are available.
All defined template names appear in the Search Results Table when you open either the Token Validation Template or Token Issuance Template node. To quickly find a specific template or set of templates, you can use the search controls.
This section explains the controls you can use to refine your search, which are similar whether you are searching for a Token Validation Template or a Token Issuance Template. It includes the following topics:
The following figures show the search pages where you will see many similarities:
Figure 20-1 Validation Templates Search Controls
Figure 20-2 Issuance Template Search Controls
Table 20-1 describes the controls available to refine a template search. Unless explicitly stated, all elements are available for both Validation and Issuance Template searches.
Table 20-1 Template Search Controls
Element | Description |
---|---|
Match |
Choose All to search for a template that matches all your specifications. Choose Any to search for a template that matches at least one of your specifications. |
Search Operations List |
A list of operations from which you choose one to help refine your search. ![]() |
... Template Name |
Choose an operation from the list and enter information in the field to help refine your search. |
Description |
Refine your search using the optional description field. |
Token Protocol Validation Template only |
Choose the token protocol from those listed:
|
Token type |
Choose the token type. Both standard and custom token types are included.
|
Search |
Initiates the Search function using criteria in the form. |
Reset |
Resets the Search form with defaults only. |
Add Fields |
A list of additional items you can add as search criteria. ![]() |
Search Results Table |
Itemizes the results of your search based on choices in the View menu, described later in this table. |
Actions menu Shown: Actions for Validation Template |
Provides the following functions that can be performed on a selection in the results table: ![]() Note: Actions menu functions mirror command buttons above the results table. For example:
|
View menu Validation Template only |
A list from which you can identify which information to display in the results table. ![]() |
View menu Issuance Template only |
A list from which you can identify which information to display in the results table. ![]() |
![]() |
Controls you can choose to define the order of items listed in the results table:
|
Users with valid Administrator credentials can use the following procedure to use search controls to locate a specific template or set of templates. For example, to locate all templates of a certain token type you can simply choose the type of token. To refine the search further to all templates of a specific token type and name.
When performing these steps, fill in as much or as little as you want. Skip any steps that do not apply to you.
See Also:
To search for a template
From the System Configuration tab, expand the Secure Token Services Settings section.
In the navigation tree, double-click the desired Template node. For example: Token Validation Templates.
Edit Search Criteria (Table 20-1). For example:
Match: All
Name: contains em
Token Type: equals Username
Click Search and review results.
An issuance template contains rules on how a token will be created and is specific to a token type. Each issuance template indicates Signing and Encryption and also contains Attribute Name, Value Mapping, and Filtering settings to be sent as part of the token.
This section provides the following information:
Each Token Issuance Template indicates how to construct a token. In other words, which signing or encryption to use when constructing a token. Each Token Issuance Template also defines the attributes mapping and filtering rules to be applied to the attributes that will be included in the outgoing token. However, Issuance Templates do not list the attributes that will be sent in the outgoing token: these are defined in the Relying Party Partner Profile.
Token Issuance Template details which will differ depending on your chosen token type. Table 20-2 describes where to find more information.
Table 20-2 Issuance Template Requirements
Topic | Figures and Tables |
---|---|
General Details |
|
Issuance Properties: Username Tokens |
|
Issuance Properties: SAML Tokens |
|
Security: SAML Tokens |
|
Attribute Mapping: SAML Tokens |
General Details
Figure 20-3 shows the New Issuance Template page with defaults showing. Unless explicitly stated, General information is the same regardless of the Token Type you choose. For more information, see Table 20-3. After you fill in General information and click Save, you cannot return and edit the template name or token type.
Figure 20-3 Issuance Template: General Details and Defaults
Table 20-3 Issuance Template: General Details
Elements | Description |
---|---|
Issuance Template Name |
Enter a unique name for this template. |
Description |
Optional. |
Token Type |
Choose a standard (or custom, if any) token type from those listed. |
SAML, Username, and Custom Token Types |
|
Send Encrypted Token |
Click to enable token encryption. |
Token Encryption Algorithm |
When token encryption is enabled, choose a Token Encryption Algorithm from those listed. |
Issuance Properties: Username Token Type
If the token type is Username, the Issuance Properties shown in Figure 20-4 are needed for a Username token type template.
Figure 20-4 Issuance Properties: Username Token Type
Table 20-4 describes the Issuance Properties for the Username token type.
Table 20-4 Issuance Properties: Username Token Type
Element | Description |
---|---|
Name Identifier User Attribute |
Attribute to be used to populate the Username element in the Username Token. |
Name Identifier User Attribute Store |
Choose the user attribute store type:
Note: If the Attribute Store is the Userstore, LDAP is used to retrieve the attribute from the user record. If the Attribute Store is context, data from the incoming token is used as the attribute source. |
Password Attribute |
Attribute to be used to populate the Password element in the Username Token. |
Password Attribute Store |
Choose the password attribute store type:
Note: If the Attribute Store is the Userstore, LDAP is used to retrieve the attribute from the user record. If the Attribute Store is context, data from the incoming token is used as the attribute source. |
Include Nonce |
Indicates whether or not a Nonce made of random data should be included in the Username token Default: Disabled |
Include Timestamp |
Indicates whether or not a the Created element should be included in the Username token Default: Disabled |
Issuance Properties: SAML Token Types
SAML 1.1 and 2.0 token types require the issuance properties illustrated in Figure 20-5.
Note:
These issuance properties differ from those for Username token type.
Figure 20-5 Issuance Properties: SAML Token Types
Table 20-5 describes all Issuance Properties by token type. Only SAML token types require issuance properties.
Table 20-5 Issuance Properties: SAML Token Types
Element | Description |
---|---|
Assertion Issuer |
Specifies the identifier representing the issuer of the assertion. This string is used to represent this Oracle Security Token Service as the issuer of the assertion. |
Name Identifier Format |
Choose a format from the list and then enter the details in the text field. ![]() |
Name Identifier Qualifier |
Contains the string that will be set as the Name Identifier Qualifier. |
Name Identifier User Attribute |
References the attribute that will be used to populate the value of the Name Identifier. |
Name Identifier User Attribute Store |
Note: If the Attribute Store is the Userstore, LDAP is used to retrieve the attribute from the user record. If the Attribute Store is context, data from the incoming token is used as the attribute source. |
Include Authentication Statement |
Indicates whether or not a SAML Authentication Statement should be included in the Assertion. Default: Disabled Note: An authentication operation is required for a statement of this type to be included. An authentication statement will be included if the incoming token contained some authentication data and that those were validated (for example, the incoming SAML Assertion contains an authentication statement, or a Username Token contains credentials that were validated). |
Include Attribute Statement |
Indicates whether or not a SAML Attribute Statement will be included in the outgoing Assertion. A statement of this type will be included only if this flag is set to true and if at least one attribute is included in the outgoing Assertion. Default: Enabled Note: the RP PP will determine which attributes need to be included in an outgoing token. |
Validity Period |
Specify the length of time (in seconds) that the token will be valid. Default: 3600 (seconds) |
Security Details: SAML Tokens
Only SAML token types require Security Details, as shown in Figure 20-6 and described in Table 20-6.
Figure 20-6 Security Details: SAML Tokens
Table 20-6 Security Details: SAML Tokens
Elements | Description |
---|---|
Signing And Encryption |
Indicates whether or not the Assertion will be signed using the Key referenced by the Signing Keystore Access Template ID field. |
Sign Assertion |
Indicates whether or not the signing certificate will be included in the Assertion. Default: Enabled |
Include Certificate in Signature |
Default: Enabled |
Signing Keystore Access Template Id |
References the key to be used to sign assertions created with this issuance template. The key templates are defined in the Security Token Service Settings section. |
Subject Confirmation |
|
Default Subject Confirmation Method |
Indicates which Subject Confirmation Method will be used by default, if the requester did not specify a method in the WS-Trust request. Possible values are:
|
Compute Holder-of-Key Symmetric Key |
Default: Enabled Indicates whether or not Oracle Security Token Service will generate random data when creating the Secret Key for the Holder of Key Symmetric Key data.
|
Encrypt RSTR Proof Token |
Indicates whether or not the Proof Token must be encrypted when returning the server entropy or secret key to the requester in the WS-Trust response, when the Subject Confirmation method is Holder of Key with Symmetric Key Default: Disabled |
Holder-of-Key Symmetric Key Generation Algorithm |
Indicates the symmetric key generation algorithm to use to create the secret key when the Subject Confirmation method is Holder of Key with Symmetric Key: ![]() |
Attribute Mapping: SAML Tokens
When the token type is SAML 1.1 or 2.0, it is possible to define attribute mapping and filter rules that will be applied to the attributes included in the Assertion.
There are three different rules:
Attribute name mapping where the local name of an attribute can be changed to another value. For example, givenname can be changed to firstname.
Attribute value mapping where the local value of an attribute can be translated to another value. For example, President to CEO.
Attribute value filtering where the local value of an attribute can be filtered so it is not included in the outgoing assertion. For example, some sensitive attribute values could be removed while others would be issued.
See Also:
Token Mapping attributes in Figure 20-9 and Table 20-11.
Table 20-7 Issuance Template: Attribute Mapping, SAML Token
Element | Description |
---|---|
Attribute Name Mapping |
Defines an optional mapping between the local name of an attribute, and the name used to reference this attribute in the assertion. The mapping is optional. If an attribute does not have a mapping defined, then its local name will be used, and the namespace will be set to
|
Attribute Value Mapping |
Defines an optional value mapping for an attribute that will be included in the Assertion. 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.
|
Attribute Value Filters |
Defines an optional value filtering for an attribute that will be included in the Assertion. Note: This attribute value filtering applies to an Attribute Name mapping. In order to define an attribute filtering for an attribute, it is required to first define an attribute name mapping for that attribute.
|
Attribute Value Condition Filters
This optional value filtering applies to an Attribute Name mapping and will be included in the Assertion. To define an attribute filtering for an attribute, you must first define an attribute name mapping for that attribute. The Condition is associated with the expression to determine whether or not the attribute value should be filtered. The possible Condition values are:
regexp: the expression will contain a regular expression, and if it evaluates to true, the attribute value will be filtered.
equals: if the attribute value matches the data contained in the expression field, then it will be filtered.
not-equals: if the attribute value does not match the data contained in the expression field, then it will be filtered.
not-equals: if the attribute value does not match the data contained in the expression field, then it will be filtered.
endswith: if the attribute value ends with the data contained in the expression field, then it will be filtered.
contains: if the attribute value contains an occurrence of the data contained in the expression field, then it will be filtered.
not-contains: if the attribute value does not contains any occurrence of the data contained in the expression field, then it will be filtered.
equals-null: if the attribute value is null, then it will be filtered.
not-equals-null: if the attribute value is not null, then it will be filtered.
Users with valid Administrator credentials can use this procedure as a guide when developing a new Token Issuance Template (or editing an existing template) Skip any steps that do not apply to you.
The following procedure describes how to create a new Token Issuance Template for a Security Assertion Markup Language (SAML) token.
Prerequisites
Confirm that the desired LDAP Identity Store is registered with Oracle Access Manager and configured as the default Identity Store.
To create a new token Issuance template
Display the list of existing Token Issuance Templates.
New Token Issuance Template:
Click the New Issuance Template button in the upper-right corner (or click the Add (+) command button above the Search Results table).
General: Define general information for this template and see:
Click Save and dismiss the confirmation window (or click Cancel without saving).
Username Token Type: Define issuance parameters for this template and see:
SAML Token Type: Define parameters for this template and see:
Table 20-5, "Issuance Properties: SAML Token Types"
Table 20-6, "Security Details: SAML Tokens"
Table 20-7, "Issuance Template: Attribute Mapping, SAML Token"
Click Apply (or click Revert without saving it).
Close the definition.
Find an Existing Template: From the Security Token Service section of the System Configuration tab:
Find All: Double-click the Token Issuance Templates node and review the results table.
Narrow the Search: Specify your search criteria (Table 20-1), click the Search Button, and review the results table.
Reset the Search Form: Click the Reset button.
Edit a Template: Start with the saved page you just created.
Alternatively: Use Step 3 to find the desired template and click the name in the Search Results table to display the definition.
Edit details as needed.
Click the Apply button at the top of the page to submit changes (or Revert to undo your changes).
Remove a Template:
Click the desired name in the Search Results table to select the item to remove.
From the Actions menu, click Delete (or click the Delete (X) command button above the table.
Click the Delete button in the Confirmation window (or click No to cancel the operation).
A validation template is used to validate an incoming token and, optionally, map the incoming token to either a Requester Partner or a user record:
For OnBehalfOf use cases, a WS-Trust Validation Template must be present.
For validating an Assertion, one Issuing Authority Partner Profile must be present.
The Oracle Security Token Service Endpoint is linked to a WSS Validation Template that indicates how to validate the token in the WSS header and how to map the token and binding data to a Requester.
This section provides the following topics.
An Oracle Security Token Service Endpoint is always mapped with a WS-Security Validation Template that indicates how to map the request to a requester entry or to a user:
If mapping is required and no match is found, processing will fail.
If no mapping is required, a default requester partner profile will be used.
In either case, a requester partner profile is retrieved.
If a mapping is performed to a user record, a default requester partner profile will be used.
If a mapping is performed to a requester partner entry, the requester partner profile for this partner will be used.
A validation template determines the token validation rules:
Whether or not to validate and map the incoming token.
The mapping rules to be used if mapping is enabled.
A validation template is specific to a token type and specific to a protocol as described in Table 20-8.
Table 20-8 Validation Template Protocols
Protocol | Description |
---|---|
WS-Security |
Validates only WS-Security Tokens:
When you toggle the Token Protocol from WS-Trust to WS-Security, options in the Token Type list do not change. However, the required "Default Partner Profile" list appears from which you must choose one profile for WS-Security. |
WS-Trust |
Validates only Tokens included in OBO (on behalf of) field of the RST (request):
|
A validation template mapping rules determines how the incoming data is mapped to a user or a partner, using data from the incoming token:
Username for Username Token
UserID for Kerberos Token
NameID and attributes for SAML Token
DN Components for X.509 Token
Attributes from a Custom
Mapping is performed as follows:
Simple mapping: one incoming attribute matched against one user record attributes
Complex LDAP query: LDAP query with placeholders for incoming data (e.g.: (&(sn=%lastname%)(mail=%email%))
NameID Mapping table for SAML Token
Figure 20-7 illustrates default General details on the New Validation Template page.
Figure 20-7 New Validation Template page: General Page Defaults
Table 20-9 describes the elements on the New Validation Template, General page.
Table 20-9 New Validation Template: General Details
Element | Description |
---|---|
Back |
Click this button to return to the previous page. |
Next |
Click this button to proceed to the next page. |
Cancel |
Click this button to dismiss the page. |
Validation Template Name |
The name you choose for this template. For example:
|
Description |
Optional. |
Token Protocol |
The type of Validation Template to be created. Type can be either:
|
Token Type |
A list of in-bound token types from which you choose the one to use for this template. The token type options depends on the protocol type:
|
Default Partner Profile |
Only applies to WS-Security Validation Template References the default requester partner profile to use, in case the incoming request is not mapped to a requester partner. For example, if the request is mapped to a user instead. A requester partner profiles contains settings that are used during the request processing. If the incoming request was mapped to a requester partner, then the partner profile for that requester will be retrieved and used as the requester partner profile |
Timestamp Lifespan |
Applies only to Username and SAML Validation Templates. It determines the validity time of a Token (for Username Token, only if it contains a Created element indicating the instant it was created). Default: 1000 (seconds) |
Authentication Details |
Specific to username token validation template. |
Enable Credential Validation |
Check this box to enable validation using credentials contained in the username token. When enabled, Oracle Security Token Service will validate the username and the password elements contained in the username token, using the specified validation source. Note: password digest as defined in the Username Token WS-Security Profile is not supported in this release. See Also: Table 20-10, "New Validation Template: Authentication Details" |
Figure 20-8 illustrates the General details page when Enable Credential Validation is checked and, as a result, the Authentication Details section of the page is visible with its default values. This is specific to username token validation.
Figure 20-8 New Validation Template: General Authentication Details
Table 20-10 describes Authentication related details that are available when you choose Enable Credential Validation.
Table 20-10 New Validation Template: Authentication Details
Element | Description |
---|---|
Validation Source |
A list from which you can choose a credential validation sources There are four types of validation sources when validating the credentials contained in a username token:
|
LDAP URL |
The URL of the LDAP server. |
Admin User |
The username of an account used to perform lookups in the LDAP server. |
Admin Password |
The password of an account used to perform lookups in the LDAP server. |
Base DN |
The Base search DN used when looking up user records. |
Enable HA |
Indicates whether or not the LDAP server is in HA mode, fronted by a load balancer. |
Person Object Class |
The person object class associated with the user records. |
Unique Id |
The attribute of the user record containing the user unique identifier data.In most cases, is identical to the Credential ID field. |
Credential Id |
The attribute of the user record containing the username data. This field will be used to lookup user records, based on the username. |
Maximum Connections |
The maximum number of concurrent opened LDAP connections Default: 40 |
Connection Wait Timeout |
Maximum amount of time to wait when opening a new connection. Default: 5 (seconds) |
Connection Inactivity Timeout |
Maximum amount of inactivity time for an LDAP connection, before closing it. Default: 300 (seconds) |
Connection Read Timeout |
Maximum number of concurrent opened LDAP connections. Default: 10 (seconds) |
Token Mapping
The Token Mapping section indicates the following:
If an incoming token needs to be mapped.
If the incoming token needs to be mapped, what kind of mapping is done. For example, mapping token to user, mapping token to partner, and so on.
How the mapping is done. For example, by mapping a token attribute to a partner/user attribute, or by using an LDAP query involving several token attributes.
Mapping rules determine how the incoming data is mapped to a user or a partner. The following data of the incoming token is used:
Username for UNT
UserID for Kerberos
NameID and attributes for SAML
DN Components for X.509
Attributes from custom
Mapping is performed using the following:
Simple mapping: One incoming attribute matched against one user record attributes.
Complex LDAP query: An LDAP query with placeholders for incoming data. For example, (&(sn=%lastname%)(mail=%email%))
A NameID Mapping table for SAML
Following are several Token Mapping Examples for a new Validation Template:
Figure 20-9, "Token Mapping: SAML2 WS-Security Validation Template"
Figure 20-10, "Token Mapping, username-wstrust-validation-template"
Figure 20-9 shows the mapping configuration settings required for Oracle Security Token Service to map the token to a user record, by matching the NameID value to user records that have a matching attribute, based on the NameID format:
Enable Map Token to User
Enable Simple User Mapping
Disable Attribute Based User Mapping
Figure 20-9 Token Mapping: SAML2 WS-Security Validation Template
Figure 20-10 shows the mapping configuration settings required for Oracle Security Token Service to map the token to a user record by matching the username element of the Username token to a user record that has a matching uid. The required settings are:
Enable Map Token to User
Enable Simple User Mapping
Datastore Attribute set to uid
Disable Attribute Based User Mapping
Figure 20-10 Token Mapping, username-wstrust-validation-template
Figure 20-11 shows the mapping configuration settings required for Oracle Security Token Service to map the token to a requester partner entry by matching the Subject DN of the certificate to a Requester Partner that has a match on SSL Client Cert DN Identification attribute. The required settings are:
Map Token to Partner
Disable Simple User Mapping
Disable Attribute Based User Mapping
Enable Simple Partner Mapping
Figure 20-11 Token Mapping: x509-wss-validation-template
Not all elements apply to all token types and token protocols. The elements that you must define will vary.
Table 20-11 describes the token mapping elements for validation templates.
Table 20-11 New Validation Template: Token Mapping
Element | Description |
---|---|
Map Token to |
WS-Security Validation Template: Map Token to list
- - - - - - - - - - WS-Trust Validation Template: Map Token to User Check the box to enable (or clear the checkbox to disable). |
Enable 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. WS-Security Validation Template: Only Username, SAML Assertion, Kerberos. and X.509. WS-Trust Validation Template: Username, SAML Assertion, Kerberos, X.509, OAM and custom token. The layout is different, depending on the token type of this validation template: Username Token:
SAML Assertion:
Kerberos:
X.509:
OAM:
Custom:
|
Enable User Name Identifier Mapping |
When enabled, define the following: WSS and WS-Trust Validation Templates will contain the same section for the Name Identifier mapping settings. A NameID user mapping operation 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, OSTS 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. |
Enable Attribute Based User Mapping |
WSS Validation Template: only Username, SAML Assertion, Kerberos and X.509. WS-Trust Validation Template: only Username, SAML Assertion, Kerberos, X.509 and custom token 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 the percent (%) 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%)). The possible token attributes depend on the token type. Username Token
SAML Assertion
Kerberos
X.509
Custom Token
|
Enable Simple Partner Mapping |
Only for WSS Validation Template and for the following token types: Username, SAML Assertion, Kerberos, and X.509. 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. The layout is different, depending on the token type of this validation template Username Token
SAML Assertion
Kerberos
X.509
|
Enable Partner Name Identifier Mapping |
When enabled, defines the following only for WSS Validation Template and for SAML token types: 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, Oracle 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. |
This is a server side configuration. A default Token Validation Template exists. Users with valid Administrator credentials can use can use the procedure in this section to add, find, edit, or delete token validation templates. Skip any steps that you do not need.
The Oracle Security Token Service Endpoint must be linked to a WS Security Validation Template that indicates:
how to validate the token in the Webservice Security header
how to map the token and binding data to a Requester
The information here can be applied when you want to validate the following:
WS-Security tokens present in the SOAP Header, of type: Username, SAML 1.1, SAML 2.0, X.509 and Kerberos.
WS-Trust tokens present in the OnBehalfOf element or in the ValidateTarget element of the WS-Trust request, of type: Username, SAML 1.1, SAML 2.0, X.509, Kerberos, OAM Session Propagation Token and custom tokens.
The following procedure includes several examples of input following specific parameters. Also, a brief translation appears within parentheses (). For instance: Name (username-token): email-wstrust-valid-temp
. Values in your environment will be different.
Prerequisites
To manage token validation templates
Display the list of existing Token Validation Templates.
New Token Validation Template:
Click the New Validation Template button in the upper-right corner (or click the Add (+) command button above the Search Results table).
General: Define parameters for this template (Table 20-9). For example:
email-wstrust-valid-temp
email
requester-profile
Authentication: Enable Credential Validation for this template, if needed, and provide details (Table 20-10). If the token type is username, enable credential validation if needed for this template and provide the details.
Token Mapping: Specify preferences for this template based on your token type (Table 20-11).
Click Save and dismiss the confirmation window (or click Cancel without saving it).
Close the definition (or edit it as described in Step 4).
Find an Existing Template: From the Security Token Service section of the System Configuration tab:
Find All: Double-click the Token Validation Templates node and review the results table.
Refine Search Results: Specify your search criteria (Table 20-1), click the Search Button, and review the results table.
Reset the Search Form: Click the Reset button.
Edit a Template: Start with the saved page you just created.
Alternatively: Use Step 3 to find the desired template and click the name in the Search Results table to display the definition.
Edit the template definition as needed.
Click the Apply button at the top of the page to submit changes (or click Revert to undo your changes).
Remove a Token Validation Template:
Click the desired name in the Search Results table to select the item to remove.
From the Actions menu, click Delete (or click the Delete (X) command button above the table.
Click the Delete button in the Confirmation window (or click No to cancel the operation).
An endpoint is a Web Service published by Oracle Security Token Service where clients can send WS-Trust requests over SOAP. An endpoint is:
Protected by a WS Security Policy.
Bound to WSS Validation Template that will indicate how to validate the security token and how to map it.
Specific to a token type, namely, the one specified in the WSS Validation Template.
Note:
The WS-Security policy protecting the endpoint must be compatible with the WSS Validation Template bound to the endpoint.
An endpoint is a Web Service endpoint published by Oracle Security Token Service and protected by OWSM Agent. An endpoint is bound to:
A WS-Security policy that will determine the WSS requirements in terms of message protection and security tokens
A WSS Validation template that will indicate how the request will be processed, how the security token will be validated.
This section provides the following information:
Oracle Security Token Service Endpoint definitions consist of three categories, as shown in Figure 20-12.
Table 20-12 describes the required Endpoints categories.
Table 20-12 Endpoints Page
Elements | Description |
---|---|
Endpoint URI |
The path to the Endpoint, relative to the Oracle Security Token Service base URL The Oracle Security Token Service base URL is /sts. |
Policy URI |
Choose from a listing of Oracle WSM policies the one used to protect this Endpoint. OAM Administrator can add a new custom policy to the available listing.To show this newly created Policy URI in the the endpoints table list, use the following wlst command to update the owsmpolicies map: putStringProperty("/stsglobal/owsmpolicies/<index>", "<newcustom_policypath>) For example: putStringProperty("/stsglobal/owsmpolicies/31", "sts/newcustom_policy") |
Validation Template ID |
Choose from a listing of Validation Template names to identify one for use with this Endpoint. |
Once an Endpoint is created, you can remove it but you cannot edit the definition.
Users with valid OAM Administrator credentials can perform the following task to add, edit, or remove an Endpoint.
Prerequisites
Creating a Token Validation Template to reference
To create or delete an endpoint
From the Oracle Access Manager Console System Configuration tab, open the Security Token Services section.
Double-click the Endpoints node to display a list of existing Endpoints.
New Endpoint: see Table 20-12 and
Click the Add (+) button above the table (or choose New Endpoint from the Actions menu).
Enter the new Endpoint URI.
Choose one of the Oracle WSM policies to protect this Endpoint.
Choose the Validation Template to use with this Endpoint.
Click Apply to submit the definition and dismiss the confirmation window (or click Revert to dismiss the page without submitting it).
Close the page.
Remove Endpoint:
Highlight a row in the Endpoints table and click the Delete (X) button (or choose Delete Selected from the Actions menu).
Confirm removal (or cancel the removal).
This section provides the following topics:
A Token Issuance Policy defines the rules under which a token can be issued for a resource (Relying Party Partner) based on the client's identity, with the client either being a Requester Partner or an end user. If a Requester is NOT present, it is assumed that the User (represented by the OBO token or WSS Token) is trying to access the RelyingParty.
When issuing a token, Oracle Security Token Service will determine for which Relying Party that token is created, and it will then evaluate if the client is authorized to request the token for that Relying Party. In order to issue a token, a Token Issuance Policy must be created with the resource involved in the operation, and with possibly a constraint. At runtime if the policy evaluation is successful, the token will be issued.
IAM Suite Token Issuance Policy
Figure 20-13 presents IAM Suite Token Issuance Policy in the IAM Suite application domain. Use Implied Constraints is checked by default, which allows access in the absence of any authorization constraints of a particular class. By default, there are no explicit constraints defined.
Figure 20-13 IAM Suite Token Issuance Policy and Resource URLs
You can add constraints to this Token Issuance Policy.
The Token Issuance Policy allows the Administrator to define "Allow" and "Deny" constraints on the policy. Each Token Issuance Policy can contain one or more constraints that determine whether access to the requested resource should be granted or denied:
An Allow type condition specifies who is authorized to access a protected resource.
Only partners and users listed in the Constraint are granted access; everyone else is denied access to the resource.
A Deny type condition specifies explicitly who is denied access to the protected resource.
Only partners and users listed in the Constraint are denied access; everyone else is granted access to the resource.
Note:
When adding User constraints, the identity store from which the users are to be chosen can be selected from a list. Ensure that you choose the Default User Identity Store, which is the only one used by Oracle Security Token Service.
Managing Token Issuance Policies and Constraints is similar to managing Authorization Policies and Constraints. Figure 20-4 shows the Constraints tab of a Token Issuance Policy.
Figure 20-14 Token Issuance Policies and Constraints
Table 20-13 describes the Token Issuance Policy and Constraint requirements.
Table 20-13 Constraints Tab: Token Issuance Policy
Element | Description |
---|---|
Name |
A unique name for this Token Issuance Policy. |
Description |
Optional. |
Use Implied Constraints |
Enabled by default, which allows access in the absence of any authorization constraints of a particular class. |
Constraints Tab |
|
Name |
A unique name for this Constraint, which you assign when you add a new constraint. A dialog box opens where you enter the name. |
Class |
Only Token Requester Identity is allowed for Token Issuance Policy constraints. You choose this in the Add Constraint dialog box. |
Type |
Choose a Condition:
|
Selected Users and Groups |
|
Add |
Choose from the following populations:
|
Entity Name |
The name of the User or Group, as defined in the selected User Identity Store. |
Entity Type |
The type of entity you want to locate during a search to add identifies to the constraint: User, or Group. |
Store Name |
Choose the name of the User Identity Store to search for users or groups to populate the constraint. Remember, Oracle Security Token Service uses only the Default Identity Store. |
Users with valid Administrator credentials can use the following procedure to add a Token Issuance Policy and Constraints to an Application Domain. When adding resources to this policy, you might want to add the UnknownRP and MissingRP resources.
Prerequisites
The application domain must already exist.
Note:
You can add Token Issuance Policies to the IAM Suite Application Domain.
To manage Token Issuance Policies and constraints
Open the Application Domain, as follows:
Add a Token Issuance Policy:
In the Application Domain tree, click the Token Issuance Policies node and then click the Add (+) button to open a fresh page.
On the Token Issuance Policy page, enter a unique name and optional description.
On the Resources tab, click the Add (+) button and choose the desired resource from those listed. For example: TokenServiceRP:URL
Select the Token Issuance Policy to assign to this new resource
Click the Apply button at the top of the page to submit changes (or click Revert to undo your changes).
See Also: "Managing Token Issuance Policies and Constraints".
Add Constraints to a Policy:
Click the Constraints tab, then click the Add button on the Constraints tab to display the Add Constraint window.
Enter a unique name for this constraint in the dialog box.
Choose Token Requester Identity from the Class list.
Choose the Allow or Deny condition.
Click Add Selected.
Add Constraints Details:
Click the Constraint name to display Constraints: Details.
Click the Add button and choose either Add Identifies or Add Partners.
Add Partners: Enter your search criteria (or click the arrow key beside the field to find all partners), then choose one or more results and click Add Selected to populate the constraint.
Add Identities: In the Search window set the Store Name, Choose an Entity Type (All, User, or Group), and provide an Entity Name choose one or more results and click Add Selected to populate the constraint.
Click the Apply button at the top of the page to submit the policy and constraints.
Find (or Add) TokenServiceRP Resources in the Application Domain: See "Managing TokenServiceRP Type Resources".
A Token Issuance Policy defines the rules under which a token can be issued for a resource (Relying Party Partner) based on the client's identity, with the client either being a Requester Partner or an end user.
When issuing a token, Oracle Security Token Service will determine for which Relying Party that token is created, and it will then evaluate if the client is authorized to request the token for that Relying Party.
Note:
In order to issue a token, a Token Issuance Policy must be created with the resource involved in the operation and, possibly, with a constraint. At run time if the policy evaluation is successful, the token will be issued.
The resource(s) in a policy can be:
A TokenServiceRP type resource based on the Relying Party Partner ID.
The pre-existing UnknownRP resource which is needed when Oracle Security Token Service is not able to map the Service URL referenced in the AppliesTo
element of the WS-Trust request to an Oracle Security Token Service Relying Party Partner entry.
The pre-existing MissingRP resource which is needed when the AppliesTo
element of the WS-Trust request is missing.
Note:
Both the MissingRP and UnknownRP are defined in the IAM Suite Application Domain.
A resource of type TokenServiceRP, Figure 20-15, represents an Oracle Security Token Service Relying Party Partner defined in the Oracle Security Token Service Partner Store.
Figure 20-15 Pre-defined Resource Type: TokenServiceRP
Resources of type TokenServiceRP are used in Token Issuance Policies, which are evaluated when Oracle Security Token Service issues tokens at run time.
For more information, see:
About Managing TokenServiceRP Type Resources in Oracle Access Manager
Managing TokenServiceRP Type Resources in Application Domains
Use the Search controls for the application domain to locate resources of a specific type within the domain. Figure 20-16 shows the search controls for the IAM Suite resources. Resource Type TokenServiceRP is the search criteria. The Search Results table lists all resources of this type within the application domain.
Figure 20-16 Search: Resource Type TokenServiceRP in Application Domain
The TokenServiceRP resources in this domain include those provided out of the box, and described earlier:
UnknownRP resource
MissingRP resource
Users with valid Administrator credentials can use the following procedure to add TokenServiceRP resources to an application domain.
Note:
If AppliesTo
is present in the RST but the requester could not be mapped, use the TokenServiceRP:UnknownRP
resource.
If AppliesTo
is not present, use TokenServiceRP:MissingRP
, otherwise select the appropriate resource.
To manage TokenServiceRP Resources
Open the Application Domain, as follows:
Add TokenServiceRP Resource to the Application Domain:
Click the New Resource button on the Application Domain Search page.
Specify the Resource Type as TokenServiceRP.
Enter a Resource URL that is the Relying Party ID for whom the token issuance policy will be defined.
Click the Apply button at the top of the page to submit this and dismiss the confirmation window.
See Also:"Adding Resource Definitions to an Application Domain".
Find TokenServiceRP Resources:
Open the Resources node to display the Search controls.
From the Resource Type list, choose TokenServiceRP, and click Search.
Review the Search Results table and click a name to open the Resource Definition.