Identity and Access Management (IAM): A Comprehensive Overview

Introduction to IAM

Identity and Access Management (IAM) is a critical discipline in the field of cybersecurity, encompassing practices, technologies, and policies that ensure only authorized individuals or systems can access specific resources within an organization’s information systems. This article provides an in-depth exploration of IAM, focusing on basic terminology and technical principles.

Key IAM Terminology

Identity Provider

An Identity Provider (IdP) is a system or service that manages and stores digital identities, and it is responsible for authenticating users and providing them with a way to access various applications, services, or systems securely. The primary role of an Identity Provider is to verify the identity of users and share relevant identity information with other systems in a secure and standardized manner.

Key features and functions of an Identity Provider include: (dont worry if you don’t quite get all the techincal terminology here, the following sections get into some technical details about each)

• User Authentication: An IdP authenticates users by verifying their credentials, which may include usernames, passwords, biometric data, or other forms of authentication.
• Identity Verification:It verifies the identity of users based on the provided credentials. This process is crucial for ensuring that only authorized individuals gain access to protected resources.
• Token Issuance: After successful authentication, the IdP issues tokens (such as Security Assertion Markup Language (SAML) tokens or JSON Web Tokens (JWT)) containing information about the authenticated user. These tokens are used to establish trust and enable Single Sign-On (SSO) capabilities
• Single Sign-On (SSO): Many IdPs support SSO, allowing users to log in once and gain access to multiple applications or services without the need to re-enter credentials for each.
• Federation: In the context of Identity and Access Management (IAM), an IdP often participates in identity federation, enabling users to access resources in different domains or systems with a single set of credentials.
• Attributes and Claims: An IdP provides attributes or claims about the authenticated user, such as name, email, roles, or other profile information, to the relying parties (applications or services) that rely on the IdP for authentication.
• Security Standards: IdPs adhere to security standards and protocols such as SAML, OAuth, OpenID Connect, or others, ensuring secure communication and interoperability with other systems in the IAM ecosystem.
• User Management: IdPs often include user management features, allowing administrators to create, modify, and deactivate user accounts. They may also support features like password management and multi-factor authentication.

Popular examples of Identity Providers include Microsoft Azure Active Directory, Okta, Google Identity Platform, and Auth0. Organizations often choose or implement an IdP as part of their IAM strategy to centralize and manage user identities securely, streamline access to resources, and enhance overall security through standardized authentication practices.

Digital Identities

Digital identities represent entities that interact with an organization’s systems. These entities can include users, devices, applications, or services.

Authentication (authn)

Authentication is the process of verifying the identity of a user, device, or service. It involves presenting credentials, such as a username and password, for validation. For example, when a user enters a password to log into an application, they are undergoing authentication.

Authorization (authz)

Authorization determines what actions or resources an authenticated identity is permitted to access. It involves defining permissions and policies. For instance, a user might be authorized to view certain files but not modify them.

Principle of Least Privilege

The principle of least privilege advocates providing entities with the minimum access necessary to perform their tasks. This minimizes the risk of unauthorized access or accidental misuse.

User Provisioning and De-Provisioning

User provisioning involves creating, modifying, or deleting user accounts and access rights. De-provisioning ensures timely removal of access when a user leaves an organization or changes roles.

Example: When an employee leaves the organization, their access is promptly revoked through de-provisioning to prevent unauthorized access.

Single Sign-On (SSO)

SSO allows users to log in once and access multiple systems or applications without re-entering credentials.

Example: A user, having authenticated to the organization’s network, seamlessly accesses various applications in a cloud environment without additional logins.

SSO, authn or authz?

Single Sign-On (SSO) is primarily associated with authentication (authn), which is the process of verifying the identity of a user. The main goal of SSO is to allow users to log in once and gain access to multiple applications or services without the need to re-enter credentials for each. In an SSO scenario, a user logs in only once, and subsequent access to other applications or services is granted seamlessly.

However, while SSO itself focuses on authentication, it has implications for authorization (authz) as well. Let’s explore both aspects:

1. Authentication (SSO — Authn):

• Primary Focus: SSO’s primary objective is to simplify the authentication process. Users authenticate once, typically through a central Identity Provider (IdP), and receive a security token or session that vouches for their identity.
• Token Issuance: After successful authentication, the IdP issues a token (such as a SAML token or JWT) that contains information about the user’s identity. This token is then presented to other applications or services within the SSO ecosystem.
• Seamless Access: Users can navigate across various applications or services without being prompted to re-enter their credentials. The token serves as proof of authentication, allowing them to access resources without going through the authentication process again.

2. Authorization (Authz) Implications:

• Limited Authorization Information: While SSO itself is primarily concerned with authentication, the tokens issued during the authentication process may contain limited authorization information. This information may include user roles, group memberships, or other attributes relevant to access control.
• Interoperability with Authorization Systems: SSO systems often work in conjunction with authorization systems. The information in the authentication token can be used by individual applications or services to make authorization decisions. For more detailed authorization, applications may need to consult their own authorization systems.
• Role-Based Access Control (RBAC): Many SSO implementations support Role-Based Access Control (RBAC), allowing administrators to define roles and permissions associated with users. This information is typically included in the authentication token.
• Integration with Access Control Systems: SSO solutions may integrate with access control systems to ensure that users, even though authenticated through SSO, are subject to appropriate authorization controls based on their roles and permissions.

Role-Based Access Control (RBAC)

RBAC is a model where access permissions are assigned based on predefined roles associated with specific job functions.

Example: A user in the finance department assumes a role with specific financial system access, determined by RBAC policies.

Multi-Factor Authentication (MFA)

MFA requires users to provide multiple forms of identification before gaining access.

Example: After entering a password, a user receives a verification code on their mobile device for additional authentication.

Technical Principles of IAM

Directory Services

IAM often relies on directory services, such as Microsoft Active Directory or LDAP, to store and manage user attributes, group memberships, and access policies.

A directory service is a centralized and specialized database that stores, manages, and organizes information related to digital identities, such as users, groups, devices, and their attributes within an organization.

Key Characteristics:

1. User Profiles: Directory services store information about individual users, including usernames, passwords, contact details, and other attributes relevant to authentication and authorization.
2. Group Memberships: Users are often organized into groups based on roles, departments, or project teams. Directory services maintain group memberships and hierarchies.
3. Organizational Units (OUs): OUs are containers within a directory service that help organize users, groups, and devices based on their roles or departments within the organization.
4. Access Policies: Directories store access policies and permissions associated with users and groups. These policies define what resources a user or group can access and what actions they can perform.

Some practical examples:

- Microsoft Active Directory: In the context of a Windows environment, Microsoft Active Directory (AD) is a widely used directory service. It stores user account information, including usernames, passwords, and group memberships. It also provides a hierarchical structure with OUs for organizing users and groups based on departments or locations.

- LDAP: LDAP, another common directory service protocol, is a lightweight and platform-independent protocol for accessing directory services. LDAP directories can be used for a variety of purposes, including authentication and authorization in heterogeneous environments.

Benefits:

• Centralized management of user identities simplifies administration, ensures consistency, and enhances security. Directory services also support features like password policies, account lockouts, and account expirations.

IdP vs Directory Service

Directory Services provide a foundational data store that IdPs may use to retrieve and manage identity information.

Authentication Protocols

IAM systems use various authentication protocols, such as OAuth, OpenID Connect (OIDC), or Security Assertion Markup Language (SAML), to facilitate secure authentication and authorization processes.

More on SAML, OAuth, OIDC

• SAML (Security Assertion Markup Language): Used for SSO, SAML facilitates the exchange of authentication and authorization data between parties. When a user logs into an application, the identity provider generates a SAML assertion, allowing the user access to the service.
• OAuth (Open Authorization): Primarily used for delegated access, OAuth enables secure authorization without sharing user credentials. For instance, when a user grants a mobile app permission to access their Google Drive, OAuth facilitates this access without exposing the user’s Google credentials.
• OIDC (OpenID Connect): Building on OAuth, OIDC provides user authentication. It allows clients to verify the identity of end-users based on authentication performed by an authorization server. OIDC is commonly used for web and mobile applications.

