42.2 Scenario: Identity Propagation with the Access Manager Token

While supporting security tier-specific or domain-specific security requirements, the user's Identity information becomes visible and gets propagated across different tiers or domains. To achieve Identity propagation using Security Token Service with Access Manager, brokered-trust model can be used.

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 42-2 Identity Propagation with the OAM Token

Description of "Figure 42-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 42-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 42-3 Process Flow During Identity Propagation

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

42.2.1 Actors and Process Overview: Identity Propagation

In a typical process that deals with identity propagation, ID Assertion Token Requestor, ID Provider, and ID Assertion Token Consumer are involved.

The following overview enables you to familiarize with any actors and processes that deal with 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 (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 (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

See About Component Processing: Identity Propagation with the OAM Token.

See Request Security Token Attributes and Run Time Processing.

See Configuration Requirements: Identity Propagation with the OAM Token.

42.2.2 About Component Processing: Identity Propagation with the OAM Token

Identity propagation can be deployed and processed using Security Token Service with Access Manager.

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

Figure 42-4 Identity Propagation Deployment

Description of "Figure 42-4 Identity Propagation Deployment"

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

Figure 42-5 Identity Propagation Processing

Description of "Figure 42-5 Identity Propagation Processing "

42.2.2.1 Process overview: Component interactions for Identity Propagation

In the process of identity propagation, when a user tries to access a protected resource, interactions between the components are established. The components include WebGate, Access Manager, WebLogic Server, Access Manager Identity Asserter on WebLogic Server, Web Service Client, and Security Token Service.

The following steps provide an overview on components interacts for Identity Propagation:

1. User attempts to access a protected resource.

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

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

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

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

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

42.2.3 Request Security Token Attributes and Run Time Processing

You need to configure the Security Token Service to process a request and issue a token for an incoming Request Security Token (RST) with the following attributes:

• RST Attributes for Identity Propagation with the OAM Token

• Process overview: Identity Propagation with the OAM Token

42.2.3.1 RST Attributes for Identity Propagation with the OAM Token

You can apply RST attributes for ID propagation using Security Token Service with Access Manager.

Following are the attributes for ID propagation:

• 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 OnBehalfOf 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://something.example.com/am/2012/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 Security Token Service

42.2.3.2 Process overview: Identity Propagation with the OAM Token

The client prepares and sends the request to the Security Token Service. Before creating a response to the client, the Security Token Service validates the token and creates one if required.

The following steps explain how to apply 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 Security Token Service, to an endpoint protected by a WS-Security User Name Token (UNT) Policy, with that endpoint being mapped to an Security Token Service WSS Validation Template.

3. Security Token Service will process the incoming request

4. Security Token Service 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 Security Token Service Partner store, thus mapping this token to a Requester Partner

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

5. Security Token Service 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. Security Token Service then examines the AppliesTo field:

   • If present, 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 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 Security Token Service will retrieve the Default Relying Party Partner Profile from the Requester Partner Profile.

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

7. Security Token Service then examines the TokenType field:

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

42.2.4 Configuration Requirements: Identity Propagation with the OAM Token

The following topics list the configuration requirements for the identity propagation scenario:

• Configuration Overview: Identity Propagation with the OAM Token

• WebLogic Server Identity Assertion Providers

• Access Manager Identity Asserter Details

• LDAP Authentication Provider Details

• Default Identity Store Configuration

• Token Issuance Policy

• Authentication Policy Response 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 Sent By the Client (Truncated)

42.2.4.1 Configuration Overview: Identity Propagation with the OAM Token

You can configure the Identity Propagation environment using Security Token Service with Access Manager.

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 Security Token Service server with Access Manager 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 Security Token Service

• Security Token Service URL: http://myhost.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 Access Manager 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.

  
  Description of the illustration GUID-7928CE60-5349-401D-970D-A1EF6AA7D8C7-default.gif

The following 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

• Security Token Service Endpoint

• An LDAP server is required for 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.

42.2.4.2 WebLogic Server Identity Assertion Providers

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

$ORACLE_HOME/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 42-6 Required v1.0 WebLogic Server Identity Assertion Providers

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

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

42.2.4.3 Access Manager Identity Asserter Details

You can use the REQUIRED Control flag to set the Identity Asserter.

The IAP-Security Token Service 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 42-7 illustrates the configuration.

Figure 42-7 IAP-Security Token Service Details

Description of "Figure 42-7 IAP-Security Token Service Details"

42.2.4.4 LDAP Authentication Provider Details

You need to create the Authenticator for the LDAP with the OPTIONAL JAAS flag.

This flag points to the Default System Store of Oracle Access Management which provides the Access Manager token.

Figure 42-8 illustrates this process.

Figure 42-8 LDAP Provider: IAP-DSEE

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

42.2.4.5 Default Identity Store Configuration

Figure 42-9 Default Identity Store Defined in Access Manager

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

Figure 42-9 illustrates the Default Identity Store configuration within Oracle Access Management Console.

42.2.4.6 Token Issuance Policy

You need to create the Token Issuance Policy for the resource URL within the IAM Suite Application Domain.

Figure 42-10 shows the Token Issuance Policy page.

Figure 42-10 Token Issuance Policy for Identity Propagation

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

42.2.4.7 Authentication Policy Response for Identity Assertion by Webgate

When an authentication is successful, the WebGate returns an Identity Assertion Token as a policy response.

Identity Assertion is required for ID propagation for any issued token from Access Manager that represents an end user (and possibly its OAM session). The Identity Assertion Token is generated and returned as a policy response (HTTP HEADER named "OAM_IDENTITY_ASSERTION" with a value as a SAML token) after a successful authentication.

The ID Provider (Access Manager) 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.

Security Token Service clients that are Web applications protected by Access Manager requesting tokens to gain proxy access to a Relying Party (ID Propagation use case) are required to pass an OAM Identity Assertion token that represents the end user.

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

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

SeeIntroduction to Policy Responses for SSO.

Confirm that the Identity Assertion box is checked as part of the Authentication Policy Response within the IAM Suite Application Domain. This enables Webgate to perform Identity Assertion for protected resources.

See Adding and Managing Policy Responses for SSO.

As you add each Response, you might be informed that Identity Assertion has not been enabled for this policy. Enable Identity Assertion in order to collect Assertion Attribute type responses (when this policy is executed).

42.2.4.8 Endpoint Configuration

The /wss10 user Endpoint is required.

This is the one that you can use in the Web application to post the RST.

Figure 42-11shows the /wss10user Endpoint. The endpoint is protected by the default WS-Security Validation Template that is used in the Web application to post the RST.

Figure 42-11 /wssuser Endpoint for Identity Assertion

Description of "Figure 42-11 /wssuser Endpoint for Identity Assertion"

42.2.4.9 Issuance Template Configuration

The Issuance Template requires configuration parameters such as Token Type and Signing Key Id for Identity Propagation.

The Issuance Template requires the following configuration for :

• Name: iap-issuance-template

• Description: Custom issuance template

• Token Type: SAML 2.0

• Signing Key Id: osts_signing

• Description: Custom issuance template

42.2.4.10 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

42.2.4.11 Partner Profile: Relying Party

You can create a new Relying Party Profile for Identity Propagation.

To create a new Relying Party Partner Profile:

• Profile ID: iap-relyingparty-profile

• Description: iap-issuance-template

• Default Token Type: SAML 2.0

• Default Template: iap-issuance-template

42.2.4.12 Partner Profile: Requester

You can create new Requester Profile for Identity Propagation.

To create a new Requester Partner Profile:

• Profile ID: iap-requestor-profile

• Description: iap-requestor-profile partner profile

• Default Relying Party Profile: iap-relyingparty-profile

42.2.4.13 Validation Template for WS-TRUST

The Validation Template for WS-TRUST requires configuration parameters such as Token Protocol and Token Type for Identity Propagation.

The required configuration parameters are the following:

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

42.2.5 Testing Your Implementation

You can access the resource to confirm that your implementation is working properly.

Webgate needs to redirect to the OAM Server if there is no existing session for the user. Upon successful authentication, you can view the RST and the RSTR that has been sent by the STS server.

The following topics provide additional information for your test environment:

• Cookies and Headers (Truncated)

• Request Security Token Sent By the Client (Truncated)

• Request Security Token Response sent by the Security Token Service (Truncated)

42.2.5.1 Cookies and Headers (Truncated)

Description of the illustration GUID-380ED969-DA19-4152-8CE0-8CA65213FD0A-default.gif

42.2.5.2 Request Security Token Sent By the Client (Truncated)

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

Description of the illustration GUID-8A95DB32-69F3-4BF0-871D-7C6BA21CEAE0-default.gif

42.2.5.3 Request Security Token Response sent by the Security Token Service (Truncated)

Here is a (truncated) response to the RST sent by the Security Token Service.

Description of the illustration GUID-F5CEBDA7-7DBD-4A69-932C-1636966DD6CA-default.gif