17 Oracle Security Token Service Implementation Scenarios

This chapter introduces several Oracle Security Token Service implementation and processing scenarios. Regardless of scenario specifics, there are many similarities in both configuration tasks and token handling. This chapter provides the following sections:

• Prerequisites

• Typical Token Ecosystem

• Scenario: Identity Propagation with the OAM Token

• Scenario: Web Service Security With On Behalf Of Username Token

17.1 Prerequisites

"Introduction to Oracle Security Token Service".

17.2 Typical Token Ecosystem

The abstract model chosen here is of interest because of the requirements placed on Oracle Security Token Service to support such models.

The phrase security token ecosystem is used here to represent a typical environment where security tokens are in use. In such environments the security token, based on the security model required for the environment, could be used to serve an end goal such as to enable brokered trust or single-sign-on and so on. Regardless of the environment and the type of security token, several aspects are common across all models, as shown and described here.

Figure 17-1 illustrates a typical token ecosystem, which includes: Token Issuing Authority, Token Requestor, Token Consumer, and the Security Token.

Figure 17-1 Typical Token Ecosystem

Description of "Figure 17-1 Typical Token Ecosystem"

Actors and Process overview: In a typical token ecosystem

1. The Token Requestor places a request for a security token at the Token Issuing Authority.

   This security token is required to communicate and request access to a service provided by a Service Provider (a Token Consumer who accepts the security token).

   • A Token Requestor could be a Partner of the Token Issuing Authority (generally registered with the Token Issuing Authority).

   • A Token Requestor could be an End User (generally not registered with the Token Issuing Authority).

2. The Token Issuing Authority (OAM and OSTS, for example) receives and processes the security token request and returns a security token, as follows:

   • Authenticate the input credentials.

   • Authorize the security token request based on a Token Issuance Policy that specifies which Token Requestors are authorized to request a security token for a given Token Consumer.

3. The Token Consumer (typically a service provider).

   • Accepts the security token as part of the service request and provides service based on the validity of the input security token.

   • Validates the input security token with Token Issuing Authority.

   Note:

   A Token Consumer is typically a registered Partner of the Token Issuing Authority. A Token Consumer is also known as a Relying Party, because it trusts and relies on the Token Issuing Authority for Token Requestor authentication. Token Consumers (Relying Party Partner) are Web Applications (for OAM, OSTS is the Token Issuing Authority) or STS Relying Party Web Services.

17.3 Scenario: Identity Propagation with the OAM Token

This is a deployment where the user's Identity information needs to be propagated from a Web application to a Web service provider. The Web service provider can reside in the same security domain as the web application or in a different security domain.

Figure 17-2 Identity Propagation with the OAM Token

Description of "Figure 17-2 Identity Propagation with the OAM Token"

Identity propagation means that the original user context becomes visible outside its original security tier or domain boundaries. The user security context is propagated across different security tiers or domains to support tier-specific or domain-specific security needs such as step-up authentication, authorization, audit and/or internal application-specific business logic.

ID Propagation is said to occur in a distributed processing of a request when the identity context established in the first node is propagated to subsequent nodes to enable further processing of the request in the context of that identity.

ID Propagation can be achieved in several ways. One of them is based on a brokered-trust model where an ID provider acts as a trust-broker for ID Assertions. The discussion here is pertains to this model.

Figure 17-3 illustrates an ID Propagation scenario in a brokered-trust model, where a user-facing application needs to request processing by a backend service application in the context of the end user. To bring out the main aspects of ID propagation all other interaction and relationship details between end user, application, and backend service application are ignored.

Figure 17-3 Process Flow During Identity Propagation

Description of "Figure 17-3 Process Flow During Identity Propagation"

Actors and Process overview: Identity Propagation

1. The ID Assertion Token Requestor (an End User-Facing Application), upon end user access, requests authentication and ID Assertion Token at the identity Provider.

   Note:

   Examples of ID Assertion Token Requestors include Web applications that are protected by OAM. The ID Assertion Token request could be either implicit or could be driven by a policy at the ID Provider.

2. The ID Provider (Oracle Security Token Service) processes the request and returns an Authentication Token and an ID Assertion Token. An ID Assertion Token, in itself, does not represent a user session and cannot be used independently to request direct access to a resource or service.

3. The ID Assertion Token Requestor uses this Token later, during the end user session, as part of a backend service processing request (on behalf of the end user).

4. The ID Assertion Token Consumer (Oracle Security Token Service), as part of the request processing, first validates the ID Assertion Token and then (on validation success) processes the request in the context of the end user Identity

For more information, see the following topics:

• Component Processing: Identity Propagation with the OAM Token

• RST Attributes and Run Time Processing

• Configuration Requirements: Identity Propagation with the OAM Token

17.3.1 Component Processing: Identity Propagation with the OAM Token

Figure 17-4 illustrates a typical deployment topology for Identity propagation using Oracle Security Token Service with Oracle Access Manager.

Figure 17-4 Identity Propagation Deployment

Description of "Figure 17-4 Identity Propagation Deployment"

Figure 17-5 illustrates a processing of Identity propagation using Oracle Security Token Service with Oracle Access Manager. Details follow the figure.

Figure 17-5 Identity Propagation Processing

Description of "Figure 17-5 Identity Propagation Processing "

Process overview: Component interactions for Identity Propagation

1. User attempts to access a protected resource.

2. Webgate is protecting the resource; it sends request to Oracle Access Manager for authentication and authorization.

3. Oracle Access Manager authenticates the user using the policy configured for this Webgate Application Domain. It sees the response type "IDENTITY_ASSERTION" is configured for this Webgate, so it generates ID Assertion token as well.

4. Oracle Access Manager sends authentication and ID assertion token to Webgate

5. Webgate processes the response; sets ID assertion token to the header; (OHS where Webgate is installed on) then redirect the request to the WLS that hosts the resource.

6. IAP (Oracle Access Manager Identity Asserter on WebLogic Server) sees OAM_IDENTITY_ASSERTION header is set, processes the headers, then sets ID assertion token to Subject's private credential as OamIdentity.

7. When the resource is finally accessed, a Web Service Client can then obtain the ID assertion token from current user's Subject, generates a OnBehalfOf (OBO) token with it, then creates and sends Request Security Token (RST) to OSTS.

8. Oracle Security Token Service sees the ID assertion Token inside OBO token, it sends validation/authentication request to Oracle Access Manager using Oracle Access Manager library.

9. Oracle Access Manager validates and authenticates the ID Assertion Token, then sends response (user identity) to Oracle Security Token Service.

10. Oracle Security Token Service uses this user identity to do further processing: policy evaluation, token issuance, and so on. It then generates Request Security Token Response.

11. Oracle Security Token Service sends Request Security Token Response to the client, which can then use the token inside the Request Security Token Response (RSTR) to create a web service request to access a service hosted on a relying party.

17.3.2 RST Attributes and Run Time Processing

For an incoming Request Security Token (RST) with the following attributes, Oracle Security Token Service must be configured to process a request and issue a token):

RST Attributes for Identity Propagation with the OAM Token

• The SOAP header contains a Username token referencing a WS Requester. The Username token contains at least a username and a password.

• The SOAP body contains a WS-Trust RST message

• The RST contains a OAM ID Propagation token in the OnBehalfOf field referencing a user in LDAP. The token included in the OnBelahfOf element is a BinarySecrityToken, whose text value is the Base 64 encoded format of the OAM Session Propagation Token, and whose ValueType attribute is http://xmlns.example.com/am/2010/11/token/session-propagation and whose EncodingType attribute is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soapmessage-security-1.0#Base64Binary

• The RST can possibly contain an AppliesTo field holding a URL pointing to the endpoint of the Relying Party Web Service

• The RST can possibly contain a TokenType field holding the type of token that needs to be returned

• The RST can possibly contain an Entropy field holding random data that will be used when creating the SecretKey when a symmetric proof key is required in the SAML Assertion

• The RST can possibly contain a UseKey field holding the certificate or public key to be used as an asymmetric proof key in the SAML Assertion, but this field will be ignored by OSTS

Process overview: Identity Propagation with the OAM Token