Real-Life Example that demonstrates usage of SAML, OAuth, OIDC: Online Document Collaboration Platform

Scenario: Consider an online document collaboration platform where users can create, edit, and share documents. The platform supports different authentication and authorization mechanisms to ensure secure access to documents and resources.

1. SAML for Single Sign-On (SSO) Authentication:

A large enterprise integrates the document collaboration platform into its ecosystem to enable seamless access for employees. The enterprise already has an Identity Provider (IdP) using SAML for authentication.

• When an employee logs into their corporate system, they are redirected to the document collaboration platform. The platform acts as the Service Provider (SP) and requests authentication from the corporate IdP using SAML.
• The IdP authenticates the user and generates a SAML assertion, which is sent back to the platform.
• The document collaboration platform uses the SAML assertion to create a local session for the user without requiring them to enter additional credentials.

Authentication or Authorization?

• SAML is primarily used for authentication in this scenario. It establishes the user’s identity (authentication) and allows them access to the document collaboration platform without a separate login.

2. OAuth for Delegated Authorization:

The document collaboration platform wants to allow users to embed documents in third-party applications. However, the platform wants to control and monitor the level of access granted to these applications.

• Developers of third-party applications register their apps with the document collaboration platform, obtaining client credentials.
• When a user wants to grant access to a third-party app, the app initiates the OAuth flow by redirecting the user to the document collaboration platform for authorization.
• The user authenticates on the platform, and upon consent, the platform issues an access token to the third-party app, allowing it to access specific resources on behalf of the user.

Authentication or Authorization?

• OAuth is used for delegated authorization. While the user authenticates with the document collaboration platform, the focus is on granting the third-party app authorization to access resources on the user’s behalf.

3. OIDC for User Authentication with Profile Information:

The document collaboration platform wants to enhance user experience by providing additional profile information and ensuring secure user authentication.

• OIDC is implemented on top of OAuth to provide an identity layer. When a user logs in, the document collaboration platform uses OIDC to request additional user information from the IdP.
• The IdP responds with an ID token containing user claims, such as name, email, and other profile information.
• The platform uses this information to personalize the user experience and display relevant details.

Authentication or Authorization?

• OIDC is primarily used for user authentication. It extends OAuth by adding an identity layer, allowing the document collaboration platform to obtain user information beyond basic authorization.

Summary:

• SAML (Security Assertion Markup Language):

Use: Authentication.

Example: Enabling Single Sign-On (SSO) for enterprise users accessing the document collaboration platform.

OAuth (Open Authorization):

Use: Authorization.

Example: Allowing third-party applications to access specific resources on the document collaboration platform on behalf of the user.

OIDC (OpenID Connect):

Use: Authentication.

Example: Enhancing user authentication with additional profile information for a personalized experience on the document collaboration platform.

SAML and OIDC — working together

It is possible for an organization to have multiple applications within the same Single Sign-On (SSO) environment that use different authentication mechanisms, such as Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). The concept of having diverse authentication mechanisms within a unified SSO environment is often referred to as “federated identity” or “federated authentication.” (more on this further in the article)

Disparate authn protocols supported by Service Providers within the SSO scope

High level workflow:

1. Federated Identity Provider (IdP): The organization may deploy a federated Identity Provider that supports multiple authentication protocols, including SAML and OIDC.
2. Application Integration: Each application integrated into the SSO environment is configured to support its preferred authentication protocol. For example: Application A might be configured to use SAML for authentication. Application B might be configured to use OIDC for authentication.
3. User Authentication: When a user accesses Application A, the federated IdP initiates a SAML authentication process. When the same user accesses Application B, the federated IdP initiates an OIDC authentication process.
4. SSO Experience: From the user’s perspective, they only need to authenticate once, and the SSO environment takes care of seamlessly authenticating them across applications.
5. Token Issuance: The federated IdP issues the appropriate tokens based on the authentication protocol used for each application. For SAML, it issues SAML assertions, and for OIDC, it issues ID tokens.
6. Access Control and Authorization: Each application has its own access control mechanisms and authorization processes. The tokens issued by the federated IdP contain information that the applications use to determine the user’s access rights.

