WS-Trust: How it Works

WS-Trust Background

The concept of universal token translation and a Security Token Service (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 SOAP world to allow web services to share user identities by incorporating standard security tokens into SOAP message headers.

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. For example, an STS can be used to convert a CA SiteMinder cookie into an IBM LTPA token.

How the WS-Trust standard works

The WS-Trust standard specifies that 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 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.