42.3 Scenario: Web Service Security On Behalf Of Username Token

The following topics provide information about web service security on behalf of username Token:

42.3.1 Component interactions for Identity Propagation with Username Token

Here is the process overview of how the components are interacting when the user’s identity is propagated with the Username token.

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

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

  6. 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. Security Token Service then generates Request Security Token Response.

  8. 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.3.2 RST Attributes and Processing for Identity Propagation with a Username Token

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

The following topics provide information about RST attributes and processing for Identity propagation with a username token:

42.3.2.1 RST Attributes for Identity Propagation with a Username Token

You can apply RST attributes for ID propagation using 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 Security Token Service.

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

  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 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:

    • Validates the format of the Username token.

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

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

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

    • Creates the WS-Trust RSTRC

    • Includes the returned token

    • Includes proof key if necessary

42.3.3 Configuration Requirements: Identity Propagation with the Username Token

42.3.3.1 Configuration overview: Identity Propagation with the Username Token

You can configure the Identity Propagation environment using 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 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.

  • Security Token Service URL: http://myhost.domain.com:14100/sts/<endpoint>

    Note:

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

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 for Access Manager.

42.3.3.2 Default Identity Store Configuration

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

Figure 42-12 Default Identity Store Defined for Access Manager

Description of Figure 42-12 follows
Description of "Figure 42-12 Default Identity Store Defined for Access Manager"

42.3.3.3 Token Issuance Policy

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

Figure 42-13 Token Issuance Policy for Identity Propagation

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

Create the Token Issuance Policy for the resource URL within the IAMSuite Application Domain.

Figure 42-13 is a screen shot of the Token Issuance Policy page.

42.3.3.4 Endpoint Configuration

The /wss11 user Endpoint is required.

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

Figure 42-14 shows the 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-14 /wss11user Endpoint for Identity Assertion

Description of Figure 42-14 follows
Description of "Figure 42-14 /wss11user Endpoint for Identity Assertion"

42.3.3.5 Issuance Template Configuration

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

Following is the required configuration:

  • Name: saml-issuance-template

  • Description: SAML issuance template

  • Token Type: SAML 2.0

  • Signing Key Id: osts_signing

42.3.3.6 Partner Configuration: Requester

You can create a new Requester Partner configuration for Identity Propagation with the OAM token.

To create:

  • 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

42.3.3.7 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: relying-party-profile

  • Description: Relying Party Profile

  • Default Token Type: SAML 2.0

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

42.3.3.8 Partner Profile: Requester

You can create a new Requester Profile for Identity Propagation.

Create a new Requester Partner Profile:

  • Profile ID: requester-profile

  • Description: Requester Partner Profile

  • Default Relying Party Profile: relying-party-profile

42.3.3.9 Validation Template for WS-TRUST

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

The configuration parameters required are the following:

  • Validation Template Name: username_wstrust_validation_template

  • Description: Username WS-Trust Template

  • Token Protocol: WS-Trust

  • 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

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>

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

Request Security Token Response sent by the Security Token Service

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

<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="myhost.uk.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">user-alice@example.com</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>