User Identity and Access Management – What’s the Deal with IDP?

Author:
Innokrea Team

Date of publication: 2024-12-11

Caterogies: Security

Hey there! In today’s article, we at Innokrea will explain what user identity is, why managing access is essential for businesses, and how an IDP (Identity Provider) works. If you haven’t read our article on authentication and authorization yet, we encourage you to do so, as the concepts discussed there will appear in today’s text as well.

What Is Identity Management?

Identity management is a critical component of today’s IT systems and a fundamental process supporting business operations. It involves verifying a user’s identity and managing their access to the company’s resources. This concept encompasses many essential processes, such as authentication, authorization, user account lifecycle management, and ensuring ease of use from the user’s perspective. These concepts can be explained as follows:

Authentication: The process of verifying a user’s identity, confirming they are who they claim to be (e.g., through a password).
Authorization: The process of granting permissions and controlling which resources a user can access based on their verified identity (authentication).
User Account Lifecycle Management: Includes creating accounts, assigning and modifying permissions, automating processes such as account creation and deletion, as well as auditing and monitoring user actions and permissions.
Ease of Use: An essential aspect of modern identity management systems, it impacts user productivity and reduces frustration associated with login processes (e.g., repetitive logins when switching between applications) or password resets.

elementy zarządzania tożsamością użytkownika

Figure 1: Key Elements of User Identity Management (Source: infosec.gov.hk)

The Problem with Traditional Identity Management

Every modern company uses a wide variety of software, such as accounting tools, developer platforms, or financial management applications. Using older approaches from before the advent of SSO (Single Sign-On) and identity management creates significant challenges when hiring employees. Specifically, users are forced to remember multiple (sometimes even dozens) of logins and passwords for different applications, while administrators must manage them from numerous separate points. This is problematic both from a scalability and security standpoint.An administrator tasked with manually registering and deregistering users in multiple systems is prone to mistakes and forced into tedious, manual work. Meanwhile, their focus should ideally be directed toward enhancing the company’s security measures and IT processes.

How to Address Identity Management Challenges?

To address these issues, the concept of the IDP (Identity Provider) was developed—a solution designed to centrally manage identity across multiple applications. This means that the IDP handles user authentication and authorization, and the identity credentials obtained during login to the IDP are then used to verify access to other applications. Effectively, the IDP serves as a TTP (Trusted Third Party)—a reliable intermediary between the user and the application they’re trying to access. This approach simplifies the process for administrators, users, and application developers, as developers no longer need to manage or store passwords. Examples of IDP applications include Google, Azure AD, and Okta.

Działanie IDP

Figure 2: How an IDP Works (Source: infosecwriteups.com)

From the user’s perspective, this works as follows:

Logging into an Application – A user attempts to log in to a chosen application within the company’s system. Since they are not authenticated, their request is redirected to the IDP.
Authentication at the IDP – The application serving as the IDP authenticates the user, for example, through a username and password or using MFA (Multi-Factor Authentication). The IDP also verifies whether the user has access to the application they are trying to reach.
Accessing the Application – If the user is successfully authenticated, the IDP generates a token. This token can then be used by the user to access the original application they intended to reach.

The above concept is known as SSO (Single Sign-On). With SSO, the user logs in once to the IDP system, and the token obtained allows them to access selected applications within the organization. This improves both the user’s convenience and security.

Technical Aspects of the IDP

We’ve introduced the basic principles of IDPs and SSO and explained how their implementation simplifies company workflows. To delve into the technical aspects, we must introduce several additional terms:

