Identity and Access Management

Introduction and Context

Identity and Access Management (IAM) is the discipline of determining who or what may access a resource, under which conditions, and for how long. In cloud computing, IAM is a foundational security control because cloud resources are accessed through APIs, web consoles, automation pipelines, applications, and distributed services rather than only through a physically controlled corporate network.

A cloud IAM system generally performs four related functions:

1. Identification — claiming an identity, such as a user, service, device, or workload.
2. Authentication — proving control of that identity.
3. Authorization — determining what the authenticated identity may do.
4. Accountability — recording actions so that they can be reviewed and attributed.

IAM is not equivalent to merely creating user accounts. Effective IAM combines identity lifecycle management, authentication technologies, authorization models, federation, privileged access controls, governance, monitoring, and periodic review.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish identification, authentication, authorization, and accounting;
• explain roles, policies, groups, claims, and permissions;
• apply least privilege and zero-standing-privilege principles;
• compare password, multifactor, federated, and passwordless authentication;
• describe single sign-on and identity federation;
• configure appropriate identities for users, applications, and cloud services;
• design basic privileged-access controls and access reviews;
• recognize ethical, legal, operational, and security risks in IAM.

1. The IAM Security Model

1.1 Authentication and authorization

Authentication answers the question: Who are you? Authorization answers: What are you allowed to do? A successful login does not imply unrestricted access. For example, an authenticated analyst may be allowed to read a reporting database but not modify production records.

A useful authorization abstraction is:

Here, Subject is the user, service, or workload requesting access; Action is the operation, such as read or delete; Resource is the object being accessed; and Context includes attributes such as time, device status, network location, and authentication strength. The expression is conceptual rather than a universal implementation formula. A request should be permitted only when the applicable policy conditions are satisfied.

1.2 The access-control decision

A cloud authorization service typically evaluates:

• the identity making the request;
• the requested operation;
• the target resource;
• applicable allow rules;
• explicit deny rules;
• resource ownership and scope;
• environmental conditions;
• organizational policies and regulatory restrictions.

Many systems follow a deny-by-default approach: if no applicable permission explicitly allows an action, the action is denied. In systems where explicit denial overrides permission, a simplified decision rule is:

This rule assumes that the platform uses explicit-deny precedence. Administrators must consult the specific cloud provider’s policy-evaluation model because policy inheritance and precedence differ between platforms.

1.3 Identity lifecycle

IAM begins before an account is created and continues after access is revoked. A typical lifecycle is:

1. Joiner — create an identity and assign initial access.
2. Mover — modify access when the person changes role, department, project, or location.
3. Leaver — disable credentials, revoke sessions, transfer ownership, and preserve required records.
4. Reviewer — periodically confirm that access remains appropriate.

Poor lifecycle management creates orphaned accounts, excessive permissions, conflicting duties, and unowned resources.

2. Core IAM Concepts

2.1 Identities and principals

A principal is an entity that can make an access request. Common principals include:

• human users;
• groups and organizational units;
• applications;
• virtual machines and containers;
• serverless functions;
• devices;
• external identities from partner organizations.

A human identity should normally represent a single person. Shared human accounts reduce accountability and make access reviews unreliable. Exceptions should be formally approved, tightly monitored, and replaced where possible with named identities or managed service identities.

2.2 Permissions, policies, and roles

A permission is an allowed operation on a resource. A policy is a collection of rules that grants or denies permissions. A role is an assignable set of permissions, usually designed around a job function or workload requirement.

Role-based access control (RBAC) assigns access according to organizational roles such as database reader, help-desk operator, or cloud auditor. RBAC is easier to administer than individual permission assignment, but poorly designed roles can become excessively broad.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and context. For example, a policy may permit a user to access records only when the user’s department matches the record’s department and the request originates from a managed device.

Modern cloud systems commonly combine RBAC, ABAC, resource policies, organization policies, and contextual conditions.

2.3 Scope and inheritance

Permissions may apply at different scopes:

• organization or tenant;
• management group or folder;
• account or subscription;
• project;
• resource group;
• individual resource.

Broad-scope permissions are convenient but risky. A role assigned at organization level may affect thousands of resources. The preferred practice is to assign access at the narrowest scope that satisfies the business requirement.

2.4 Separation of duties