1. Client prepares the request by:

   1. Creating the SOAP message

   2. Creating the Username token referencing the client and including it in the SOAP header

   3. Creating the WS-Trust RST message

   4. Creating the OAM ID Propagation token referencing the user and including it in the OnBehalfOf field of the RST

   5. Including the RST message in the SOAP body

2. Client sends the message to the OSTS, to an endpoint protected by a WS-Security User Name Token (UNT) Policy, with that endpoint being mapped to an OSTS WSS Validation Template.

3. OSTS will process the incoming request

4. OSTS validates the token included in the SOAP header by using the settings contained in the WS-Security Validation Template:

   1. Validates the format of the Username token

   2. Validates the credentials contained in the Username token against the OSTS Partner store, thus mapping this token to a Requester Partner

   3. Knowing the Requester Partner, OSTS will retrieve the Requester Partner Profile associated with this Requester

5. OSTS then validates the token present in the OnBehalfOf field:

   1. Determines the type of token present in the OnBehalfOf field

   2. Retrieves the WS-Trust Validation Template to be used for OAM Token Type, from the Requester Partner Profile

   3. Validates the format of the OAM token Validates the OAM token, and maps the token to a user

   4. Creating the OAM ID Propagation token referencing the user and including it in the OnBehalfOf field of the RST

6. OSTS then examines the AppliesTo field:

   • If present, OSTS will attempt to map the AppliesTo URL to a Relying Party Partner, using the WS Endpoint Mapping of the Relying Party Partner. If the mapping is successful, then the AppliesTo field has been mapped to a Relying Party Partner, and OSTS will retrieve the Relying Party Partner Profile from this Partner. If mapping was not successful, then the AppliesTo field could not be mapped to a Relying Party Partner, and OSTS will retrieve the Default Relying Party Partner Profile from the Requester Partner Profile

   • If absent, OSTS will retrieve the Default Relying Party Partner Profile from the Requester Partner Profile

7. OSTS then examines the TokenType field:

   • If present, OSTS will map the TokenType string to a local token type value using the Requester Partner Profile, and it will then use the Relying Party Partner Profile to retrieve the Issuance Template to be used to create the outgoing token

   • If absent, OSTS will retrieve the default token type from the Relying Party Partner Profile, and it will then use the Relying Party Partner Profile to retrieve the Issuance Template to be used to create the outgoing token

8. OSTS will perform an Authorization evaluation to check that the Requester Partner is authorized to request a token for the Relying Party referenced in the flow (see Authorization Trust Policy for more information)

9. OSTS will then create the token

   • If the token to be issued is of SAML type, then the Issuance Template will list how to populate the NameID, the Relying Party Partner Profile will list which attributes need to be sent in the token, the Issuance Template will indicate whether or not to translate the names and values of the attributes, the Issuance Template will indicate whether or not to sign/encrypt the token.

   • If the token to be issued if of SAML type, the OSTS server will examine the KeyType to determine the Subject Confirmation Method of the Assertion. If it is missing, it will use the Default Confirmation Method from the Issuance Template

10. OSTS will create the Response that the client will process:

    1. Creates the WS-Trust RSTRC

    2. Includes the returned token

    3. Includes proof key if necessary

17.3.3 Configuration Requirements: Identity Propagation with the OAM Token

This topic walks through the configuration requirements for the identity propagation scenario. It includes:

• Configuration overview: Identity Propagation with the OAM Token

• WebLogic Server Identity Assertion Providers

• Oracle Access Manager Identity Asserter Details

• LDAP Authentication Provider Details

• Default Identity Store Configuration

• Token Issuance Policy

• Authentication Policy for Identity Assertion by Webgate

• Endpoint Configuration

• Issuance Template Configuration

• Partner Configuration: Requester

• Partner Profile: Relying Party

• Partner Profile: Requester

• Validation Template for WS-TRUST

• Cookies and Headers (Truncated)

• Request Security Token Sent By the Client (Truncated)

• Request Security Token Response sent by the OSTS Server (Truncated)

Configuration overview: Identity Propagation with the OAM Token

Following is an overview of the Identity Propagation environment and implementation tasks:

