+

Search Tips   |   Advanced Search

Trust service


The security token service that is provided by WAS is called the trust service. The WAS trust service uses the secure messaging mechanisms of Web Services Trust (WS-Trust) to define additional extensions for the issuance, exchange, and validation of security tokens.

Web Services Trust (WS-Trust) is an OASIS standard that enables security token interoperability by defining a request/response protocol. This protocol allows SOAP actors, such as a Web services client, to request of some trusted authority that a particular security token be exchanged for another.

WAS is not providing a full security token service that implements all the contents of the WS-Trust draft specification. The WAS support of WS-Trust focuses on establishing a security context token for secure conversation. Version 7.0 of WAS supports many of the security features described in version 1.3 of the WS-Trust OASIS standard, dated March 19, 2007.

 

Third party WS-Trust client

WAS does not provide a WS-Trust client implementation. We can choose to use a third-party WS-Trust-enabled client but, if we do, WAS does not support a third-party trust-enabled client. A trust client can facilitate the generation of these soap messages and the processing of the response, but the client is not required.

WAS focuses on the issuing, renewing, and canceling of the security context token for Web Services Secure Conversation (WS-SecureConversation).

The WS-Trust specification must be followed to make requests of the trust service. This specification includes the use of Web Services Addressing (WS-Addressing) headers. The WS-Addressing headers are specified in both the August 2004 or the August 2005 specifications. Per the specification, the SOAP body must consist of a single RequestSecurityToken (RST) element. This element can contain sub-elements as defined in the WS-Trust and WS-SecureConversation specifications.

We can secure the WS-Trust SOAP messages by using the bootstrap policy that is defined in the policy set. The bootstrap security policy is invoked in the process of an initiator establishing communication with an application service. Initial requests to services other than the application service are secured by using the bootstrap policy. These initial requests typically involve one or more requests to a security token service (STS), such as the WAS trust service. An example of a request might be acquiring the security context token necessary for WS-SecureConversation. An initiator is the role that initiates the original request and, in most cases, it is the client. The client bootstrap policy set must correspond to the trust service issue and renew attached policy sets for the endpoint. The trust service cancel and validate attached policy sets for the endpoint must correspond to the client's application policy set.

Websphere Application Server provides two ways to secure SOAP messages that are destined for the trust service. One way is to use the bootstrap policy that is defined in the policy set. A second way is to use the WS-Security API (WSS API). Your application might use the WSS API to acquire the security context token for the programmatic, API-based WS-SecureConversation.

For Secure Conversation, a request from the client to an endpoint service is suspended while a new (second) request is generated and processed by the trust service. The security context token returned with the second request is used to derive keys that secure communications with the service.

 

High-level trust service functions

The following list includes WS-Trust-related functions that are currently supported in WAS. The list is not exhaustive and it focuses only on the high-level functions.

 

Trust service functions that are not supported

The following high-level WS-Trust functions that are not supported in WAS. The list is not exhaustive, and the list focuses only on key functions:

 

Trust service operations

WAS specifically supports the ability of the trust service, on behalf of the endpoint, to issue a security context token for WS-SecureConversation. The token-issuing support is currently limited only to the security context token. There is also trust policy management for defining a policy for the trust service to issue, cancel, validate, or renew tokens. The token service supports the WS-Trust schema namespace. Within this namespace the following actions are supported:

The token service also supports the WS-SecureConversation schema namespace. Within this namespace the following actions are supported:

An inbound RST for the security context token issue operation must contain an Entropy element. The Entropy element must contain a BinarySecret. The trust services does not support the Entropy element that contains an EncryptedKey.

Note that the trust service does not support unsolicited RSTR actions. In addition, the ability to amend a token is not supported by WAS. Also, see the section titled Trust service functions that are not supported.

 

Trust policy set-related files

The default trust service policy set for issue and renew is TrustServiceSecurityDefault. You can set up the corresponding policy set and binding for each service endpoint URL.


Subtopics


Security context token
System policy sets
Web Services Trust standard

 

Related concepts


Secure conversation client cache and trust service configuration
Web Services Secure Conversation
Web Services Addressing support

 

Related tasks


Secure requests to the trust service using system policy sets