Separation of duties (SoD) prevents one person from controlling an entire sensitive process. For example, the person who develops a production change should not be the only person who approves and deploys it. SoD reduces fraud, error, and abuse, but it must be designed realistically for small teams. Where staffing prevents complete separation, compensating controls such as independent review and detailed logging are necessary.

3. Least Privilege and Zero Standing Privilege

3.1 Least privilege

Least privilege means providing only the permissions, scope, and duration necessary for an approved task. It has three dimensions:

• minimal actions — for example, read rather than read-and-delete;
• minimal scope — one database or project rather than the entire organization;
• minimal duration — access for the task period rather than indefinitely.

Least privilege is a risk-reduction principle, not an absolute guarantee of safety. A narrowly privileged account can still be compromised, and an attacker may exploit an allowed action. Therefore, least privilege must be combined with strong authentication, monitoring, segmentation, secure software, and recovery controls.

3.2 Zero standing privilege

Zero standing privilege (ZSP), also called just-in-time or on-demand access, aims to ensure that elevated permissions are not continuously assigned. A user requests temporary access, provides an approved reason, satisfies additional authentication or approval requirements, performs the task, and loses the privilege automatically when the time limit expires.

A typical workflow is:

1. The user requests a named role and duration.
2. The system checks eligibility and separation-of-duties rules.
3. An approver or automated policy authorizes the request.
4. Strong authentication is required.
5. The role is activated temporarily.
6. Commands and sessions are logged.
7. The role expires automatically.
8. The activity is reviewed.

ZSP reduces the opportunity for credential theft and accidental misuse. It can, however, create operational delays during incidents, so emergency access (“break glass”) must be controlled, logged, time-limited, and reviewed afterward.

3.3 Permission analysis

Access reviews should examine actual usage as well as assigned permissions. A useful classification is:

• required — demonstrably needed for current duties;
• unused — assigned but not used during the review period;
• excessive — broader than the task requires;
• conflicting — violates separation-of-duties rules;
• unowned — associated with no accountable person or team.

Usage data should not be interpreted mechanically. An unused permission may be needed for an infrequent but legitimate task. A review should therefore combine logs, business ownership, job responsibilities, and risk assessment.

4. Authentication Methods

4.1 Authentication factors

Authentication factors are usually grouped as:

• something you know — password or PIN;
• something you have — hardware security key, authenticator device, or registered phone;
• something you are — biometric characteristic;
• somewhere you are — location or network context;
• something you do — behavioral characteristics.

Multifactor authentication (MFA) requires evidence from at least two distinct factor categories. Two passwords are two knowledge items, not genuine multifactor authentication.

4.2 Passwords and passkeys

Passwords remain common but are vulnerable to phishing, reuse, credential stuffing, guessing, malware, and database compromise. Good practice includes unique passwords, password managers, secure hashing by the service provider, breached-password screening, and rate limiting. Forced frequent password changes can be counterproductive when they encourage predictable variations; changes should be required when compromise is suspected or when risk warrants it.

Passkeys use public-key cryptography. The private key remains protected by the user’s device or authenticator, while the service stores a corresponding public key. Authentication proves possession of the private key without transmitting a reusable password. Passkeys can significantly reduce phishing risk when implemented with appropriate device and recovery controls.

4.3 MFA selection

MFA methods differ in resistance to phishing and interception. Hardware security keys and carefully implemented passkeys generally provide stronger phishing resistance than SMS codes. SMS may be useful as a transitional or recovery mechanism but is exposed to risks such as SIM swapping and message interception.

MFA should be required at minimum for administrators, remote access, sensitive data, financial operations, and identity-management changes. Adaptive authentication can request stronger verification when risk signals change, such as a new device, unusual location, impossible travel pattern, or high-impact action.

5. Federation and Single Sign-On

5.1 Federation

Identity federation allows one organization’s identity provider (IdP) to authenticate a user for another organization or service provider (SP). The IdP issues a signed assertion or token containing claims such as subject identifier, group membership, and authentication time. The SP validates the token and creates an application session.

Federation reduces duplicate accounts and centralizes authentication policy. It also creates dependency on the IdP, token validation, key management, clock synchronization, and correct claim mapping.

Common federation technologies include:

