introduce

Federated identity management is an arrangement that can take place between two or more trust domains to allow users of those domains to use the same digital identity to access applications and services. This is called federated identity, and using this solution pattern is called identity federation.

Federated identity management is based on trust between two or more domains. For example, a trust domain can be a partner organization, business unit, subsidiary, and so on.

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

Depending on the role an identity broker plays in federated identity management, an identity broker may go by other names. These names are not standardized across the industry, although they are used in common parlance and are used interchangeably. Therefore, whenever these names are used, they must be specified in the relevant context, and depending on the arrangement, the Identity Broker may play more than one role.

These roles include:

identity provider
residency provider
federated identity provider
joint provider
Resident Authorization Server

Below is a brief description of each role.

Identity providers are responsible for declaring digital identities with claims for use by service providers.

Resident Identity Providers are defined for digital identities and are not responsible for asserting digital identities within their trust domain. Sometimes this is also called a local identity provider or an incumbent identity provider.

A federated identity provider is defined against a trust domain and is responsible for asserting digital identities belonging to a second trust domain. A relationship of trust is established between the two.

The term federated provider refers to an identity broker that specializes in mediating IAM operations between multiple service providers and multiple identity providers based on trust relationships.

A residency authorization server is defined for 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 to obtain the requested access.

Benefits of identity federation

Provides a seamless user experience, as users only need to remember one set of credentials.
Most implementations support single sign-on.
Avoid administrative overhead by delegating account and password management responsibilities to a resident identity provider without having to manage multiple identity silos.
Simplify data management and storage costs.
Avoid privacy and compliance burdens.

Examples of Federated Identity Management Use Cases

Federated identity management provides access to users from supplier, reseller and partner networks.
Federated identity management provides access to new users outside the confines of the traditional post-acquisition organization.
Federated identity management provides access to users from commercial identity providers such as banks, for example, third-party payment providers (TPPs) in PSD2. Provides access to users from commercial identity providers such as banks, e.g. Third Party Payment Providers (TPP) in PSD2.
Federated Identity Management uses national identity providers (eg DigiD, Emirates ID, etc.) to provide access to citizens.
Federated identity management provides access to users with a common organizational ID (such as an ORCID ID).
Additionally, this allows the use of social logins (register/login/connect), such as Facebook, Google, LinkedIn, etc.
Additionally, it can be used as a temporary arrangement to support transitions between IAM systems.

Inbound and outbound identity federation

Identity federation broadly falls into two areas:

Inbound Identity Federation
Outbound Identity Federation

In the identity federation process, an identity broker that receives assertions from another identity broker is called inbound identity federation. This allows you to provide access to your applications and services to identities outside your organization's traditional perimeter/trust domain.

Similarly, an identity provider that produces assertions to be consumed by another identity broker is called outbound identity federation. This allows identities you manage to access applications and services outside your organization's traditional boundaries/trust domains.

Figure 1: Identity Federation between the Enterprise and SaaS Application

Figure 1 illustrates an identity federation arrangement between an enterprise and a SaaS application. SaaS applications are hosted in the Azure cloud and their authentication is delegated to a federation provider. Businesses are tenants and co-providers of SaaS applications. An enterprise identity provider (ADFS) is configured as a federated identity provider in the corresponding tenant of the federation provider in the Azure cloud. Thus, trust is established between the cloud tenant's federation provider and the enterprise identity provider. Therefore, users in the corporate identity provider will be able to log in to the corresponding tenant of the SaaS application using their identity in the corporate identity provider.

The process described is about authentication. However, in order for users to gain full access, they also need to pass authorization. Authorization may or may not be part of such joint arrangements.

Identity federation and single sign-on

Most federated identity management solutions are implemented in such a way that users do not need to prove their identity multiple times per login session. Single sign-on is not synonymous with identity federation. However, it's a by-product of how it's implemented.

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

bring your own identity

With the trend of using social identities to access applications and services, the term Bring Your Own Identity (BYOID) has become popular. While BYOID is often used in the context of social identity, the concept applies to any federated digital identity issued by a government, NGO or business.

Use cases 3, 4, 5, and 6 are all examples of BYOID, commonly found in Customer IAM (CIAM). They can be further divided into BYOID for registration, login and connection. Although all three of these use cases follow a similar process, there are subtle differences in the goals of these use cases.

The goal of BYOID for Registration is to improve the user experience of the self-registration process using managed identities by retrieving a portion of the profile information necessary to complete the creation of an account for the user in an intermediary identity broker by a third party.

Instead, BYOID for Login aims to make the login process as smooth as possible for the end user with as few prompts for additional input as possible. BYOID for login does not necessarily require a local account to be configured in the intermediate identity broker.

In the end, the purpose of "BYOID Connect" is only to enrich/populate the local user profile with additional/missing information.

joint account link

One of the key features of a federated identity provider is linking the digital identifier of a single identity in multiple federated identity providers to a digital identifier in a resident identity provider. This is called joint account linking.

If there is no federated account link, the federated provider will only mediate between the service provider and the federated identity provider. This federation model is common in non-critical applications and services such as public forums, download forms, white papers, reports, etc. This can be seen in Figure 2 below.

Figure 2: Federated login without account linking

However, for federated account linking, in addition to mediation, a federation provider can provide account management, password management, and entitlement management, as shown in Figure 3.

Figure 3: Federated login with account linking

Instant account configuration