Party – An entity involved in the identity management process. The IDP acts as a Trusted Third Party (TTP). Other parties may include the client application (the one the user is trying to access) or other resources. The client application is often referred to as the SP (Service Provider).
Security Domain (Realm) – An isolated area of trust where user identity is managed independently of other domains. For example, these could be two organizations with separate IDPs.
Trust – A relationship established between an application and the IDP that allows authentication at the IDP to grant access to the application. The application trusts the token provided by the IDP and therefore grants access to the user. Trust can also be established between two distinct security domains (federation), such as between two companies with different identity management systems. When different entities merge legally, trust can be established between their organizations, allowing users from one to access resources of the other.
Federation – A trust relationship between two or more security domains. Federation requires the use of an authentication protocol.
Metadata – Data about data, in this case referring to information exchanged to establish trust between organizations or between an application and the IDP via an authentication protocol. Metadata is essential for negotiating and verifying trust within a federation.
Level of assurance – A metric that indicates the confidence in the user’s authentication. This is particularly important in federations, where one organization may consider the other’s authentication insufficient, e.g., relying solely on a password without an additional factor (MFA).
Claim – Information provided by the IDP to the SP during the user authentication process. The request includes data that allows for user identification, their role, and the IDP signature, which is verified by the SP application.
Claim transformation – The process of modifying claims between systems due to differences between federated organizations (in object definitions or authentication protocols used).
Tenant – A separate entity in a multi-tenant system, such as a user of Azure Active Directory. In federated organizations, each organization is often a separate tenant.
Tenant Discovery – During login, the application determines which tenant to contact for authentication, often based on the user’s domain. In federations with multiple IDPs, the request is routed to the appropriate IDP of a separate organization.
Provisioning – The process of creating resources within the infrastructure. In identity management, this refers to creating and deleting (deprovisioning) user accounts. Provisioning is often integrated with other account management systems such as SailPoint or HR systems.
Authentication protocol – A protocol used between an application and an IDP or between two IDPs to establish trust. Examples include SAML or OIDC with OAuth.

Figure 3: The ‘Trust’ Relationship Between Two Organizations in Two Security Realms (Source: microsoft.com)

Example

Since definitions alone are difficult to grasp, let’s imagine an example. Assume there is CompanyA and CompanyB, both of which have their own IDPs and separate organizations. These organizations, after one company acquired the other, have merged. A ‘Trust’ has been configured between the organizations (security domains), specifically their IDPs, at an appropriate level of trust. The scenario of a user from CompanyB logging into Microsoft 365, which belongs to CompanyA, might look as follows:

User Initiates Login – A user from CompanyB (e.g., user@companyB.com) opens the Microsoft 365 application, which is owned by CompanyA, and attempts to log in. On the login screen, they enter their email address.
Tenant Discovery – The Microsoft IDP, which supports the Microsoft 365 application, analyzes the domain provided (companyB.com). Based on this information, it determines that the user belongs to the CompanyB tenant. However, CompanyB is not a direct identity provider for this application. Instead, there is a federation with CompanyA, which manages access to Microsoft 365.
Redirecting the Request – The Microsoft IDP redirects the authentication request to CompanyA’s IDP, with which it has a configured trust relationship. CompanyA’s IDP knows that the user user@companyB.com belongs to CompanyB, so it uses the federated trust to verify the user’s data through CompanyB’s IDP.
Authentication at CompanyB – CompanyB’s IDP verifies the user’s identity (e.g., using their username and password and multi-factor authentication, if required). After successful authentication, CompanyB’s IDP generates a token containing claims such as: email: user@companyB.com role: Employee organization: CompanyB
Claim Transformation at CompanyA – The token from CompanyB is sent to CompanyA’s IDP, which transforms the claims. For instance: The email claim might be transformed into userPrincipalName, as this format is expected by the Microsoft IDP. The role claim might be remapped to a role understood by CompanyA’s systems, such as User. A tenantId claim might be added to clearly indicate CompanyB as the tenant.
Passing Claims to Microsoft IDP – CompanyA’s IDP generates a new token containing the appropriate claims and digitally signs it. This token is sent to the Microsoft IDP, which verifies the signature and checks the claims for compliance with the Microsoft 365 application’s requirements.
Accessing the Application – The Microsoft IDP accepts the token, and Microsoft 365 logs the user in based on the claims within the token. The user is granted the appropriate permissions (e.g., as an employee of CompanyB).

Summary

We hope that this example has helped clarify the technical aspects of identity management. If you’re interested, we encourage you to check the sources and also read our upcoming articles, where we’ll explain how OIDC and SAML work.