WAS v8.5 > Secure applications > Secure web services > Secure web services > Administer Web Services Security > Administer message-level security for JAX-WS web services > Secure requests to the trust service using system policy sets

Trust service

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 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. 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. 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 using the bootstrap policy 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). 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.

• The trust service component is embedded into and available on each WAS that processes 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). However, the restriction is that security context token, which is needed for WS-SecureConversation, must be provided by the WAS trust service.

• A security policy for each of the WS-Trust operations (issue, cancel, validate, and renew).
• Pre-configured Security Context Token provider which issues tokens for specific URL.
• Specification of a token provider's token-specific parameters (for example, expiration time).
• A security context token for WS-SecureConversation.
• Caching support for the security context token in both cluster and non-cluster environments. WAS issues security context tokens when requested if the request meets the security requirements. However, WS-SecureConversation provided by WAS only processes security context tokens issued by WAS.
• Note that WAS trust service only supports the security context token.
• Trust service supports both the Submission specification (2004/08) and the final specification (2005/08) versions of WS-Addressing.
• 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.

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:

• No negotiation and exchange protocols are supported.
• No other token types are currently supported out of the box; only the security context token is supported.
• No Trust10 specifications from WS-SecurityPolicySet are supported.
• No unsolicited RequestSecurityTokenResponse (RSTR) is supported.
• A Request Security Token (RST) request cannot be issued to an external security token service (STS) to establish a secure conversation; only the embedded trust service is currently supported.
• Policy requests that are contained in the RST are not honored.
• The ability to amend a token (the amend operation) is not supported.
• A dedicated external endpoint for access to the token service is not supported; only the embedded trust service is currently supported.
• The trust services does not support the entropy element containing an EncryptedKey.
• Delegation and forwarding are not supported.
• The OnBehalfOf element is not supported.
• The Key Exchange Token (KET) binding is not supported.

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:

• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue
• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Cancel
• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate
• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew

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

• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT
• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel
• http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew

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.

Note 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

• Security context token
  Web Services Trust (WS-Trust) and Web Services Secure Conversation (WS-SecureConversation) support in the application server provides the ability to issue a security context token (SCT). Requests for a security context token are processed by the security token service.
• System policy sets
  A policy set is a named collection of Quality of Service (QoS) policies. We can use either the dmgr console or wsadmins to manage system policy sets. Policy sets can be created, deleted, copied, imported or exported.
• Web Services Trust standard
  Web Services Trust (WS-Trust) is a proposed Organization for the 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. The trust service, which is provided with WebSphere Application Service, uses the secure messaging mechanisms of WS-Trust to define additional extensions for the issuance, exchange, and validation of security tokens.

Related concepts:

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

+

Search Tips   |   Advanced Search