What is Federated Identity Management?

Introduction

Federated identity management is an arrangement that can be made between two or more trust domains, to allow users of these domains to access applications and services using the same digital identity. This is known as federated identity and the use of such a solution pattern is known as identity federation.

Federated identity management is built upon the basis of trust between two or more domains. For example, a trust domain can be a partner organization, a business unit, a subsidiary, etc.

In any digital organization today, identity and access management (IAM) is a specialized function that is delegated to a service provider known as an identity broker. This is a service that specializes in brokering access control between multiple service providers, and is also referred to as relying parties. Federated identity management is an arrangement made between two or more providers across organizations.

Identity brokers could be known by other names depending on the role they play in federated identity management. These names are not standardized across the industry, although used in common parlance and may be used interchangeably. Therefore, it is important to specify these names with the relevant context whenever they are used and depending on the arrangement, an identity broker may play more than one role.

These roles include:

1. Identity Provider
2. Resident Identity Provider
3. Federated Identity Provider
4. Federation Provider
5. Resident Authorization Server

Here is a quick description of each role.

An identity provider is responsible for asserting digital identities with claims for service providers to consume.

A resident identity provider is defined with respect to a digital identity, and is t responsible for asserting the digital identities within its trust domain. Sometimes this is also referred to as local identity provider or incumbent identity provider.

A federated identity provider is defined with respect to a trust domain, and is responsible to assert digital identities that belong to a second trust domain. A trust relationship is established between the two.

The term federation provider denotes an identity broker that specializes in mediating IAM operations between multiple service providers and multiple identity providers, based on trust relationships.

A resident authorization server is defined with respect to a service provider, and is where the logical representation of the application or service provider resides. It is responsible for authenticating and authorizing the application or service provider for the requested access.

Benefits of Identity Federation

1. Provides a seamless user experience as users are required to remember only one set of credentials.
2. Single-sign-on is supported in most implementations.
3. Avoids administrative overheads by delegating account and password management responsibilities to the resident identity provider, instead of having to manage multiple identity silos.
4. Simplifies data management and storage costs.
5. Avoids privacy and compliance burdens.

Examples for Federated Identity Management Use Cases

1. Federated Identity Management provides access to users from supplier, distributor, and partner networks.
2. Federated Identity Management provides access to new users outside the traditional organization perimeter after mergers and acquisitions.
3. Federated Identity Management provide access to users from commercial identity providers like banks, for example, Third Party Payment Providers (TPPs) in PSD2.rovide access to users from commercial identity providers like banks, for example, Third Party Payment Providers (TPPs) in PSD2.
4. Federated Identity Management provide access to citizens using a national identity provider, for example, DigiD, Emirates ID, etc.
5. Federated Identity Management provides access to users who own a public organization ID, for example, ORCID ID.
6. Furthermore, this allows use of social logins (sign-up/sign-in/connect), for example, Facebook, Google, LinkedIn, etc.
7. Additionally, it can be used as a temporary arrangement to support transitioning between IAM systems.

Inbound and Outbound Identity Federation

Identity Federation is broadly categorized into two areas:

1. Inbound Identity Federation
2. Outbound Identity Federation

In an identity federation flow, one identity broker which receives an assertion from another is known as inbound identity federation. This allows you to provide access to your applications and services to identities that are outside your organization's traditional boundary/trust domain.

Similarly, an identity provider which produces an assertion to be consumed by another identity broker is known as outbound identity federation. This allows identities that you manage to access applications and services that are outside your organization's traditional boundary/trust domain.

Figure 1: Identity Federation between the Enterprise and SaaS Application

Figure 1 illustrates an identity federation arrangement between an enterprise and a SaaS application. The SaaS application is hosted in Azure cloud and its authentication is delegated to a federation provider. The enterprise is a tenant in the SaaS application and the federation provider. The enterprise identity provider (ADFS) is configured as a federated identity provider in the respective tenant of the federation provider in Azure cloud. Thus, a trust is established between the cloud tenant's federation provider and the enterprise identity provider. Therefore, the users in the enterprise identity provider will be able to login to the respective tenant of the SaaS application using their identities in the enterprise identity provider.

The flow described is with respect to authentication. However, in order for users to gain complete access they need to pass authorization as well. Authorization may or may not be part of this federation arrangement.

Identity Federation vs. Single Sign-On

Most federated identity management solutions are implemented in a way in which users are not required to prove their identity more than once per logged-in session. Single-sign-on is not synonymous with identity federation. But, it is a by-product of the way it is implemented.

On the other hand, not all single-sign-on implementations can be categorized as identity federation. For example, Integrated Windows Authentication (IWA) based on the Kerberos network authentication protocol, is an example of a single-sign-on implementation across applications and services, but not considered an example of identity federation because it is limited to a particular network.

Bring Your Own Identity

The phrase Bring Your Own Identity (BYOID) became popular following the trend of using social identities to gain access to applications and services. Although BYOID is commonly used in the context of social identities, the concept applies to any federated digital identity issued by government, non-governmental organizations, or enterprises.