This approach allows organizations to leverage the benefits of SSO while accommodating applications with different authentication requirements. It simplifies the user experience by reducing the need for multiple logins, even when applications use different authentication protocols.

Access Control Lists (ACLs) and Policies

Access control lists (ACLs) and policies define who can access specific resources and what actions they can perform. IAM systems enforce these rules to control access.

Example: An ACL specifies that only users in the “Admin” role have write access to a particular database, ensuring proper access control.

Audit and Compliance

IAM systems include auditing capabilities to track user activities, changes in access permissions, and compliance with security policies. Auditing helps organizations monitor and analyze security events for regulatory compliance.

Example: An audit log records every login attempt, access request, and modification to access controls, aiding in compliance assessments.

Identity Provider Chaining

Identity Provider Chaining involves a sequential authentication process where a user is authenticated by multiple Identity Providers in a predefined order.

Key Characteristics:

1. Sequential Authentication: Users go through a chain of Identity. Providers one after the other. Each Identity Provider in the chain authenticates the user before passing them to the next in line.
2. Order Matters: The order of Identity Providers in the chain is significant. Users must be successfully authenticated by one IdP before moving on to the next.
3. Fallback Mechanism: There might be a fallback mechanism in place. If authentication fails with one Identity Provider, the process might switch to an alternative one in the chain.

Consider a scenario where a user needs to access a secure application. The organization has set up multiple Identity Providers, and the user must authenticate sequentially. The first IdP might be a traditional username-password system, followed by a multi-factor authentication IdP, and finally, a biometric authentication IdP.

Enhanced Security: Identity Provider chaining is often employed to enhance security by requiring users to go through multiple layers of authentication.

Identity Federation

Identity Federation is a trust-based relationship between different organizations or systems that allows users from one domain to access resources in another domain without the need for multiple authentications.

Key Characteristics:

1. Cross-Domain Access: Users from one organization can seamlessly access resources in another organization’s system without the need for separate logins.
2. Trust Relationship: Identity Federation relies on a trust relationship between participating organizations. Typically, a federation server manages this trust and facilitates the secure exchange of authentication and authorization information.
3. Single Sign-On (SSO): Identity Federation often involves Single Sign-On (SSO), allowing users to log in once and access resources in multiple federated domains without re-entering credentials.

Example Scenario:

Typical Identity Federation set-up that spawns across organizations

• Two companies, CAL and Udemy, have an identity federation agreement. An employee from CAL can access resources in CAL as well as Udemy seamlessly, and vice versa, without the need for separate logins. In both cases the authentication is delegated to the resident IdP

Difference between SSO and Identity Federation

While SSO simplifies access within a single domain, Identity Federation extends these capabilities to enable secure and seamless access to resources across different security domains or organizations. Identity Federation often incorporates SSO as a component but goes beyond it in terms of cross-domain interoperability.

Lifecycle Management

IAM includes lifecycle management features for user accounts, covering creation, modification, and deletion. This ensures that access rights are aligned with the user’s role and responsibilities throughout their employment.

Token-based Authentication

Token-based authentication involves the exchange of tokens between entities. Tokens contain information about the user and their permissions.

Example: In OAuth-based authentication, a token is issued after the user grants permission to a third-party application, enabling the application to access specific resources on behalf of the user.

Self-Service Portals

Many IAM systems offer self-service portals, enabling users to manage their own credentials, reset passwords, or request access permissions without administrative intervention.

Example: A user forgets their password and uses a self-service portal to reset it, enhancing user autonomy and reducing helpdesk requests.

Conclusion

IAM is a foundational element of cybersecurity, ensuring that organizations can manage and secure access to their systems, applications, and data. By understanding the basic terminology and technical principles of IAM, organizations can implement robust identity and access management practices to protect their digital assets and ensure a secure and efficient computing environment.

Author’s Note:

Please note that the opinions and insights expressed in this article are solely my own and do not reflect the views or positions of my employer. This article is a product of my personal expertise and experience in the field of technology and is intended for informational and educational purposes.