Design Patterns for Cloud: Federated Identity Pattern
Federated Identity Pattern is a cloud design pattern that is used to delegate authentication responsibility to an external identity provider. It’s a useful pattern when your application needs to provide Single Sign-On (SSO) experience to the users, where applications needs to authenticate users with multiple partners, in Software as a Service (SaaS) applications where tenants of the SaaS application can authenticate using a suitable identity provider etc. Let’s look at what are the reasons behind using Federate Identity Pattern, what is the solution the pattern provides and what are the considerations and issues with the pattern you need to understand before using the pattern.
Why Should We Use the Pattern?
In any application, doesn’t matter if it is a web, mobile or a desktop application, if the application has restrictions to access its content, then the users of the application needs to be authenticated in order to access the application. The application needs to have a record of the user and his/her capabilities in order to authenticate. This record is called the Identity of the user. An Identity is a representation of the user and specifies what the user has access to in the application. Normally an application would store the identities of the users in a database to be used in authenticating the user.
Today, users deal with a large number of applications, be it an On-Premise Application or a Cloud Application. This is the case even in an enterprise scenario. Normally what happens is that the user has to register with the application and create a username and password to authenticate. If the user needs to access 10 applications the this has to be done 10 times and that is 10 passwords to remember. This leads to forcing bad password practices. What this leads to normally is that the users will reuse passwords, which is a bad practice. This allows the uses password to leak even if one application gets compromised and automatically leaving all the applications that users uses to be vulnerable.
Let’s take a scenario in a corporate environment, where employees have to use 5 applications that needs authentication to access each one of them. As mentioned above, if each individual apps needs to login, then its 5 usernames and passwords. Then imagine suddenly an employee is terminated and his access from these applications needs to be removed immediately. Then the operations team needs to individually remove the user from 5 different applications which is difficult to manage and error prone. If Ops team makes a mistake, then that user may still have access to some applications.
So, this scenario is a headache to the Operations teams to manage and a hassle to the users at the same time since they have to remember 5 different passwords to login. Overall a poor user experience all round. Not only that, this approach is complex when it comes to development and maintenance, where you have to develop 5 different authentication mechanisms for each application and maintain them. And it’s difficult to keep the systems safe and secure from outside threats since your focus and time is divided between multiple applications. Also, managing user credentials is no easy task and require a lot of responsibility and attention which is something organizations are not really fond of. And as mentioned above, User Administration is really difficult.
What Federated Identity Pattern Brings to the Table?
Federated Identity Pattern removes these problems and provide you with a robust way of authenticating the users by separating the authentication from application code and delegating the authentication to a Trusted Identity Provider (IdP). This decuples authentication from authorization, where Authentication is the responsibility of the Identity Provider and Authorization is the responsibility of the Application itself. These trusted identity providers can be Corporate Directories, On-Premise Federation Services, and other Identity Providers like Business Partners and Social Identity Providers like Facebook, Twitter, Google etc.
This allows the users not to enter their credentials for each and every application they need to login, by doing so hiding the user credentials from all the other applications except the original identity provider. This removed the overhead of managing the user credentials from the individual applications. Providing a Single Sign-On (SSO) experience that is much more user friendly and will improve overall User Experience.
This also allows to include more advanced identity management features like Two-Factor/Multi-Factor Authentication, Password Change Reminders, Stricter Password Policies to insure had to crack passwords which was difficult and expensive to implement in individual applications. And if we take the previous scenario where a user has access to 5 corporate applications and that user gets terminated, then the Ops team only needs to remove the user from one location and the user will automatically be removed from all the applications. Which is great from the perspective of the Operations team when it comes to Managing Users.
How Federated Identity Pattern Work?
To explain how Federated Identity Pattern works, let’s take an example where a user needs to access an application that requires authentication.
The flow of authenticating is like this.
1. The user navigates to the secure application
2. Applications tell unauthenticated user to authenticate at the Identity Provider (IdP)
3. User Authenticates with the Identity Provider (E.g. Entering username & password)
4. Identity Provider providers an Access Token to the user (claims may be included)
5. User goes back to the application with the Access Token
Here, the users navigate to the application to access its content. But the application is secure and it detects that the user is not authenticated and tells the user to authenticate at the Identity Provider (IdP). The user is redirected to the Identity Providers login screen since the application knows about the Identity Provider and trusts the IdP. Then the user enters his/her credentials and after authenticating the Identity Provider issues an Access Token to the user. This access token can include Claims that can be used to authorize access to certain content in the application. The user then goes back to the application with the access token and then the application allows access to the content of the application according to the authorization of that user (authorization level can be decided using the claims that came with the Access Token)
In the above diagram the Identity Management is the Identity Provider, this is a common implementation where Identity Management Application acts at an Identity Provider and the Secure Token Service (that provides the Access Token). The Identity Management can also be integrated with External Identity Provides such as Azure Active Directory, ADFS etc. and provide User Administration and Management capabilities.
As mentioned above the Identity Provider can be included in to an Identity Management application that integrates with external identity providers. Take a look at the diagram below.
In this diagram, you can see a high-level overview of real world implementation of this pattern. Here the Identity Management acts as the Identity Provider for the mobile, web and desktop apps that has a Trust Relationship with the Identity Management system. It also integrates with external Identity Providers like Azure AD, ADFS, Social Providers and other Identity Provider Services. The Identity Management system has User Administration and Management capabilities where Operations Teams can quickly perform user administration tasks like removing users from the system, controlling access to certain applications/resources, managing password policies etc. This makes is so much easier for operations teams to handle these at a single place rather than looking at 5–10 different systems.
Most of the time the External Identity Providers that are connected to the Identity Management does not provide a lot of information about the user. Most of the time what External IdPs would provide is the email address of the user or some unique ID that is associated with the user. Then Identity Management System has the responsibility to associate this identifier with a specific user that tries to login to applications that has a trust relationship with the Identity Management system and creates the Access Token with the necessary details included as Claims and pass this token along to the user to login in to the applications.
Things to Remember
It’s important to understand that Identity Management System is a Mission Critical Production System. It’s not a part of your application(s) but without it your application(s) will not work since no user can authenticate. This makes the Identity Management System a Single Point of Failure. Therefor to ensure your users can always login and use the application(s) you need to make sure that Identity Management System is always Available, Secure and Performs exceptionally well.
This is an issue if your Identity Provider (IdP) also acts as the Identity Management System (as seen in the above diagram) So, having a fully featured Identity Management System has its drawbacks as well. To eliminate these issues with availability, security and performance you can opt for Identity Management as a Service offering if it suits your requirements.
It’s very important to understand that The Identity Management System (and Identity Provider as well) does NOT Provide Authorization for the user, it Only Provides Authentication. It’s the applications responsibility to implement authorization mechanism using the details provided by the Identity Management or Identity Provider (via claims).
When to Use Federated Identity Pattern?
You can use the Federated Identity Pattern when you need to provide Single Sign-On (SSO) Experience to the user. Where a single external Identity Provider can be used to seamlessly login to a number of applications. This provides a better user experience.
You can Allow Access to External Users to your applications with this pattern. This may be a partner company your organization works with in a Business to Business (B2B) scenario or you can also open up your applications to customer that can use their social accounts to login in a Business to Consumer (B2C) scenario. The identities for this scenario lives with in the external identity provides, and these IdP has a trust relationship with the Identity Management System.
You can also provide Federated Identity for your SaaS Applications. This is a common scenario where Independent Software Vendors (ISVs) provide a SaaS offering to multiple clients. With this ISVs, can provide the flexibility to use their own identity provider. Each client can bring in their own existing Identity Provider and authenticate to your application. The Identity Management System in the SaaS application sits in the middle of this and provides the capabilities to configure identity providers, Manage users and user access etc.
This article gives you a high-level understanding of what Federated Identity Patter is and where, when and how to use it. It also provides information about what to look out for when implementing this pattern in your applications. For more information refer to the Cloud Design Patterns — Federated Identity Article in Microsoft Technical Documentation.
