We get a lot of questions from partners regarding ‘federation’ or ‘federated identity’, so we thought we’d do a short summary to explain what it is and how you can use it to help your users and your business. The profiles you hold on your users (their first name, last name, gender, email, age, etc.) are held in a database of an Identity Provider (IdP). This IdP, depending on its capabilities, can then speak in one or more ‘languages’, or more accurately data formats, such as OAuth 2 or SAML 2.
The IdP is responsible for authenticating a user each time he/she tries to log-in to an application. In corporate environments, and within a corporate network, Microsoft’s Active Directory is a very common Identity Provider that is responsible for user authentication. In online environments, Google Account can be used as an alternative Identity Provider, Microsoft has Azure AD and there are white-label, cloud-based Identity Providers such as the 10Duke Identity Provider. Regardless of vendor, each Identity Provider is responsible for authenticating the users held in its database.
Now, suppose that you are an application vendor selling a web application, ‘DesignX’, into a large corporate customer, ‘GlobalCo’. In order to access DesignX, the employees of GlobalCo have to log in to their corporate network, fire up a web browser, navigate to your url and then log-in to the DesignX application. They have had to log in twice, which isn’t the end of the world, but it is a bit of a pain and potentially insecure as they have to remember two sets of usernames and passwords. This is where federated identity can help.
To login to the GlobalCo network, the employee will likely be logging into Active Directory, one IdP. To login into the DesignX application, they would be logging-in to another IdP, such as the 10Duke IdP. What you can do is connect the two Identity Providers, a process called ‘federated identity’, wherein the 10Duke Identity Provider would delegate authentication to Active Directory (and an AD add-on called Active Directory Federation Services, but let’s skip that for now) and ‘trust’ that AD has authenticated the employee correctly and then allowed him/her access to the DesignX application without him/her having to re-enter the username and password for the DesignX application. In this context, ‘federation’, ‘federated identity’, and ‘federated identity management’ can all be used synonymously.
In addition to improving the usability of the DesignX application and making it easier for the employee of GLobalCo to access it, identity federation also serves to increase the security of the overall (now connected) systems as there is a single database of usernames and passwords, rather than two. Provided this first database is adequately and properly secured, the system itself is more secure. Additionally, in this case, AD remains as a single point of user provisioning (and de-provisioning). If an employee leaves GlobalCo and she is removed from AD, she will no longer be able to access the DesignX application.
We have seen first hand how federated identity can be a key selling tool for application vendors trying to sell to large customers who have strict security requirements. When the potential customer asks the application vendor if its authentication system is secure, if the vendor’s IdP supports federation, it enables the vendor to answer the question simply by saying ‘we support federated identity and therefore provided you’re happy with how you authenticate your own employees, they will use the same method to access our application’. A very simple and very powerful selling feature to support. And as you might expect, the 10Duke Identity Provider supports federated identity. You can also learn more on Wikipedia.