• A custom application module that will act as a client to:

  • Retrieve the OAM Session Propagation token from the HTTP request

  • Send a WS-Trust request to the Oracle Security Token Service server with OAM Session Propagation token as the OnBehalfOf element

• A web application that will be protected by Webgate and will invoke the client web application that will send a WS-Trust request to Oracle Security Token Service

• OSTS Server URL: http://yourhost.domain.com:14100/sts/<endpoint>

  Note:

  Replace <endpoint> with the path configured in the STS Endpoints section.

• An OHS 11g with Webgate protecting the web application

  Provision (register) a Webgate (11g or 10g) to protect the application deployed in WebLogic Server. The OAMSuite application domain is pre-seeded and delivered with OAM 11g. When you provision an OAM Agent to use this (or another existing) application domain, decline the option of having policies automatically created.

  Reverse Proxy mapping for Webgate in the OHS Server mod_wl_ohs.conf, is shown here.

  
  

The following Oracle Security Token Service configuration is required to implement token processing for identity propagation:

• One Requester Partner Profile

• One Relying Party Partner Profile

• One Issuance Template

• One WS-Trust Validation Template

• OSTS Endpoint

• An LDAP server is required for Oracle Security Token Service to map the Username token referencing the user to an LDAP User record, and thus use that record to populate the outgoing token.

  Ensure that the desired LDAP server is configured as the Default Identity Store for Oracle Access Manager with Oracle Security Token Service.

WebLogic Server Identity Assertion Providers

Deploy the Identity Assertion Providers jar. The Oracle Access Manager Identity Asserter is available in the following path with Oracle Fusion Middleware installed:

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovider.war

Copy oamauthenticationprovider.war to the following location:

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war  

Figure 17-6 illustrates the required WebLogic Server Identity Assertion Providers configuration for this scenario.

Figure 17-6 Required v1.0 WebLogic Server Identity Assertion Providers

Description of "Figure 17-6 Required v1.0 WebLogic Server Identity Assertion Providers"

Oracle Access Manager Identity Asserter Details

The IAP-OSTS identity asserter must be the first, and set using the REQUIRED Control flag. The Active Types should be set as ObSSOCookie and OAM_REMOTE_USER, with an SSO Header name of OAM_REMOTE_USER1.

Figure 17-7 illustrates the configuration.

Figure 17-7 IAP-OSTS Details

Description of "Figure 17-7 IAP-OSTS Details"

LDAP Authentication Provider Details

Create the Authenticator for the LDAP with the OPTIONAL JAAS flag. This will point to the Default System Store of Oracle Access Manager, which provides the OAM token.

Figure 17-8 illustrates this.

Figure 17-8 LDAP Provider: IAP-DSEE

Description of "Figure 17-8 LDAP Provider: IAP-DSEE "

Default Identity Store Configuration

Figure 17-9 illustrates the Default Identity Store configuration within Oracle Access Manager Console.

Figure 17-9 Default Identity Store Defined in Oracle Access Manager

Description of "Figure 17-9 Default Identity Store Defined in Oracle Access Manager"

Token Issuance Policy

Create the Token Issuance Policy for the resource URL within the IAM Suite Application Domain, as shown in Figure 17-10.

Figure 17-10 Token Issuance Policy for Identity Propagation

Description of "Figure 17-10 Token Issuance Policy for Identity Propagation "

Authentication Policy for Identity Assertion by Webgate

Confirm that the Identity Assertion box is checked in the Authentication Policy within the IAM Suite Application Domain. This enables Webgate to perform Identity Assertion for protected resources, as shown in Figure 17-10.

Figure 17-11 Authentication Policy for Identity Assertion by Webgate

Description of "Figure 17-11 Authentication Policy for Identity Assertion by Webgate"

Endpoint Configuration

The /wss10user Endpoint is needed, as shown in Figure 17-12. This endpoint is protected by the default WS-Security Validation Template. This is the one that will be used in the Web application to post the RST.

Figure 17-12 /wssuser Endpoint for Identity Assertion

Description of "Figure 17-12 /wssuser Endpoint for Identity Assertion"

