WS-Trust and Security Token Service (STS)
WS-Trust and STS (Security Token Service) are two of the many terms I often came across when I started learning Identity and Access Management concepts. What is WS-Trust?… and what is STS? Do they mean the same thing?… if not, how do they relate to each other? These are the questions I had in mind when I started to find more about these concepts. So, I decided to write down what I found in this brief article to help anyone who is having the same questions that I had.
First, let’s see what is WS-Trust by definition.
WS-Trust is a specification and OASIS standard that uses secure messaging mechanisms of WS-Security to deal with issuing, validating, and renewing security tokens.
Now, most of you may have the question — what is WS-Security? Well, “WS-” prefix is used to indicate specifications associated with web services. WS-Security (Web Service Security) is one such specification which focuses on end-to-end security in web services.
The Security Token Service, STS, is a service that acts as a broker to establish trust relationships between a service provider and a service requestor. The STS issues signed security tokens which are used by service requestors (clients) to authenticate themselves at the service providers.
STS is a service model defined by WS-Trust specification. The issuance, validation, renewal, and exchange of security tokens in STS are based on WS-Trust protocol.
So, now you know the terms by definition, and how they relate to one another. Now let’s get a little deeper to these concepts.
Security Token Service
The Security Token Service enables operations such as authentication, authorization, identity validation, identity mapping, and security token exchange.
The STS model involves three main parties.
- Service/Resource Provider
- Service Requestor (Client)
- Security Token Service (STS)
A service requestor (client) needs to access a service/resource provided by a service provider. To access the service/resource, a security token issued by a specific token provider (STS) is required. A security token is a collection of claims (statements made about a client such as name, role, authorization code, privilege etc.). So, a service requestor retrieves a security token from the specified Security Token Service (STS), and present the token to the service provider. The service provider trusts the token issued by the STS. Here, the service provider is called the relying party as it relies upon tokens issued by the STS to grant or deny access to the services it provides. If the retrieved token is valid, the requestor is allowed to access the service/resource.
A high-level illustration of the STS model is shown in the following figure.
WS-Trust
WS-Trust specifies protocol mechanisms for requesting, issuing, renewing, validating, canceling security tokens independent from the application type. It also defines formats for messages used to request tokens, and responses to those messages. The request message is called Request Security Token (RST), and the response message is called Request Security Token Response (RSTR).
The requestor/client prepares the RTS and sends it to the STS as a web service request. The RST includes the type of the token required (SAML 1.1/SAML 2.0), request type for the token, what claims should be included in the token, endpoint reference of the service etc. Upon a successful validation, the RSTR can include the requested claims. There are other RSTRs possible including challenges that must be met before the requested token is issued.
In this article, I tried to explain what is WS-Trust, and what is STS in high-level. I hope now you know the answers to the questions I stated in the beginning of the article. If you are interested in learning more about these concepts, following links in the references are ideal to start with. Hope you enjoyed reading :)
References
https://www.ibm.com/developerworks/websphere/library/techarticles/1003_chades/1003_chades.html
