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.
Before you begin
This function is enabled in WebSphere® Application Server Version 7.0.0.9
and later releases. To use the function, you must first install WebSphere Application Server Version 7.0.0.9,
which includes SAML sender-vouches support. After installing Version
7.0.0.9, you must create one or more new server profiles, or add SAML
configuration settings to an existing profile. For example, in a WebSphere Application Server, Network Deployment 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, you must
determine which type of security you want to use.
About this task
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.
WebSphere Application Server 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, you must
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.
You 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, you must 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 .
- 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 .
- 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,
complete the following steps:
- Click .
- 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, complete the following steps:
- Regenerate the plug-in.
Click .
- 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. For more information, see the documentation about
Secure Sockets Layer (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.