Issuance Template Configuration

The Issuance Template requires the following configuration for Identity Propagation:

• Name: iap-issuance-template

• Description: Custom issuance template

• Token Type: SAML 2.0

• Signing Key Id: osts_signing

• Description: Custom issuance template

Partner Configuration: Requester

Create a new Requester Partner configuration for Identity Propagation with the OAM token as follows:

• Partner Name: iap-request-partner

• Requester Type: STS_REQUESTER

• Partner Profile: iap-requestor-profile

• Description: Custom requester

• Trusted

• Username Token Authentication

  • Username <enter username used by the Web Service Client>

  • Password <enter password used by the Web Service Client>

  • Confirm Password <enter password used by the Web Service Client>

• Identity Attribute values for:

  • httpbasicusername

  • sslclientcertdn

Partner Profile: Relying Party

Create a new Relying Party Profile for Identity Propagation as follows:

• Profile ID: iap-relyingparty-profile

• Description: iap-issuance-template

• Default Token Type: SAML 2.0

• Default Template: iap-issuance-template

Partner Profile: Requester

Create a new Requester Profile for Identity Propagation as follows:

• Profile ID: iap-requestor-profile

• Description: iap-requestor-profile partner profile

• Default Relying Party Profile: iap-relyingparty-profile

Validation Template for WS-TRUST

The Validation Template requires the following configuration for Identity Propagation:

• Validation Template Name: iap_wstrust_validation_template

• Description: iap_wstrust_validation_template

• Token Protocol: WS-Trust

• Token Type: OAM

• Timestamp Lifespan:

This completes the configuration requirements for the Identity Propagation with OAM Token scenario.

17.3.4 Testing Your Implementation

Following configuration, you can try to access the resource to confirm your implementation is working properly.

Webgate should redirect to the OAM Server if there is no existing session for the user Upon successful authentication, you should be able to see the RST and RSTR sent by the STS server.

Cookies and Headers (Truncated)

Request Security Token Sent By the Client (Truncated)

Here is a (truncated) request for security token sent by the client.

Request Security Token Response sent by the OSTS Server (Truncated)

Here is a (truncated) response to the RST sent by the OSTS Server.

17.4 Scenario: Web Service Security With On Behalf Of Username Token

This section provides the following topics:

• Component interactions for Identity Propagation with Username Token

• RST Attributes and Processing for Identity Propagation with a Username Token

• Configuration Requirements: Identity Propagation with the Username Token

17.4.1 Component interactions for Identity Propagation with Username Token

Process overview: Component interactions for Identity Propagation

1. User attempts to access a protected resource.

2. User is authenticated.

3. The WebLogic container sets the user's identity into a Subject for this session.

4. When the resource is finally accessed, a Web Service Client can then obtain the user's identity from current user's Subject, generates a OnBehalfOf (OBO) token with it, then creates and sends Request Security Token (RST) to OSTS.

5. Oracle Security Token Service authenticates the Web Service Client as a Requester Partner.

6. Oracle Security Token Service sees the Username Token inside OBO token, it maps the maps the user's identity to a user record in LDAP.

7. Oracle Security Token Service then generates Request Security Token Response.

8. Oracle Security Token Service sends Request Security Token Response to the client, which can then use the token inside the Request Security Token Response (RSTR) to create a web service request to access a service hosted on a relying party.

17.4.2 RST Attributes and Processing for Identity Propagation with a Username Token

For an incoming Request Security Token (RST) with the following attributes, Oracle Security Token Service must be configured to process a request and issue a token.

RST Attributes for Identity Propagation with a Username Token

• The SOAP header contains a Username token referencing a WS Requester. The Username token contains at least a username and a password.

• The SOAP body contains a WS-Trust RST message.

• The RST contains a Username Token in the OnBehalfOf field referencing a user in LDAP.

• The RST can possibly contain an AppliesTo field holding a URL pointing to the endpoint of the Relying Party Web Service.

• The RST can possibly contain a TokenType field holding the type of token that needs to be returned.

• The RST can possibly contain an Entropy field holding random data that will be used when creating the SecretKey when a symmetric proof key is required in the SAML Assertion.

