We get a lot of questions from partners regarding 'federated identity' or 'identity federation', 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.
Identity federation, federated identity or federated identity management (FIM) are terms that you may have only heard about, yet it is likely that you have used or experienced them in action without realising it.
To understand identity federation, an entity called Identity Provider should be explained first.
An Identity Provider (IdP) is an entity that is responsible for the creation and management of users. An IdP authenticates the user anytime he/she tries to log in to an application, and then sends that information to other applications that rely on the IdP to do its job.
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.
And that leads us to federation, which is basically two Identity Providers talking to and trusting each other.
Identity federation is the process where the authentication responsibility of a user is delegated to an external partner.
Think of it as two partners: one of them (Identity Provider) provides the identity of the user, the other provides only the service or application the user is trying to access. The second partner (let’s call it Service Provider) delegates the authentication responsibility to an external, trusted party - the Identity Provider.
This process is called federation, where the Identity Provider “vouches” for the identity of the user, the Service Provider trusts the IdP, and allows the user to access whatever the service or application is.
In practice, this makes life easier and faster for the user, as the user only has to login once. It also increases security, as the user only has to remember one set of credentials (provided that they’re using a strong password).
In corporate environments, and within a corporate network, Microsoft's Active Directory (AD) is a common user directory that is responsible for user authentication within the corporate domain. When combined with Active Directory Federation Services (ADFS), AD is then able to interact with other online services and ADFS is an Identity Provider that supports federation. In online environments, Google Account can be used as an alternative Identity Provider, and Microsoft also has Azure AD.
However, there are also 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', for a large corporate customer, 'GlobalCo'.
If identity federation has not been implemented, 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 login 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 of the most popular user directories in use by business worldwide. To login to 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, which is the process called 'federation'.
Here the 10Duke Identity Provider would delegate authentication to Active Directory (via the AD add-on called Active Directory Federation Services) and 'trust' that AD has authenticated the employee correctly and then allowed her access to the DesignX application without her having to re-enter the username and password for the DesignX application.
In this context, the terms 'federation', 'federated identity', and 'federated identity management' can all be used synonymously.
Federated identity management increases the security of the overall connected systems and simplifies the login process improving organisational productivity.
Going back to the example from earlier: 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. This is because 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.
Having federated identity implemented is also a time-saver. Imagine there are 10 or 20 applications that an employee needs daily, some of them might be modern cloud applications, but some of them are applications installed on-premise. For each of those applications, the employee must have a username and a password. To memorize 10 or 20 sets of credentials is not easy. It is only human to resort to using the same credentials for many of those applications, but that is a security concern and often forbidden by the company and you'll end up trying to memorize what password variant you're using for which application, losing time that could have been spent actually working. With federated identity only one set of credentials can be used, this time with one, strong password.
But wait, isn't that just Single Sign-On (SSO)?
Federated Identity Management (FIM) and Single Sign-On (SSO) are closely related, but they are not the same. There is a clear distinction between them and they are in no way synonymous.
Yes, Single Sign-On, as the same suggests, allows a user to sign in to multiple services or applications with a single login. However, Federated Identity Management reaches much further. While SSO gives you access to applications or systems within an organisation, with FIM you can access applications or systems across several different enterprises. It is a broader concept where two identity management systems are connected and work together seamlessly, based on mutual trust. As a result, Federated Identity Management can give you SSO, but it doesn't necessarily work the other way around.
For example, anytime you use your Facebook account to access a service such as Airbnb, you're seeing identity federation in action. This is because Facebook and Airbnb are completely separate systems, but with FIM you can use one to access the other. However, when you use your Google account to access Gmail and Google Maps you're still within the same "organisation", meaning you're using SSO. But if you were to use that Google account to access Quora message boards, then it would be FIM again. For the user, the distinction can become blurry in practice, which is a sign that the user experience is smooth.
We are increasingly seeing federation being referred to as “SAML SSO”. If a company says that it supports SAML SSO what they likely mean is that they support identity federation. A user identity stored and authenticated in an Identity Provider that uses SAML 2 simply means that it is using the SAML 2 standard to authenticate and exchange user identity information with connected systems or applications for the purposes of Single Sign On.
In more simple terms, a user (whose profile is stored in a SAML 2-based Identity Provider) can use her same login credentials to access multiple applications but only be required to login once, assuming that SAML SSO has been implemented for all connected applications. “SAML SSO” and “federated identity” in this case can be considered synonyms.
We have seen first hand how identity federation 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 supports identity federation, this is a major check mark from most CISOs (Chief Information Security Officer) - in effect the vendor is saying it "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".
Federated identity is 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.
If you are considering identity federation or have any questions, please contact us at 10Duke.
We get a lot of questions from partners regarding ‘federated identity’ or ‘identity federation’, 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.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.