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 requests to the trust service using system policy sets
The security token service provided by WAS is called the trust service. The WAS trust service uses the secure messaging mechanisms of WS-Trust to define additional extensions for the issuance, exchange, and validation of security tokens.
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. We can choose to use a third-party WS-Trust-enabled client but, if you 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 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 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.
- Cache 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 that are 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 that contains 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:
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. We can set up the corresponding policy set and binding for each service endpoint URL.
Security context token
System policy sets
Web Services Trust standard
Secure conversation client cache and trust service configuration
Web Services Secure Conversation
Web Services Addressing support
Secure requests to the trust service using system policy sets