• The RST can possibly contain a UseKey field holding the certificate or public key to be used as an asymmetric proof key in the SAML Assertion, but this field will be ignored by Oracle Security Token Service.

Process overview: Identity Propagation with the OAM Token

1. Client prepares the request by:

   • Creating the SOAP message

   • Creating the Username token referencing the client and including it in the SOAP header.

   • Creating the WS-Trust RST message.

   • Creating the Username Token referencing the user and including it in the OnBehalfOf field of the RST.

   • Including the RST message in the SOAP body.

2. Client sends the message to the Oracle Security Token Service, to an endpoint protected by a WS-Security User Name Token (UNT) Policy, with that endpoint being mapped to an Oracle Security Token Service WSS Validation Template.

3. Oracle Security Token Service will process the incoming request.

4. Oracle Security Token Service validates the token included in the SOAP header by using the settings contained in the WS-Security Validation Template:

   • Validates the format of the Username token.

   • Validates the credentials contained in the Username token against the Oracle Security Token Service Partner store, thus mapping this token to a Requester Partner.

   • Knowing the Requester Partner, Oracle Security Token Service will retrieve the Requester Partner Profile associated with this Requester.

5. Oracle Security Token Service then validates the token present in the OnBehalfOf field:

   • Determines the type of token present in the OnBehalfOf field.

   • Retrieves the WS-Trust Validation Template to be used for Username Token Type, from the Requester Partner Profile.

   • Validates the Username Token, and maps the token to a user.

6. Oracle Security Token Service then examines the AppliesTo field:

   • If present, Oracle Security Token Service will attempt to map the AppliesTo URL to a Relying Party Partner, using the WS Endpoint Mapping of the Relying Party Partner. If the mapping is successful, then the AppliesTo field has been mapped to a Relying Party Partner, and Oracle Security Token Service will retrieve the Relying Party Partner Profile from this Partner. If mapping was not successful, then the AppliesTo field could not be mapped to a Relying Party Partner, and Oracle Security Token Service will retrieve the Default Relying Party Partner Profile from the Requester Partner Profile.

   • If absent, Oracle Security Token Service will retrieve the Default Relying Party Partner Profile from the Requester Partner Profile.

7. Oracle Security Token Service then examines the TokenType field:

   • If present, Oracle Security Token Service will map the TokenType string to a local token type value using the Requester Partner Profile, and it will then use the Relying Party Partner Profile to retrieve the Issuance Template to be used to create the outgoing token.

   • If absent, Oracle Security Token Service will retrieve the default token type from the Relying Party Partner Profile, and it will then use the Relying Party Partner Profile to retrieve the Issuance Template to be used to create the outgoing token.

8. Oracle Security Token Service will perform an Authorization evaluation to check that the Requester Partner is authorized to request a token for the Relying Party referenced in the flow (see Authorization Trust Policy for more information).

9. Oracle Security Token Service will then create the token:

   • If the token to be issued is of SAML type, then the Issuance Template will list how to populate the NameID, the Relying Party Partner Profile will list which attributes need to be sent in the token, the Issuance Template will indicate whether or not to translate the names and values of the attributes, the Issuance Template will indicate whether or not to sign/encrypt the token.

   • If the token to be issued if of SAML type, the Oracle Security Token Service server will examine the KeyType to determine the Subject Confirmation Method of the Assertion. If it is missing, it will use the Default Confirmation Method from the Issuance Template.

10. Oracle Security Token Service will create the Response that the client will process:

    • Creates the WS-Trust RSTRC

    • Includes the returned token

    • Includes proof key if necessary

17.4.3 Configuration Requirements: Identity Propagation with the Username Token

This topic walks through the configuration requirements for the identity propagation scenario. It includes:

• Configuration overview: Identity Propagation with the Username Token

• Default Identity Store Configuration

• Token Issuance Policy

• Endpoint Configuration

• Issuance Template Configuration

• Partner Configuration: Requester

• Partner Profile: Relying Party

• Partner Profile: Requester

• Validation Template for WS-TRUST

