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 client and provider bindings for the SAML sender-vouches token
Configure the client and provider policy set attachments and bindings for the SAML sender-vouches token, which includes the sender-vouches confirmation method. The sender-vouches confirmation method is used when a server needs to propagate the client identity or behavior of the client. This function is enabled in WAS v7.0.0.9 and later releases.
To use the function, first install WAS v7.0.0.9, which includes SAML sender-vouches support. After installing Version 7.0.0.9, create one or more new server profiles, or add SAML configuration settings to an existing profile. For example, in a WAS ND environment, there are multiple profiles. Read about setting up the SAML configuration for more information. The sender-vouches token must be protected using either message-level security or HTTPS transport. Therefore, determine which type of security to use.
A SAML sender-vouches token is a SAML token that uses the sender-vouches subject confirmation method. A SOAP message sender is required to protect the integrity of SOAP messages and SAML tokens so that a receiver can verify that the message contents and SAML tokens were not modified by unauthorized parties. WAS with SAML provides numerous default SAML token application policy sets and several general client and provider binding samples. The policy set for the SAML sender-vouches token is similar to the SAML bearer token policy set. The procedure shows how to create a sender-vouches policy set based on the attached SAML bearer token policy set. Before you can configure the client and provider bindings for the SAML sender-vouches token, attach SAML bearer token client and provider bindings to the JAX-WS application. For more information about the bearer policy sets, read about configuring client and provider bindings for the SAML bearer token.
We must use application-specific custom bindings instead of general bindings for sender-vouches. Therefore, if you configure sender-vouches policy sets and bindings from attached bearer token policy sets and bindings, ensure that the assigned bindings are application-specific bindings.
The procedure for creating the sender-vouches policy set begins with attaching the Web services bearer token policy sets.
Procedure
Complete the associated steps to configure the selected protection method. Follow the first set of steps to protect messages using message-level security, or follow the second set of steps to protect messages using HTTPS transport.
- To protect messages using message-level security, attach the SAML20 Bearer WSSecurity default policy set and configure the associated application-specific bindings.
- Attach the SAML20 Bearer WSSecurity default policy set. Refer to steps 1 and 2 in the topic, Configuring client and provider bindings for the SAML bearer token.
- Create and configure application-specific bindings for the client and the service provider. Refer to steps 3 to 9 in the topic Configuring client and provider bindings for the SAML bearer token. For the binding names, enter names that include sender-vouches, such as SAML20SenderVouches_Client and SAML20SenderVouches_Service.
- The sender of SOAP messages (attesting entity) satisfies the sender-vouches subject confirmation requirement by including a <ds:Signature> element in the corresponding <wsse:Security> header. The initiator key is used to sign the relevant message content and assertions. Modify the sender-vouches bindings to satisfy the vouching requirement.
- Refer to the topic, Signing SAML tokens at the message level for information about modifying the sender-vouches bindings.
- Edit both the Client policy set and bindings and the Service provider policy sets and bindings. Click WS-Security > Authentication and protection.
- Click the name of the authentication token that is configured in the attached SAML bearer policy set; for example, request:SAMLToken20Bearer.
- Click Callback handler.
- Under Custom Properties, select confirmationMethod.
- Click Edit.
- Change the value of the confirmationMethod property to sender-vouches.
- Verify that the value of the keyType property value is http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer or the bearer alias. The wstrustClientWSTNamespace property determines how the bearer alias is interpreted. In this case it is assumed that it is set to the WS-Trust 1.3 namespace. If it had a value of WS-Trust 1.2, the bearer alias carries no meaning, as it is not defined for WS-Trust 1.2.
- To protect messages using HTTPS transport, attach the SAML20 Bearer WSHHTPS default policy set and configure the associated application-specific bindings.
- Attach the SAML20 Bearer WSHHTPS default policy set. Refer to steps 1 and 2 in the topic, Configuring policy sets and bindings to communicate with the Security Token Service (STS).
- Create and configure application-specific bindings for the client and the service provider. Refer to steps 3 to 5 in the topic, Configuring policy sets and bindings to communicate with STS. For the binding names, enter names that include sender-vouches, such as sslSamlSenderVouches_Client and sslSamlSenderVouches_Service.
- Set the required SAML SubjectConfirmation method to the sender-vouches method.
- Edit both the Client policy set and bindings and the Service provider policy sets and bindings. Click WS-Security > Authentication and protection .
- Click the name of the authentication token configured in the attached SAML bearer policy set. For example, request:SAMLToken20Bearer.
- Click Callback handler.
- Under Custom Properties, select confirmationMethod.
- Click Edit.
- Change the value of the confirmationMethod property to sender-vouches.
- Verify that the value of the keyType property value is http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer or the bearer alias. The wstrustClientWSTNamespace property determines how the bearer alias is interpreted. In this case it is assumed that it is set to the WS-Trust 1.3 namespace. If it had a value of WS-Trust 1.2, the bearer alias carries no meaning, as it is not defined for WS-Trust 1.2.
- Use X.509 client certificate authentication over SSL to satisfy the sender-vouches subject confirmation requirement. The configuration steps vary on the SOAP message receiver side depending on whether SSL connections end at the internal HTTP server or at an external HTTP server. An external HTTP server might be a web server, a reverse proxy security server, a proxy server, and so on.
When client certificate authentication is required, the internal HTTP server accepts a client SSL connection request under one of the following conditions:
- The X.509 certificate for the client exists in the trust store.
- The X.509 certificate is issued by a trusted entity or party, which means that the X.509 certificate for the issuer exists in the trust store.
- If a web services SSL connection ends at an internal HTTP server...
- Click Security > SSL certificate and key management > Manage endpoint security configurations > node_name > SSL configurations.
- Select the resources used in the SSL transport bindings and in the secure transport chain.
- Under Additional Properties, click Quality of protection (QoP) settings.
- Under General Properties, select Required from the Client Authentication menu list.
- Click Apply.
- If a web services client SSL connection ends at an external HTTP server...
- Regenerate the plug-in. Click Servers > Web Servers.
- Select the web server, then click Generate Plug-in.
- Update the HTTP server with the generated plug-in.
- Restart the HTTP server.
- Enable client certificate authentication from the HTTPS client to your web server. See the documentation about SSL client certificate authentication.
The external web server is configured to propagate web services client SSL context data to the application server. Protect the connection between the external web server and the application server to prevent man-in-the-middle attacks.
General sample bindings for JAX-WS applications
SSL client certificate authentication
Signing SAML tokens at the message level
Configure client and provider bindings for the SAML bearer token
Configure policy sets and bindings to communicate with STS
Encode passwords in files
IBM WAS V6.1 Security Handbook