• SAML — widely used for browser-based enterprise SSO;
• OpenID Connect (OIDC) — an identity layer built on OAuth 2.0, commonly used by modern web and mobile applications;
• OAuth 2.0 — primarily an authorization framework for delegated access, not by itself an authentication protocol.

Confusing OAuth with authentication can produce insecure designs. OIDC adds identity claims and authentication semantics to OAuth flows.

5.2 Single sign-on

Single sign-on (SSO) allows a user to authenticate once and access multiple approved services without entering separate passwords for each service. SSO improves usability, reduces password reuse, and simplifies centralized offboarding. Its main risk is concentration: compromise of the IdP account can expose many applications. Strong MFA, conditional access, token protection, rapid revocation, and resilient recovery are therefore essential.

Federation and SSO are related but not identical. Federation is the trust relationship and exchange of identity information; SSO is the user experience of accessing multiple services through one authentication event.

6. Service Identities and Workload Access

Human credentials should not be embedded in application code, scripts, container images, or configuration files. Cloud workloads should use managed identities, workload identities, or short-lived credentials issued by a trusted identity service.

A secure service identity design should:

• give each application or workload a distinct identity;
• grant only required API actions;
• restrict the identity to appropriate resources;
• use short-lived tokens where possible;
• store unavoidable secrets in a managed secrets service;
• rotate keys and certificates automatically;
• prevent developers from using production identities for testing;
• log service-to-service requests.

A service account with broad permanent permissions is a high-value target. Identity isolation also improves incident response because investigators can attribute actions to a specific workload rather than to a shared credential.

7. Privileged Access Management

Privileged Access Management (PAM) protects identities that can alter security settings, access sensitive data, create credentials, or control infrastructure. Privileged accounts should be separated from ordinary user accounts. An administrator may use a standard account for email and a separate privileged account for approved administrative tasks.

Core PAM capabilities include:

• approval-based elevation;
• just-in-time access;
• session recording or command logging;
• credential vaulting;
• automatic password or key rotation;
• administrator activity alerts;
• emergency access procedures;
• independent review of privileged actions.

Root or global-administrator access should be rare. It should be protected by strong MFA, hardware-backed authentication where available, carefully controlled recovery methods, and monitoring for changes to identity policies themselves.

8. Access Reviews and Governance

An access review is a documented decision about whether a permission remains justified. A mature review process includes:

1. Inventory — identify users, groups, roles, service identities, privileged accounts, and external trust relationships.
2. Ownership — assign a business owner and technical owner to each access package and resource.
3. Evidence — provide role descriptions, recent usage, approvals, and risk information.
4. Decision — approve, modify, suspend, or revoke access.
5. Remediation — remove unnecessary permissions and resolve conflicts.
6. Attestation — record who made the decision and when.
7. Follow-up — verify that changes were implemented.

Review frequency should be risk-based. Privileged access, external accounts, and access to regulated data may require monthly or quarterly review, while lower-risk access may be reviewed less frequently. A review that merely asks a manager to click “approve all” is not effective governance.

Useful IAM measures include:

• percentage of privileged identities using MFA;
• number of standing privileged accounts;
• time taken to revoke leaver access;
• percentage of access packages with named owners;
• number of excessive or unused permissions removed;
• frequency of emergency-access use;
• number of failed or anomalous authentication events.

Metrics should support decisions rather than become targets that encourage misleading behavior.

9. Applied Case: Northbridge Health Analytics

Background

Northbridge Health Analytics is an illustrative cloud-based organization that processes hospital appointment and claims data. Analysts, software engineers, support staff, and an external reporting partner access cloud resources. The organization uses several independent application accounts and has accumulated numerous long-lived service keys.

Problem

An audit identifies three weaknesses: former contractors still have active accounts, engineers use permanent administrator roles for troubleshooting, and a reporting application stores a long-lived cloud key in its deployment configuration. The organization also lacks a reliable record of who approved access.

Analysis

The weaknesses arise from incomplete identity lifecycle management, excessive standing privilege, poor workload identity design, and weak governance. The risk is not limited to malicious insiders. A stolen contractor password or leaked application key could allow unauthorized access to health information.

Approach and solution

Northbridge adopts the following design:

• a central IdP with SSO for workforce applications;
• phishing-resistant MFA for administrators and access to sensitive data;
• automated joiner-mover-leaver integration with the human-resources system;
• named RBAC roles with resource-level scope;
• separate standard and privileged administrator accounts;
• just-in-time elevation for production administration;
• managed workload identity for the reporting application;
• a secrets manager for credentials that cannot yet be eliminated;
• quarterly review of sensitive access and monthly review of privileged access;
• immutable audit logs and alerts for policy, role, and key changes;
• a controlled emergency role that expires automatically and requires retrospective review.

Outcome

The organization removes dormant contractor accounts, eliminates the embedded application key, reduces permanent administrator assignments, and gains evidence of access approvals. Troubleshooting becomes slightly more formal, but administrative actions are more attributable and less exposed to credential theft.

Learning points

The case illustrates that IAM is an operating model, not a single product. Strong MFA without lifecycle automation leaves orphaned access. Role design without periodic review leaves excessive permissions. PAM without logging weakens accountability. Effective protection requires these controls to work together.

10. Challenges, Ethics, and Contemporary Developments

IAM creates practical tensions. Strict controls can delay legitimate work, while convenience can increase exposure. Accessibility must be considered: authentication methods should support users with disabilities and provide secure recovery without creating weak bypasses.

Organizations should collect only the identity and behavioral data necessary for security and administration. Biometric information deserves particular care because it cannot be changed like a password if compromised. Monitoring must be proportionate, transparent, legally justified, and protected from misuse.

Regulatory requirements vary by jurisdiction and sector, but common expectations include least privilege, access logging, prompt deprovisioning, separation of duties, protection of personal data, and evidence of review. IAM controls should be mapped to applicable organizational policies and laws rather than treated as a substitute for legal advice.

Contemporary developments include passwordless authentication, continuous risk-based authorization, confidential computing for sensitive workloads, workload identity federation, and policy-as-code. Artificial intelligence can assist with anomaly detection and permission recommendations, but automated recommendations require human review. An AI system may infer that an unusual access event is suspicious without understanding a legitimate emergency or business process. High-impact access decisions should remain explainable, auditable, and subject to appeal or human approval.

Best-Practice Checklist

• Use unique named identities for people.
• Deny access by default where the platform supports that model.
• Prefer roles and groups over scattered individual permissions.
• Assign permissions at the narrowest practical scope.
• Require MFA for privileged and sensitive access.
• Prefer phishing-resistant authentication for high-risk accounts.
• Separate ordinary and privileged accounts.
• Replace permanent privilege with time-limited elevation.
• Use managed identities for cloud workloads.
• Never place secrets in source code or images.
• Automate joiner, mover, and leaver processes.
• Record owners, approvals, and expiration dates.
• Review sensitive access periodically and investigate exceptions.
• Monitor identity-policy changes and emergency access.
• Test recovery, revocation, and break-glass procedures.

Chapter Summary

Identity and Access Management establishes how cloud identities are created, authenticated, authorized, monitored, and retired. Authentication proves identity; authorization determines permitted actions; accountability records activity. RBAC provides manageable job-based access, while ABAC and policy conditions support context-sensitive decisions. Least privilege limits actions, scope, and duration, and zero standing privilege removes persistent elevation through just-in-time access. Federation and SSO centralize authentication, but require strong IdP protection. MFA, particularly phishing-resistant methods, reduces account-compromise risk. Service identities should be distinct, short-lived, and minimally privileged. PAM protects administrative operations through separation, approval, logging, and automatic expiry. Finally, access reviews, lifecycle automation, ethical safeguards, and governance convert IAM technology into a sustainable security program.

Key Terms