Use cases 3, 4, 5, and 6 are all examples of BYOID, and are commonly found in Customer IAM (CIAM). They can be further divided as BYOID for sign-up, sign-in, and to connect. Although all these 3 use cases follow a similar flow, there are subtle differences in the objectives of these use cases.

The objective of “BYOID for sign-up” is to improve the user experience of the self sign-up process by retrieving a part of to complete profile information necessary to create an account for the user in the intermediary identity broker, using an identity managed by a third party.

Conversely, the purpose of “BYOID for sign-in” is to make the login flow as smooth as possible to the end-user with minimal prompts for additional input as possible. BYOID for sign-in doesn’t necessarily require to have a local account provisioned in the intermediary identity brokers.

Finally, the intention of “BYOID to connect” is simply to enrich/fill the local user profile with additional/missing information.

Federated Account Linking

One of the key features of a federation provider is linking digital identifiers of a single identity in multiple federated identity providers to a digital identifier in the resident identity provider. This is known as federated account linking.

Without federated account linking, a federation provider will simply only mediate between a service provider and a federated identity provider. This mode of federation is commonly seen in non-critical applications and services such as public forums, downloading forms, whitepapers, reports, etc. This can be seen in Figure 2 below.

Figure 2: Federated login without account linking

However with federated account linking, in addition to mediating, the federation provider may also provide features such as account management, password management, and entitlements management, as illustrated in Figure 3.

Figure 3: Federated login with account linking

Just-In-Time Account Provisioning

The Just-In-Time account provisioning technique is used to set up an account for the user in an intermediary identity broker on the fly. Just-in-Time account provisioning is a key part of Just-in-time account linking. This concept is better illustrated in Figure 4.

Figure 4: Federated login with just-in-time account provisioning

Just-In-Time Password Provisioning

Just-In-Time Password provisioning is an optional step of just-in-time account provisioning. The need for this type of provisioning generally depends on the combined account and password policies of the organization and the applications the user will be accessing. If you decide to provision a new password for the local account, it is also optional to allow the user to continue signing in using the federated identity.

Home Realm Discovery

Federating with a single identity provider is not sufficient for today’s enterprise needs. Typically there are multiple federated identity providers, known as realms, that are configured, due to the need of supporting multiple partners or multiple social login options. In such cases choosing the resident identity provider, commonly known as the home realm, for the particular user who is trying to access the application or service becomes a challenge, especially in terms of user experience.

Home Realm Discovery (HRD) is the process of identifying the resident identity provider of a particular user in order to authenticate the user and assert the user's identity with claims. HRD was originally a Microsoft term but the concept applies to all modern identity federations. There are no standards around how HRD should be implemented. Each vendor has their own style and as such, it’s hard to support portability.

HRD methods can be automatic or involve manual user interaction. Following are some commonly used methods for HRD:

1. Present a list of options to the user to choose from.
2. Identifier first login — Prompt the user to enter his/her identifier and resolve the identity provider based on the identifier. For example, if the identifier is [email protected], we would know that the identity provider for Johann is Google, initiate an authentication request to Google, and ideally the identifier would be pre-filled in the Google login form so that the user does not have to re-enter his identifier.
3. Selective home realm discovery — Limit the identity providers that are used for a specific service provider. This can be useful in situations where there are multiple federated identity providers that you trust, but have service providers that will only be used and accessed by users in a specific subset of identity providers.
4. Use HTTP query parameters added by the service provider.
5. Use the IP address of the user’s device. For example, intranet users must login using local accounts in an Active Directory (AD), whereas internet users must login from upstream identity providers with multi-factor authentication for additional security.
6. Use headers added via an intercepting proxy server.
7. Use cookies to remember the realm the user previously selected on the device. If cookies are not found, fallback to manual methods.
8. The federated identity provider can itself be a federation provider who in turn federates with other identity providers. In such situations, prompting the user to provide information for HRD at each intermediary federation provider, could be considered poor user experience. Therefore, it may be required to collect all possible information from the user upfront to be routed to the correct resident identity provider.

Supporting IAM Transitions

Identity federation can also be used as a transition strategy for IAM. It can facilitate transitioning from multiple decentralized source user directories to a single, centralized target user directory. In this case passwords will be provisioned. Once all the accounts are eventually migrated, you may decide to disconnect these federated identity providers governing the distributed directories from the ecosystem.

Summary

This article focuses on federated identity management and its usage. There are many identity federation protocols such as Security Assertion Markup Language (SAML2) Web SSO, OpenID Connect, WS-Trust, WS-Federation, etc. Although we haven't looked at any of the specific protocols used to implement federated identity management, the concepts that we discussed remain intact for any protocol that you may choose to implement it with.

WSO2 Identity Server is an open source IAM product distributed under the Apache 2.0 license. It possesses a powerful identity management and identity federation framework, which gives it the ability to play any role of an identity broker, as described in this article, in a federated identity management system.