Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services > Secure messages using SAML
Configure policy sets and bindings to communicate with STS
Configure policy sets and binding documents to enable a web services client to request SAML assertions from an external Security Token Service (STS). This function is enabled in WAS Version 7.0.0.7 and later releases. After installing, create a new server profile, or add SAML configuration settings to an existing profile. Read about setting up the SAML configuration for more information. WAS with SAML supports web services clients using the Web Services Security policy set and bindings when communicating with an external security token service (STS). In WAS Version 6.1 and later, web services clients use policy set and bindings to communicate with the target web services provider. A web services client uses two sets of policy set attachments: one set of policy set attachments for communicating to the target web services provider; and the other set of policy set attachments for communicating to the STS. Policy sets and bindings that are used when communicating with the target web services provider are attached to the web services client. In contrast, policy sets and bindings that enable STS communication are not directly attached to the web services clients. Instead, policy sets and bindings that enable STS communication are specified as custom properties in the web services client binding document. We can use general bindings or application-specific bindings to communicate with an STS. Using a general binding to access an STS is straightforward; simply specify the general binding name in the custom properties.
The procedure to configure application-specific bindings to access an STS is more involved. The admin console is designed to manage policy set attachments to communicate with a web service provider. The console is not designed to manage a second set of policy set attachments to communicate to an STS. However, you can use the administrative console to manage a policy set attachment to access an STS, as described in the procedure.
Use the admin console to attach the policy set used to access an STS to a web services client, and then create and modify an application-specific binding. Once the binding configuration is complete, detach the policy set and binding from the web services client. This procedure is necessary because the next step is to attach the policy set and bindings to communicate to the target web services provider. Detached application-specific bindings are not deleted from the file system, so the web services client bindings custom properties can successfully refer to the detached application-specific bindings.
The procedure uses a default application policy set, Username WSHTTPS default, as an example to describe the configuration steps to access the STS. The steps can also be applied to other policy sets. The web services application, JaxWSServicesSamples, is used in the example. JaxWSServicesSamples is not installed by default.
Procedure
- Import the Username WSHTTPS default policy set. In this example, the Username WSHTTPS default policy is used to demonstrate the procedure, but you can use a different policy set to configure the bindings, if the policy set meets the policy requirements of the external STS.
- Click Services > Policy sets > Application policy sets.
- Click Import.
- Select From Default Repository.
- Select the WSHTTPS default policy set.
- Click OK to import the policy set.
- Attach a policy set for the trust client. Click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service client policy sets and bindings. The steps which pertain to attaching and detaching the policy set, and configuring the trust client binding, are required only if an application-specific binding is used to access the external STS. We can skip these steps, and go to the step that discusses configuring communication with the STS, if you use a general binding to access the external STS.
- Select the check box for the web services client resource.
- Click Attach Client Policy Set.
- Select the policy set, Username WSHTTPS default.
This step attaches the policy set to the web services trust client, as you would do to use this policy set for the application client to access the target web services. However, since you plan to use the Username WSHTTPS default policy set to access an external STS instead, the policy set is only temporarily attached to the Web services client. The purpose of this step is to allow you to use the admin console to create or to modify the client binding document.
- Configure the trust client binding.
Optional. We can create an HTTP transport binding using the previous steps to configure a user name and password to add to the HTTP header, or to configure a proxy. If you elect not to create an HTTP transport binding, the web services runtime environment uses the default HTTP transport settings.
- Select the web services client resource again.
- In the Service client policy sets and bindings panel, click Assign Binding.
- Click New Application Specific Binding to create an application-specific binding.
- Specify a binding configuration name for the new application-specific binding. In this example, the binding name is SamlTCSample.
- Add the SSL transport policy type to the binding. Optionally, you can modify the NodeDefaultSSLSettings settings. Click Security > SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings.
- Add the WS-Security policy type to the binding, then modify the authentication settings.
- Click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service client policy sets and bindings > SamlTCSample > Add > WS-Security > Authentication and protection > request:uname_token.
- Click Apply.
- Select Callback handler.
- Specify a user name and password (and confirm the password) to authenticate the web services client to the external STS.
- Click OK and Save.
- After the binding settings are saved, return to the Service client policy sets and bindings panel to detach the policy set and bindings.
- Click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service client policy sets and bindings.
- Click the check box for the web services client resource.
- Click Detach client.policy set.
The application-specific binding configuration you created in the previous steps is not deleted from the file system when the policy set is detached. This means that you can still use the application-specific binding you created to access the STS.
- Import the SSL certificate from the external STS.
Optional. If further modifications to the wstrustClientBinding configuration are needed, and the wstrustClientBinding property is pointing to an application-specific binding, attach the application-specific binding to the web services client before you can complete the modifications. The attachment is temporary. As detailed in the previous steps, you can detach the modified application-specific binding from the web service client after the modification is completed.
- Click Security > SSL certificate and key management > Manage endpoint security configurations > server_or_node_endpoint > Keystores and certificates > NodeDefaultTrustStore > Signer certificates.
- Click Retrieve from port.
- Specify the host name and port number of the external STS server, and assign an alias to the certificate. Use the SSL STS port.
- Click Retrieve signer information.
- Click Apply and Save to copy the retrieved certificate to the NodeDefaultTrustStore object.
Results
After successfully completing the steps, the web services client is ready to send requests to the external STS.To enable this function, the following conditions and settings were activated when you completed the procedure:
- Attach a policy set and bindings that propagate SAML tokens. For example, attach the SAML11 Bearer WSHTTPS default policy set and the Saml Bearer Client sample general binding to the web service client.
- The Username WSHTTPS default policy set and an application-specific binding, SamlTCSample, are referenced in the Saml Bearer Client sample binding, and are set up to access the external STS.
- The external STS SSL certificate has been retrieved and added to the NodeDefaultTrustStore truststore.
- To confirm that you successfully enabled the function, you can configure the trace setting, com.ibm.ws.wssecurity.*=all=enabled. The trace shows that SAML assertions are issued by the external STS, for example:
[8/23/09 18:26:59:252 CDT] 0000001f TrustSecurity 3 Security Token Service reponse: [8/23/09 18:26:59:392 CDT] 0000001f TrustSecurity 3 <?xml version="1.0" encoding="UTF-8"?> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <s:Header> <a:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal </a:Action> <a:RelatesTo>urn:uuid:663A7B27BA8EB2CF9D1251070029934 </a:RelatesTo> <o:Security xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" s:mustUnderstand="1"> <u:Timestamp u:Id="_0"> <u:Created>2009-08-23T23:26:57.664Z </u:Created> <u:Expires>2009-08-23T23:31:57.664Z </u:Expires> </u:Timestamp> </o:Security> </s:Header> <s:Body> <trust:RequestSecurityTokenResponseCollection xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <trust:RequestSecurityTokenResponse> <trust:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2009-08-23T23:26:57.648Z </wsu:Created> <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2009-08-24T09:26:57.648Z </wsu:Expires> </trust:Lifetime> <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <a:EndpointReference> <a:Address>https://taishan.austin.ibm.com:9443/WSSampleSei/EchoService12 </a:Address> </a:EndpointReference> </wsp:AppliesTo> <trust:RequestedSecurityToken> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="_3c656382-9916-4e5f-9a16-fe0287dfc409" Issuer="http://svt193.svt193domain.com/Trust" IssueInstant="2009-08-23T23:26:57.663Z"> <saml:Conditions NotBefore="2009-08-23T23:26:57.648Z" NotOnOrAfter="2009-08-24T09:26:57.648Z"> <saml:AudienceRestrictionCondition> <saml:Audience>https://taishan.austin.ibm.com:9443/WSSampleSei/EchoService12 </saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2009-08-23T23:26:57.640Z"> <saml:Subject> <saml:SubjectConfirmation> <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_3c656382-9916-4e5f-9a16-fe0287dfc409"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>YGySZX4VPv25R+oyzFpE0/T/tjs= </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>eP68...Vr08= </ds:SignatureValue> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MII...ymqg3 </X509Certificate> </X509Data> </KeyInfo> </ds:Signature> </saml:Assertion> </trust:RequestedSecurityToken> <trust:RequestedAttachedReference> <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">_3c656382-9916-4e5f-9a16-fe0287dfc409 </o:KeyIdentifier> </o:SecurityTokenReference> </trust:RequestedAttachedReference> <trust:RequestedUnattachedReference> <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">_3c656382-9916-4e5f-9a16-fe0287dfc409 </o:KeyIdentifier> </o:SecurityTokenReference> </trust:RequestedUnattachedReference> <trust:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 </trust:TokenType> <trust:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </trust:RequestType> <trust:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer </trust:KeyType> </trust:RequestSecurityTokenResponse> </trust:RequestSecurityTokenResponseCollection> </s:Body> </s:Envelope>
What to do next
Complete the web service client and web service provider configuration. Read about configuring client and provider bindings for the SAML bearer token for more information.
Configure client and provider bindings for the SAML bearer token
Configure client and provider bindings for the SAML holder-of-key symmetric key token