+

Search Tips   |   Advanced Search

Trust service (WS-Trust)

The security token service provided by WebSphere Application Server 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 support of the WS-Trust draft specification focuses on establishing a security context token for secure conversation.


Third party WS-Trust client

WAS does not provide a WS-Trust client implementation and WAS does not support third-party trust-enabled clients. 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 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 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 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 defined in the policy set. A second way is to use the Web Services Security API (WSS API). The 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

WS-Trust-related functions supported in WAS:

The trust service component is embedded into and available on each application server processiing the WS-Trust protocol messages. Communication is accomplished through the RequestSecurityToken (RST), RequestSecurityTokenCollection (RSTC), RequestSecurityTokenResponse (RSTR), and RequestSecurityTokenResponseCollection (RSTRC).

An RST request can be made to an external security token service (trust service). The security context token is provided by the WAS trust service. WAS provides a pre-configured security context token provider which issues tokens for specific URLs. We can specify s token-specific parameters (for example, expiration time). WAS issues security context tokens when requested if the request meets the security requirements. WAS provides a security context token for WS-SecureConversation, however WAS only processes WS-SecureConversation tokens issued by WAS.

There is a security policy for each of the WS-Trust operations: issue, cancel, validate, and renew. The trust service uses a default policy set called TrustServiceSecurityDefault, which includes WS-Security and WS-Addressing and provides default security for the issue and renew operations. Trust service uses a second default policy set called TrustServiceSymmetricDefault, which includes WS-Security and WS-Addressing and provides default security for the cancel and validate operations.

WAS supports token caching support in both cluster and non-cluster environments.


Trust service functions that are not supported

The following WS-Trust functions are NOT supported in WAS.


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 containing an EncryptedKey. 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. We can set up the corresponding policy set and binding for each service endpoint URL.


Subtopics


Related: