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 and other is  has  developed several applications to use for their employees. Employees can access these applications by authenticating with the user store of domain. has several  SOAP services and REST services that have been exposed from their legacy systems.

As time goes, establishes a partnership with applications wish to access the services that are in the  Therefore must expose their services to domain.  Then 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 user store with and then 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 domain. So, what would be the solution?
If there is some way, If we can propagate the user’s identity data in to, that would be great…!!!

So, Users in the could be authenticated with its own user store. And the user identity data could be propagated to in to 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 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 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 domain STS must be deployed.

Securing SOAP & REST API

There must be a way to validate Security Tokens that are sent to alone with the request. Requests without security tokens, invalid tokens and untrusted tokens must be denied too. Therefore 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 domain, ESB can be deployed.

Creating the trust between Domains

As and 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 domain must be trusted by the domain. There are few ways that trust can be created.

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

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

2. ESB (or Server in domain) does not trust the STS of But it trusts only the STS in its own 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 domain.

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

  • If services have been secured with a separate mechanism (not to accept the token issued by STS),  STS in 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.