• Example 17-1, "Sample exchange: Request Security Token Sent By the Client"

• Example 17-2, "Request Security Token Response sent by the OSTS Server"

Configuration overview: Identity Propagation with the Username Token

Following is an overview of the Identity Propagation environment and implementation tasks:

• A web application where the user will request. This web application will authenticate the user, then attempt to send a SOAP message to a remote Web Service Provider. As part of that SOAP exchange, the WS-Security client will download the WS-Security policy of the Web Service Provider, connect to the Oracle Security Token Service to retrieve the token requested by the Web Service Provider, send the Security Token with the SOAP message to the Web Service Provider.

• OSTS Server URL: http://yourhost.domain.com:14100/sts/<endpoint>

  Note:

  Replace <endpoint> with the path configured in the STS Endpoints section.

The following Oracle Security Token Service configuration is required to implement token processing for identity propagation:

• One Requester Partner Profile

• One Relying Party Partner Profile

• One Issuance Template

• One WS-Trust Validation Template

• Oracle Security Token Service Endpoint

• An LDAP server is required for Oracle Security Token Service to map the Username token referencing the user to an LDAP User record, and thus use that record to populate the outgoing token.

• Ensure that the desired LDAP server is configured as the Default Identity Store for Oracle Access Manager with Oracle Security Token Service.

Default Identity Store Configuration

Figure 17-13 illustrates the Default Identity Store configuration within Oracle Access Manager Console.

Figure 17-13 Default Identity Store Defined in Oracle Access Manager

Description of "Figure 17-13 Default Identity Store Defined in Oracle Access Manager"

Token Issuance Policy

Create the Token Issuance Policy for the resource URL within the IAMSuite Application Domain, as shown in Figure 17-14.

Figure 17-14 Token Issuance Policy for Identity Propagation

Description of "Figure 17-14 Token Issuance Policy for Identity Propagation"

Endpoint Configuration

The /wss11user Endpoint is needed, as shown in Figure 17-15. This endpoint is protected by the default WS-Security Validation Template. This is the one that will be used in the Web application to post the RST.

Figure 17-15 /wss11user Endpoint for Identity Assertion

Description of "Figure 17-15 /wss11user Endpoint for Identity Assertion"

Issuance Template Configuration

The Issuance Template requires the following configuration for Identity Propagation:

• Name: saml-issuance-template

• Description: SAML issuance template

• Token Type: SAML 2.0

• Signing Key Id: osts_signing

Partner Configuration: Requester

Create a new Requester Partner configuration for Identity Propagation with the OAM token as follows:

• Partner Name: requester-partner

• Partner Type: Requester

• Partner Profile: requester-profile

• Description: Requester

• Trusted

• Username Token Authentication

  • Username <enter username used by the Web Service Client>

  • Password <enter password used by the Web Service Client>

  • Confirm Password <enter password used by the Web Service Client>

• Identity Attribute values for:

  • httpbasicusername

  • sslclientcertdn

Partner Profile: Relying Party

Create a new Relying Party Profile for Identity Propagation as follows:

• Profile ID: relying-party-profile

• Description: Relying Party Profile

• Default Token Type: SAML 2.0

• Issuance Template: iap-issuance-template for SAML 2.0

Partner Profile: Requester

Create a new Requester Profile for Identity Propagation as follows:

• Profile ID: requester-profile

• Description: Requester Partner Profile

• Default Relying Party Profile: relying-party-profile

Validation Template for WS-TRUST

The Validation Template requires the following configuration for Identity Propagation:

• Validation Template Name: username_wstrust_validation_template

• Description: Username WS-Trust Template

• Token Protocol: WS-Trus

• Token Type: Username

• Timestamp Lifespan: 600

• Enable Credential Validation: unchecked

• Token Mapping:

  • Map Token To User: checked

  • Enable Simple User Mapping: checked

  • Datastore Attribute: uid

This completes the configuration requirements for the Identity Propagation with Username Token scenario.

Example 17-1 Sample exchange: Request Security Token Sent By the Client

