Web services are software applications that interact over network by using the Hyper Text Transfer Protocol (HTTP). World Wide Web Consortium (W3C) describes web services as a standard means of interoperating between software applications running on a variety of platforms and frameworks. A web service provides a fine-grained service to its client.
Web services use network for communication and data exchange spanning from protected network (intranet) to unprotected network (internet). This demands for security requirements such as client authentication, access control, data integrity, and confidentiality.
You can secure web services and protect your information against authentication attacks and unauthorized access by using security tokens. A security token contains a set of claims made by a client that includes details such as a user name, password, identity, key, and certificate.
Access Manager addresses the need for a secure token mechanism through WS-Trust STS that is based on the WS-Trust protocol. WS-Trust is built on top of the WS-Security specification. It enables web applications to construct trusted SOAP message exchanges.
WS-Trust STS provides secure communication and integration between services. It issues and validates security tokens to establish trust relationships between a web service client and a web service provider. If the requestor (web service client) does not have the necessary token to provide required claims to a service, it contacts WS-Trust STS and requests the needed tokens with proper claims. WS-Trust STS may in turn require its own set of claims for authenticating and authorizing the request for security tokens.
WS-Trust STS allows secure identity propagation and token exchange between web services. It provides a standard framework for requesting and returning security tokens by using Request Security Token (RST) and Request Security Token Response (RSTR) messages. RST provides the means for requesting a security token from WS-Trust STS. RSTR contains the requested token, claims, and other related information.
The web service client provides its credentials to WS-Trust STS and gets a SAML token from WS-Trust STS. A trust is established between the web service provider and WS-Trust STS. The web service client presents the token from WS-Trust STS to the web service provider. The web service provider validates if the token has been issued from WS-Trust STS and grants access to the required service.
The following is an example of how WS-Trust STS facilitates a secure communication between a web service client and a web service provider through security tokens:
WS-Trust STS can interoperate with different web service environments and supports SOAP and WS-Trust specifications. Web services must implement the protocol defined in the WS-Trust 1.3 or 1.4 specification by making assertions based on the evidence that it trusts, to whoever trusts it, or to specific recipients. See WS-Trust 1.3 Specification and WS-Trust 1.4 Specification.
The following table lists supported SOAP and WS-Trust versions and corresponding namespaces:
Specification |
Version |
Namespace |
---|---|---|
Soap |
1.1 |
http://schemas.xmlsoap.org/soap/envelope/ |
1.2 |
http://www.w3.org/2003/05/soap-envelope |
|
WS-Trust |
1.3 |
http://docs.oasis-open.org/ws-sx/ws-trust/200512 |
1.4 |
http://docs.oasis-open.org/ws-sx/ws-trust/200802 |
NOTE:
WS-Trust STS supports SAML tokens in addition to usernametokens.
WS-Trust STS can issue both SAML 1.1 and SAML 2.0 based tokens.
WS-Trust STS supports issuing, validating and renewing tokens.
Web service clients and web service providers must be in the same domain.
Enables the secure exchange of SOAP messages among web services.
Facilitates identity delegation (through ActAs) and impersonation (through OnBehalfOf) where an authenticated user is granted access to downstream web services.
Reduces complexity for the web service consumer as the web service consumer does not need token specific knowledge.