Home > Candidate Patterns > Federated Identity

Federated Identity

How can one achieve single-sign-on for services and applications residing in different enterprises and in the cloud?


Direct Authentication is impractical to use when consumers need to access a large number of services within an enterprise. Brokered Authentication effectively solves that problem by creating an enterprise resource that handles authentication on behalf of the rest of the services. By so doing the business services are relieved from the task of identifying users and it is possible to get a single-sign-on for the enterprise. However, in many cases users need to use services across enterprise borders and even services that reside in the cloud. These services do not accept tokens (or credentials) issued by your Authentication Broker.


Establish a trust relationship between your Authentication Broker and the Authentication Broker of the business services that your users needs to access. Use tokens issued by your own Authentication Broker to obtain tokens from the other Authentication Broker and send those obtained tokens to the business services that doesn't accept your tokens.


The kind of Authentication Broker that is normally used for this kind of setting is a Security Token Service (STS) that issues SAML tokens. Since SAML is a widely adopted technology agnostic standard it will be possible for STS's that trust each other to understand the tokens (SAML ticket) of the other party and thereby being able to create a new token based upon the token of the other party.


The Brokered Authentication pattern establishes a single point that manages security information for an enterprise, and thus introduces a single point of failure as well as a single point where the security of an entire Service Inventory can be breached. The Federated Identity pattern adds to this risk as the security of a Service Inventory can be compromised if any of the Authentication Brokers that your Authentication Broker trusts are breached.


Enterprise, Inventory, Composition, Service


Under Review


Herbjorn Wilhelmsen, Thomas Rischbeck


Direct Authentication, that is making every service or application authenticate users by themselves through an active sign-in, is impractical to use when end users need to access a large number of services within an enterprise. The situation becomes even more impractical and difficult when a user task is to be performed through Composition that involves multiple service calls behid the scenes. Brokered Authentication effectively solves that problem by creating an enterprise resource that handles authentication on behalf of other services and applications. By so doing these services and applications are relieved from the task of identifying users and it is possible to get a single-sign-on for the enterprise.

With more intensive collaboration amongst enterprises, and after mergers and acquisitions, we again have a problem where users need to be registered and authenticated in several Authentication Brokers. If Alice works for Enterprise A and suddenly also needs access to services in Enterprise B it is not enough to have her registered as a user only in Enterprise A. To register her as a user for Enterprise B too will give rise to additional work and risks. In order for Alice to do her work administrators in two different enterprises must grant her rights. When Alice quits her job two administrators have to revoke her rights or disable her user accounts altogether.

PKI-based solutions that use certificates for authentication cannot address these requirements. Complex PKI authorities are very time-consuming in their management. Also, services will need additional information (apart from user identity and other standard certificate info) that describes the entity and its roles. Such sensitive information must be targeted and should not be sent to all external enterprises that business relationships exist with. A certificate-based scheme would also be very inflexible: certificates typically have a validity in the range of a year or longer (unless revoked). Role- and other attribute information that is relevant for authorization decisions at a business partner's services often underlies a more frequent change cycle (for example, when the user changes position).

One possible workaround is to allow services from Enterprise B to accept tokens issued by Enterprise A If this is your strategy you must define all authorization logic and security policies twice for each service that Alice wants to use, and also make sure that the correct version of logic / policy is applied by examining the token that is appended to each request. Another alternative is to create two separate ways to access each service / application and let these different access points have different policies and authorization logic.

When we take cloud computing into this reasoning it gets very clear that the problem is very big. How can we effectively manage identities for users that can reside in a multitude of enterprises? Or, alternatively, how can we manage a lot of authorization logic and security policies?

Solution / Application

When two enterprises collaborate it is necessary to have some level of trust between them. This is always a business decision, and not related to technology. But as soon as users from the different enterprises want to access each others IT resources technology will matter. The Federated Identity pattern suggests that the trust relationship between enterprises should be extended to Authentication Brokers. When Alice wants to access a service that resides in Enterprise B (that may be a cloud provider) she can use her token issued by the Authentication Broker in Enterprise A to obtain a token from the Authentication Broker in Enterprise B. The services in Enterprise B will then trust the token from its own Authentication Broker, as illustrated in the figure below.


Before any transactions in the systems starts the Cloud Service (the service with a Cloud symbol) from Enterprise B has a trust relationship to the Cloud Authentication Broker (the service with a Lock and a Cloud symbol) that resides within its own enterprise; also the Cloud Authentication Broker has established a trust relationship to the Authentication Broker (the service with a Lock symbol) from Enterprise A. To use the Cloud Service Alice will 1) Sign-in (actively) to the Authentication Broker within her own enterprise and receive a token. 2) Post that token to the Cloud Authentication Broker (a passive sign-in), 3) Receive a token from the Cloud Authentication Broker and finally 4) Request that the Cloud Service performs something and send the token from the Cloud Authentication Broker as a part of that request.

This shields the services and applications in Enterprise B from having to accept tokens from Enterprise A. It also shields the services and applications from having to translate between the claims located within the token issued by Enterprise A to the claims that should exist in tokens issued by Enterprise B. For instance credentials in Enterprise A may present the users email address in a claim called 'email', while in Enterprise B it is presented in a claim called 'e-mail'. Another example of a possible translation is that all users that originate from Enterprise A automatically obtain a set of default roles in Enterprise B.

When Alice needs to be granted more rights in Enterprise B, some additional claims may have to be added to the token that Alice obtains from Enterprise A. When Alice quits her job, her user account can be deactivated in Enterprise A, after which she will not be able to access any services or applications in Enterprise A or Enterprise B.

In order to make this work, especially in Cloud Computing, it is necessary to base the solution on a technology agnostic standard. The standard that is most widely accepted today is SAML (Security Assertion Markup Language). Setting up a trust relationship between Authentication Brokers then becomes a matter of specifying how information is transferred (e.g. which version of SAML) as well as what kind of information that is relevant (e.g. the name of the email address claim or what roles a user that performs a passive sign-in should be assigned). Another paramount part of the trust relationship is the ability to know who the SAML ticket was issued by and that the ticket is unaltered when it is used for a passive sign-in. To achieve this XML signature is applied. Protection from replay attacks is also important for SAML tokens. This can be achieved by using timestamps as well as only allowing a token to be used once.

When a lot of services and applications from multiple enterprises and cloud providers are to be made accessible knowing what Authentication Broker a specific service of application trusts can difficult. It is therefore a common practice to let services and applications redirect unauthenticated users to the Authentication Broker it trusts so that the end user or calling system knows where to obtain valid tokens for the resource that they are trying to access.

Sometimes services and applications need information about users when they are not logged in. Due to this reason another widely adopted practice is to save a snapshot of (some of ) the users' credentials for later reference, this is often referred to as a user profiles. This profile can be refreshed the next time the user signs in. It is also a good idea to have a timestamp attached to this profile so that you at any time know how old this user specific information is.