Here is a request for security token sent by the client.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
<SOAP-ENV:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken><wsse:Username>requester-test</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcome1</wsse:Password></wsse:UsernameToken></wsse:Security>
<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action></SOAP-ENV:Header>
<SOAP-ENV:Body><wst:RequestSecurityToken xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"><wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:OnBehalfOf>
<wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:Username>user-alice</wsse:Username>
</wsse:UsernameToken></wst:OnBehalfOf></wst:RequestSecurityToken></SOAP-ENV:Body></SOAP-ENV:Envelope>

Example 17-2 Request Security Token Response sent by the OSTS Server

Here is a response to the RST sent by the OSTS Server.

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
</env:Header><env:Body><wst:RequestSecurityTokenResponseCollection xmlns:ns6="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wst:RequestSecurityTokenResponse><wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType><wst:RequestedSecurityToken><saml:Assertion AssertionID="id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-" IssueInstant="2011-04-22T18:48:05Z" Issuer="adc2110618.us.example.com" MajorVersion="1" MinorVersion="1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saml:Conditions NotBefore="2011-04-22T18:48:05Z" NotOnOrAfter="2011-04-22T19:48:05Z"/><saml:AttributeStatement><saml:Subject><saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[e-mail]</saml:NameIdentifier><saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod></saml:SubjectConfirmation>
</saml:Subject><saml:Attribute AttributeName="sn" AttributeNamespace="urn:oracle:security:fed:attrnamespace"><saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">user-alice-last</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement><dsig:Signature><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><dsig:Reference URI="#id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>1GF2ZT9h+gs8sxyO+/yG/N6jxk8=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo>
<dsig:SignatureValue>InZVb5aRM5+KKI1VqXg9HiIgLjKyGm0VkD6sMJ/8SIbFbbxuNm7Mnky5W35p2P0c5bCPRx02uzLEE4KhLkyM2GsLsVaDNkRztGMphQW/Mcg7DprJIEyR2OYMYDOQSipa/k2K98C4zO/RNivo1KvyJsd6a3h6CBHwoO1RKip039w=</dsig:SignatureValue>
<dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIIB/DCCAWWgAwIBAgIBCjANBgkqhkiG9w0BAQQFADAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wHhcNMTEwNDE5MTUxNTI2WhcNMjEwNDE2MTUxNTI2WjAjMSEwHwYDVQQDExhhZGMyMTEwNjE4LnVzLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJnSxVc86TGcwewieaueIVG33C3Qouve6HuJxHsoM8cRRkJcmv+0auyvDLJfYAEOfHo5OsF4+za11iNPln9ZFaOjUy/Y8JC0kSVxatgU36RveIrpOJvp978Oa6IlMNUtdFf8q3TrsizspE2hnbLY+0SMofgnAPcJEKPxkd6b0b0ZAgMBAAGjQDA+MAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/BAUDAwfYADAdBgNVHQ4EFgQU47ZqWHgTOmZO67uw4YzsbrRMNOswDQYJKoZIhvcNAQEEBQADgYEAH0QIHaLMN/7hD2VP0SLOCtNdEmY5IqLY1CDW+GpUZZ9e+MCgE/rvr34566D9Q8lvET6T9u+sg3h+hSkb3gE4a4wgShH/V7nfHzx8ZntlxccvCZK6ePVDMt0Lfj2iVnE7IJxou4bO0w0m9DrvyKop7ncnSEzaVpxIZgCDo7+8Zdw=</dsig:X509Certificate>
</dsig:X509Data></dsig:KeyInfo></dsig:Signature></saml:Assertion></wst:RequestedSecurityToken><wst:RequestedAttachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedAttachedReference>
<wst:RequestedUnattachedReference><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">id-1LNkSUVcpbH7O0oQwbHJ5JOd5fs-</wsse:KeyIdentifier></wsse:SecurityTokenReference></wst:RequestedUnattachedReference>
<wst:Lifetime><wsu:Created>2011-04-22T18:48:05Z</wsu:Created><wsu:Expires>2011-04-22T19:48:05Z</wsu:Expires></wst:Lifetime></wst:RequestSecurityTokenResponse></wst:RequestSecurityTokenResponseCollection></env:Body></env:Envelope>