• Authentication: Verification of an identity claim.
• Authorization: Determination of whether an identity may perform an action.
• Principal: Entity capable of making an access request.
• Identity provider (IdP): Service that authenticates identities and issues identity information.
• Service provider (SP): Application or service that accepts federated identity assertions.
• Permission: Allowed operation on a resource.
• Policy: Rule or collection of rules governing access.
• Role: Named set of permissions assigned to a user or workload.
• RBAC: Access control based primarily on organizational roles.
• ABAC: Access control based on subject, resource, action, and contextual attributes.
• Least privilege: Granting only the access necessary for an approved task.
• Zero standing privilege: Removal of persistent elevated access through temporary activation.
• Multifactor authentication: Authentication using evidence from at least two factor categories.
• Single sign-on: Access to multiple services after one authentication event.
• Federation: Trust relationship allowing one identity domain to authenticate users for another service.
• Privileged Access Management: Controls for high-impact administrative identities.
• Separation of duties: Division of sensitive responsibilities among different people or roles.
• Managed identity: Provider-controlled identity for a cloud workload or service.
• Access review: Periodic assessment of whether permissions remain justified.
• Break-glass access: Emergency access used under exceptional, monitored conditions.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What are the three dimensions of least privilege?
3. Why should applications use managed workload identities rather than embedded keys?
4. Define identity federation and single sign-on.
5. Why is a shared human administrator account undesirable?

Long Answer Questions

1. Explain how RBAC and ABAC differ, and describe a situation in which they could be combined.
2. Describe a complete joiner-mover-leaver identity lifecycle and the risks of failing at each stage.
3. Explain how zero standing privilege changes the administration of production systems.
4. Discuss the security advantages and concentration risks of centralized SSO.
5. Design an access-review process for an organization handling sensitive personal data.

Analytical / Application Questions

1. A developer has permanent permission to delete production storage but uses it only during rare migrations. Analyze the risks and propose a least-privilege, zero-standing-privilege design.
2. An organization requires SMS MFA for all administrators but permits password resets through an email account that has no MFA. Identify the weaknesses and recommend a stronger recovery architecture.
3. A reporting service uses one cloud key shared by development, testing, and production. Propose an identity and accountability model that separates environments and supports incident investigation.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do, while authorization verifies identity.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication records activity, while authorization encrypts data.

D. Authentication creates backups, while authorization deletes accounts.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

Which practice most directly implements zero standing privilege?

A. Assigning every engineer a permanent administrator role

B. Sharing one emergency administrator password

C. Granting approved administrator access temporarily and expiring it automatically

D. Allowing access from any device after one initial login

Correct Answer: C. Granting approved administrator access temporarily and expiring it automatically

Question 3

Which authentication method generally provides the strongest phishing resistance?

A. A reused password

B. An SMS code alone

C. A hardware security key using public-key authentication

D. A security question

Correct Answer: C. A hardware security key using public-key authentication

Question 4

What is the primary purpose of a managed workload identity?

A. To replace all human access reviews

B. To provide an application with controlled identity without embedding long-lived credentials

C. To allow every application to use the same administrator account

D. To disable logging for service requests

Correct Answer: B. To provide an application with controlled identity without embedding long-lived credentials

Question 5

Which statement about OAuth 2.0 is most accurate?

A. It is primarily an authorization framework for delegated access.

B. It is a password-hashing algorithm.

C. It always provides multifactor authentication by itself.

D. It is a database access-control language.

Correct Answer: A. It is primarily an authorization framework for delegated access.

Question 6

A permission is assigned at organization-wide scope when only one project requires it. What principle is most clearly violated?

A. Least privilege

B. Data compression

C. Fault tolerance

D. Load balancing

Correct Answer: A. Least privilege

Question 7

What is a major risk of centralized single sign-on?

A. Users must maintain more unrelated passwords.

B. Compromise of the identity provider may affect many connected services.

C. Federated applications cannot use logging.

D. It prevents all forms of multifactor authentication.

Correct Answer: B. Compromise of the identity provider may affect many connected services.

Question 8

Which control best supports separation of duties?

A. Allowing one person to develop, approve, and deploy a sensitive change

B. Using one shared account for all operators

C. Requiring independent approval before a developer’s production change is deployed

D. Removing audit logs after deployment

Correct Answer: C. Requiring independent approval before a developer’s production change is deployed

Question 9

What should an effective access review determine?

A. Whether every employee has the same permissions

B. Whether assigned access remains justified, appropriately scoped, and owned

C. Whether passwords are visually similar

D. Whether all access should be permanent

Correct Answer: B. Whether assigned access remains justified, appropriately scoped, and owned

Question 10

Why should emergency break-glass access be reviewed after use?

A. To ensure the emergency activity was justified and controlled

B. To make the emergency account permanent

C. To prevent all future emergency access

D. To replace multifactor authentication

Correct Answer: A. To ensure the emergency activity was justified and controlled