Instant account provisioning technology is used to instantly provision an account for a user in an intermediary identity broker. Instant Account Configuration is a key part of Instant Account Linking. Figure 4 better illustrates this concept.

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

Instant password configuration

Instant password configuration is an optional step for instant account configuration. The need for such provisioning typically depends on the organization's combined account and password policies and the applications the user will access. Allowing users to continue logging in with federation is also optional if you decide to provide a new password for the local account.

Family Domain Discovery

Federation with a single identity provider is not enough for today's enterprise needs. Multiple federated identity providers (known as realms) are often configured due to the need to support multiple partners or multiple social login options. In this case, selecting a resident identity provider (often referred to as a home realm) for a particular user trying to access an application or service becomes a challenge, especially in terms of user experience.

Home Realm Discovery (HRD) is the process of identifying a particular user's resident identity provider in order to authenticate the user and assert the user's identity through claims. HRD was originally a Microsoft term, but the concept applies to all modern identity federations. There is no standard on how to implement HRD. Each vendor has its own flavor, so it's hard to support portability.

HRD methods can be automated or involve manual user interaction. Here are some commonly used HRD methods:

Provides the user with a list of options from which to choose.
Identifier First Login — Prompts the user for their own identifier and resolves the identity provider based on the identifier. For example, if the identifier is [email protected], we would know that Johann's identity provider is Google, make an authentication request to Google, and ideally the identifier would be pre-filled in the Google login form so the user doesn't have to re-enter his identifier.
Selective Home Realm Discovery - Restrict identity providers to specific service providers. This is useful in situations where you have multiple federated identity providers that you trust, but have service providers that are only used and accessed by users from a specific subset of the identity providers.
Use HTTP query parameters added by the service provider.
Use the IP address of the user's device. For example, intranet users must log in with local accounts in Active Directory (AD), while Internet users must log in from an upstream identity provider with multi-factor authentication for increased security.
Use headers added by intercepting proxy servers.
Use cookies to remember which fields the user has previously selected on the device. Fallback to manual method if cookie not found.
A federated identity provider can itself be a federated provider that in turn federates with other identity providers. In this case, prompting the user to provide information to HRD at each intermediary federation provider may be considered a poor user experience. Therefore, it may be necessary to pre-collect all possible information from the user in order to route it to the correct residency provider.

Support for IAM transitions

Identity federation can also be used as a transition strategy for IAM. It facilitates the transformation from multiple decentralized source user directories to a single centralized target user directory. In this case, a password will be provided. Once all accounts are finally migrated, you may decide to disconnect these federated identity providers that manage distributed directories from the ecosystem.

summarize

This article focuses on federated identity management and how to use it. There are many identity federation protocols such as Security Assertion Markup Language (SAML2) Web SSO, OpenID Connect, WS-Trust, WS-Federation, and others. While we haven't looked at any specific protocol for implementing federated identity management, the concepts we've discussed hold true for any protocol you might choose to implement it with.

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

This article: https://architect.pub/what-federated-identity-management
Discussion: Knowledge Planet [Chief Architect Circle] or add WeChat trumpet [ca_cto] or add QQ group [792862318]
No public	【jiagoushipro】【Super Architect】 Brilliant graphic and detailed explanation of architecture methodology, architecture practice, technical principles, and technical trends. We are waiting for you, please scan and pay attention.
WeChat trumpet	[ca_cea] 50,000-person community, discussing: enterprise architecture, cloud computing, big data, data science, Internet of Things, artificial intelligence, security, full-stack development, DevOps, digitalization.
QQ group	[285069459] In-depth exchange of enterprise architecture, business architecture, application architecture, data architecture, technical architecture, integration architecture, security architecture. And various emerging technologies such as big data, cloud computing, Internet of Things, artificial intelligence, etc. Join the QQ group to share valuable reports and dry goods.
video number	[Super Architect] Quickly understand the basic concepts, models, methods, and experiences related to architecture in 1 minute. 1 minute a day, the structure is familiar.
knowledge planet	[Chief Architect Circle] Ask big names, get in touch with them, or get private information sharing.
Himalayas	[Super Architect] Learn about the latest black technology information and architecture experience on the road or in the car.	[Intelligent moments, Mr. Architecture will talk to you about black technology]
knowledge planet	Meet more friends, workplace and technical chat.	Knowledge Planet【Workplace and Technology】
LinkedIn	Harry	https://www.linkedin.com/in/architect-harry/
LinkedIn group	LinkedIn Architecture Group	https://www.linkedin.com/groups/14209750/
Weibo‍‍	【Super Architect】	smart moment‍
Bilibili	【Super Architect】
Tik Tok	【cea_cio】Super Architect
quick worker	【cea_cio_cto】Super Architect
little red book	[cea_csa_cto] Super Architect
website	CIO (Chief Information Officer)	https://cio.ceo
website	CIOs, CTOs and CDOs	https://cioctocdo.com
website	Architect practical sharing	https://architect.pub
website	Programmer cloud development sharing	https://pgmr.cloud
website	Chief Architect Community	https://jiagoushi.pro
website	Application development and development platform	https://apaas.dev
website	Development Information Network	https://xinxi.dev
website	super architect	https://jiagou.dev
website	Enterprise technical training	https://peixun.dev
website	Programmer's Book	https://pgmr.pub
website	developer chat	https://blog.developer.chat
website	CPO Collection	https://cpo.work
website	chief security officer	https://cso.pub ‍
website	CIO cool	https://cio.cool
website	CDO information	https://cdo.fyi
website	CXO information	https://cxo.pub