Federated identity management architecture

Federated Identity Management (FIM) architecture is a framework that allows multiple systems and organizations to share authentication and identity information securely. This architecture enables users from one domain (identity provider) to access resources in another domain (service provider) without needing to maintain separate credentials for each domain.

Here is a breakdown of key components and a step-by-step architecture for implementing federated identity management:

1. Identity Providers (IdPs)

An Identity Provider is a system that authenticates and verifies the identity of users. It holds and manages user credentials (e.g., usernames, passwords, MFA) and provides authentication services to other systems. Popular identity providers include:

• Active Directory Federation Services (ADFS)
• Azure Active Directory (Azure AD)
• Okta
• Google Identity
• Facebook

The identity provider can authenticate the user via Single Sign-On (SSO) and then provide identity tokens to access other systems or applications.

2. Service Providers (SPs)

A Service Provider is an application or system that relies on an Identity Provider for user authentication and authorization. Once the user is authenticated by the IdP, the Service Provider will trust the identity and provide access to the resources.

Examples of service providers are:

• A web application
• An internal enterprise system
• A third-party service (like a CRM, ERP, etc.)

The service provider typically needs to trust the identity provider for user authentication, which is accomplished through a trust relationship.

3. Security Tokens

Security tokens are used to communicate identity information between IdPs and SPs. These tokens can come in several forms:

• SAML (Security Assertion Markup Language): Widely used in enterprise systems, especially for Single Sign-On (SSO).
• OAuth 2.0 / OpenID Connect: Modern protocols used for web and mobile apps that enable the transfer of access tokens and identity information in a secure manner.

The token typically includes user identity attributes (e.g., email, roles, group membership) and expiration times to help manage session lifetimes.

4. Trust Relationships

A trust relationship is a mutual agreement between the Identity Provider and Service Provider. This relationship ensures that both systems can rely on each other’s authentication and authorization mechanisms.

• SAML Federation: In SAML-based federations, Service Providers are configured with information about which IdPs they trust.
• OAuth/OpenID Connect Federation: With OAuth and OpenID Connect, federated trust is established by registering the IdP with the SP and exchanging public keys to ensure the tokens are signed correctly.

5. Authentication Flow (Single Sign-On)

In a federated identity management architecture, a typical Single Sign-On (SSO) flow works as follows:

1. User Accesses Service Provider: The user attempts to access a protected resource on a service provider (SP).
2. Redirection to Identity Provider (IdP): The SP detects that the user is not authenticated and redirects the user to an Identity Provider (IdP) for authentication.
3. User Authentication: The IdP verifies the user’s identity (via username, password, multifactor authentication, etc.).
4. Token Generation: Upon successful authentication, the IdP generates a security token (SAML assertion or OAuth token) that contains identity information (e.g., user details and permissions).
5. Token Exchange: The token is passed back to the Service Provider.
6. Access Granted: The SP validates the token (typically through a public key or shared secret), and if valid, grants the user access to the requested resource.

6. Authorization (Role-based Access Control)

Once authentication is successful, the authorization phase takes place. Here, the user’s roles and permissions, embedded within the token, are checked to determine what level of access the user should have in the service provider’s system.

Federated identity systems typically use Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) models for controlling what actions users can perform.

7. User Attribute Mapping

In federated identity management, it is important to map the user attributes sent by the Identity Provider to the attributes used by the Service Provider. For instance, the IdP might provide the user’s email address, but the SP might require a specific role or permission to grant access.

This can be done through attribute mappings:

• SAML Attribute Mapping: SAML allows passing attributes like userRole, email, etc.
• OAuth Scopes and Claims: In OAuth/OpenID Connect, user attributes are passed as claims, which can be mapped to roles/permissions in the SP.

8. Multi-Factor Authentication (MFA)

For enhanced security, many federated identity systems implement Multi-Factor Authentication (MFA). MFA requires users to verify their identity using two or more forms of authentication (e.g., something they know, something they have, or something they are).

This can be integrated into the authentication flow of the Identity Provider. Once the user provides the first factor (password), they may need to provide a second factor, such as a one-time password (OTP) from an app like Microsoft Authenticator or Google Authenticator.

9. Federation Metadata

To simplify the setup of federated relationships, Identity Providers and Service Providers often exchange federation metadata. This metadata contains information about:

• The IdP’s URLs for authentication and logout endpoints.
• The public key used by the IdP to sign tokens.
• The supported protocols (e.g., SAML, OAuth).
• Supported claims and attributes.

By exchanging metadata, Service Providers can automatically configure and establish trust relationships without needing manual configuration of each endpoint.

10. Use Cases for Federated Identity Management

• Enterprise SSO: Employees can access multiple corporate applications (e.g., CRM, email, document management) without needing separate logins.
• Third-party SaaS Integrations: Users can log into third-party applications (like Salesforce, Office 365) using their corporate credentials.
• Cross-Organization Access: Businesses can allow external partners or contractors to access specific resources (such as APIs, documents, or internal systems) without needing to create a separate account for each user.
• Cloud and Hybrid Environments: Federated identity management allows for consistent access controls across both on-premises and cloud systems.

---

Key Technologies and Protocols in FIM

• SAML 2.0: Used for federated Single Sign-On (SSO) in enterprise applications.
• OAuth 2.0: A framework for authorization, enabling third-party apps to access user resources without needing their credentials.
• OpenID Connect (OIDC): An identity layer on top of OAuth 2.0, used to authenticate users and provide identity details.
• Active Directory Federation Services (ADFS): A Microsoft solution for implementing SSO and federated identity management, typically used with enterprise systems.