WS-Trust is an OASIS standard that directs web service clients and providers to interact with the security token service (STS) to issue, renew, and validate security tokens so that a trusted connection can be established. This exchange can happen between various web devices, APIs, or applications via simple object access protocol (SOAP) messages. If the receiving entity successfully validates the security token from the requesting entity, the connection is established. If it’s unsuccessful, the request is denied.
An OASIS Web Standard
“The goal of WS-Trust is to enable applications to construct trusted [SOAP] message exchanges. This trust is represented through the exchange and brokering of security tokens. This specification provides a protocol agnostic way to issue, renew, and validate these security tokens.”1
In a web service that uses WS-Trust, the STS is used by both sides to complete the authentication process.
For example, when a client wants access to the service, it will send a message to the server that contains a token with XML data records that identifies them. Protected with strong cryptography, the token also contains information about its longevity and ownership. When the server gets the message from the client, the server itself does not authenticate the client’s identity against the data in its own database. Instead, it sends the request to the STS to evaluate and validate the request. After all of this communication takes place, the client can then present the token to the server for access.
The concept of universal token translation and an STS originated with web services. Early on, the lack of a standard method for communicating user identities hindered web services applications from gaining widespread business acceptance. Standards such as WS-Security and WS-Trust emerged in the Simple Object Access Protocol (SOAP) world to allow web services to share user identities by incorporating standard security tokens into SOAP messages.
While WS-Trust envisioned token processing as occurring in two phases at the web service client and provider, the underlying STS has no such restriction. As a result, larger organizations with multiple security domains have recognized the value of the STS as a “universal token translator” that can convert any type of security token into any other type of security token–even if there are no web services being used.
The WS-Trust standard specifies that the security token service (STS) can be used by both web service clients and providers to perform operations on standard security tokens. On the web service client side, which can be a web application or rich desktop application, the STS converts whatever security token that is used locally into a standard security assertion markup language (SAML) security token containing the user's identity, which is shared with the web services provider. On the web service provider side, the STS validates incoming security tokens and can generate a new local token for consumption by other applications.
The process begins when the requestor asks the service provider for its security policies and checks them against its own requirements to see if they have the security tokens needed to gain access to the service provider. The service may be attached to an electronic device that communicates with the client via the Internet, or it may be on a computer device that receives requests at a particular port in a network.
If the requestor doesn’t have a viable token on hand, it can request one from the STS. In this way, the STS acts like an identity provider for the requestor because it issues and renews tokens for authentication purposes.
When the provider receives the token from the client, their STS is used to validate or reject the token.
If the token is accepted by the provider, then a connection is established. If it’s not accepted, messaging doesn’t take place.
Related Resources
Start Today
Contact Sales
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo