Brokered Authentication Pattern

Today I am going to talk about  brokered authentication.  Before going to topic, I guess you are familiar with the direct authentication that there is an direct relationship between the two parties, those are client and server.  But in brokered authentication, there is an authentication broker that both parties trust independently. And authentication broker issues security token to the client, where client can present them to the servers for accessing resources.

Let go in to more details on brokered authentication pattern with some sample. That would help you to understand more clearly

Sample user case

Say; there are two organizations. One is FOO.com and other is BAR.com.  FOO.com  has  developed several applications to use for their employees. Employees can access these applications by authenticating with the user store of  FOO.com domain.   BAR.com has several  SOAP services and REST services that have been exposed from their legacy systems.

As time goes,  FOO.com establishes a partnership with BAR.com.  FOO.com applications wish to access the services that are in the BAR.com.  Therefore BAR.com must expose their services to FOO.com domain.  Then FOO.com users must be authenticated to access these APIs, because the services can be secured with authentication and authorization.

How to achieve this?  It can be done by  sharing the FOO.com user store with BAR.com and then BAR.com services can use the user store to verify the users.???  NO…!!! it is not possible, user store is a highly secured, It can NOT be exposed outside the FOO.com domain. So, what would be the solution?
If there is some way, If we can propagate the FOO.com user’s identity data in to BAR.com, that would be great…!!!

So, Users in the FOO.com could be authenticated with its own user store. And the user identity data could be propagated to in to BAR.com. Security tokens such as SAML can be used to propagate the user identity information across two domains. Also there must be way to validate these security tokens at the BAR.com domain and extract user information for authentication and authorizations.

Issuing security tokens

Security Token Service (STS) is the standard entity that security tokens are issued. WS-Trust specification defines the way to communicate with the STS. Therefore, Applications in FOO.com would need to call to STS using WS-Trust standard. Once application sends the user credentials to STS, STS validates the credentials with user store and response back with the security token that contains the user information (attributes , entitlements of users). One important behavior of STS is that, there could be several ways that user can be authenticated to STS. It can be username/password, certificates, tokens or any proof of the user’s identity. STS must be capable of handing different types of authentication mechanism. This would lead to implement security token exchange patterns with STS. As an example, Application can provides the user’s X.509 certificate and exchange it for a standard SAML token using the STS. Apart from issuing the tokens, STS exposes the methods to renew, validate and cancel the tokens. Finally; in FOO.com domain STS must be deployed.

Securing SOAP & REST API

There must be a way to validate Security Tokens that are sent to BAR.com alone with the request. Requests without security tokens, invalid tokens and untrusted tokens must be denied too. Therefore BAR.com services must be secured and must be modified in a way to validate security tokens. Most of the real world cases, APIs that are exposed could not be modified. Because these legacy systems can not be changed in a simple manner and APIs may be used by many other legacy systems. Therefore, the best way is to use a Enterprise Service Bus (ESB) by fronting these legacy systems and expose the APIs in a modified manner. Typical ESB can be used to add security to SOAP services (using WS-Secutity and further validation logics) and REST APIs (Using Basic Auth, OAuth and further validation logics ). As an example, ESB can secure a SOAP service using WS-Security, in such a manner that, It would look for SAML token as the security token. Therefore in BAR.com domain, ESB can be deployed.

Creating the trust between Domains

As FOO.com and BAR.com domains have created a partnership. So there must be a way to create a trust between these domain. Basically, Security Token that is issued by FOO.com domain must be trusted by the BAR.com domain. There are few ways that trust can be created.

1. ESB (or Server in BAR.com domain) trusts the STS of FOO.com.

  •  If Security Token is signed, Signature of the token can be validated. To validate the signature public certificate of the STS in the FOO.com domain must be within the ESB.
  •  ESB can talk to validation service of the STS in FOO.com and validate the token using it.

2. ESB (or Server in BAR.com domain) does not trust the STS of FOO.com. But it trusts only the STS in its own BAR.com domain. But STS in both domains trust each other.

  • ESB talks to validation service of its own STS and then STS can talks the validation service of STS in FOO.com domain.

  • Application in FOO.com, sends the received security token to STS in BAR.com and exchange with a security token that is trusted by BAR.com

  • If BAR.com services have been secured with a separate mechanism (not to accept the token issued by FOO.com STS),  STS in BAR.com can do the token exchange.  As an example,  SAML2 token must be exchanged with OAuth tokens, to access  the OAuth secured REST services.

In next few blog post, we are going to implement these scenarios with open source STS and ESB.