The Web Services Trust Model (WS-Trust)
The relationship with [WS-Security]
[WS-Security] defines the basic mechanisms for providing the message level security. This specification uses the base mechanisms and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains.
In order to secure a communication between two parties, the two parties must exchange security credentials. However, each party needs to determine if they can “trust” the asserted credentials of the other party. [WS-Trust] is there to fulfill that process.
The Goal of [WS-Trust]
The main 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. In order to facilitate this process, [WS-Trust] introduces a standard run-time component called Security Token Service (STS).
STS (Security Token Service)
In a typical [WS-Security] scenario, the client and the server can exchange keys between them in order to complete a secure communication. However, in a much larger enterprise level application, If we are going to take that approach, the relevant service needs to remember all the client locations and needs to update one by one when there is a key change happens at the service level.
In this kind of a scenario a STS can be quite a help, With STS around, the web service consumer doesn’t need to know the art of creating security tokens. Instead, it sends a request to the STS containing the requirements of the service consumer and the service provider and later attaches the returned security token to the outgoing SOAP message to the service provider. All the service consumer needs to do is to grab the returned token from the STS and attach it to the SOAP message. This basically eases the burden from the service consumer and they can concentrate on the business logic rather than the security aspects revolve around them.
SAML (Security Assertion Markup Language)
Although WS-Trust specification is having a protocol agnostic security token feature, SAML has been the preferred option mainly because of it is inter-operable capability over other protocols. SAML token assertions can provide three kinds of information related to service consumers.
1. Authentication Assertion – limit the service access for some authentication credentials (Name, Id, etc) of the service consumer.
2. Authorization Assertion – limit the service access for some authorization capabilities of the service consumer.
3. Attribute Assertion – limit the service access for certain attributes of the service consumer.
How it works
Now we are in a position to explain the basic flow of the “Web Service Trust Model”. Lets assume that both STS and service consumers are in an agreement to “trust” each other. Therefore, the given STS provider is able to issue security tokens (SAML) to service consumers to access their services. Basically this trust process can be explained in three steps as follows.
1. RST (Request Security Token) – Service Consumer request a security token from STS.
2. RSTR – (RequestSecurityTokenResponse) – STS will send the response as a SAML token with relevant security assertions
3. Now the service consumer is in a position to access the service provider with the SAML token, which was provided by STS.
All these SAML assertions are governed by policies defined (with the help of WS-SecurityPolicy) at service consumer, STS and service provider levels.
The above process is explained in the following diagram as well.
The above pattern creates an indirect trust relationship between the service provider and the STS instead of between the service provider and service consumer. As long as the service consumer is in the possession of a security token issued by a trusted STS, the service consumer is able to access the services provider.
So, this web service trust model is the base for the most of the Single Sign On and other Federated Identity Management systems in the SOA world. My next articles will discuss more into each of the technologies in a very detailed manner. Until then Happy SOA!
1. WS-Trust Specification – http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf
2. WS-Trust with Fresh Banana Service – http://blog.facilelogin.com/2010/05/ws-trust-with-fresh-banana-service.html
3. Advanced SOA Security – SAML and WS-Trust – http://www.youtube.com/watch?v=YZNVyUc-3fQ
Comments are closed.