Security Token Service and Universal Token Translation

The concept of Universal Token Translation and Security Token Services (STSs) 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.

Security Token Services were originally created to identity-enable Web Services

As part of this effort, the WS-Trust standard specified a Security Token Service (STS) that could 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 that 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.

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