Identity and Access Management

Introduction

Identity and Access Management (IAM) is the discipline of establishing who or what is requesting access, determining what that subject is permitted to do, and recording whether the access was appropriate. In cloud computing, IAM is a foundational security control because cloud resources are accessed through programmable interfaces, distributed networks, temporary workloads, and external identity providers rather than only through a local corporate network.

A cloud IAM design must protect human users, administrators, applications, services, containers, virtual machines, devices, and automated pipelines. It must also support legitimate business activity without creating excessive friction. The central security principle is:

A subject should receive only the permissions required for an approved purpose, for the shortest practical period, under conditions that can be verified and audited.

IAM therefore combines authentication, authorization, federation, accountability, lifecycle management, and governance. Weakness in any one of these areas can produce serious consequences. For example, strong passwords do not compensate for excessive administrative permissions, and a well-designed role model does not compensate for credentials that are never revoked.

Learning Objectives

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

1. Distinguish identification, authentication, authorization, accounting, and auditing.
2. Explain identity federation and single sign-on in cloud environments.
3. Select appropriate multi-factor authentication methods and understand their limitations.
4. Apply role-based and attribute-based access control.
5. Design basic privileged access management controls.
6. Distinguish human identities from workload identities and manage both safely.
7. Explain secrets-management practices and common credential failures.
8. Apply identity lifecycle controls from onboarding through deprovisioning.
9. Analyze an IAM architecture and recommend improvements using least privilege, separation of duties, and zero-trust principles.

1. The IAM Security Model

IAM is often described using four related activities:

• Identification: A subject claims an identity, such as a username, email address, service name, or certificate subject.
• Authentication: The system verifies the claim.
• Authorization: The system decides whether the authenticated subject may perform a particular action on a particular resource.
• Accounting and auditing: The system records actions, decisions, and relevant context for accountability and investigation.

A useful abstraction is:

The decision is not based only on identity. Context may include device status, network location, time, risk signals, data classification, and the assurance level of authentication. Authentication answers “Who are you?” Authorization answers “What may you do here?”

Authentication factors

Authentication factors are commonly grouped as follows:

A password plus a second password is still generally one factor, because both are knowledge factors. Multi-factor authentication (MFA) requires independent factors or an authenticator mechanism that provides equivalent resistance to common attacks.

Least privilege and separation of duties

Least privilege grants only the permissions necessary for an approved task. Separation of duties divides sensitive responsibilities so that one person or process cannot complete a high-risk operation without an independent control. For example, a developer may deploy code to a test environment, while production deployment requires approval from an operations or security role.

These principles reduce the impact of compromised accounts and insider misuse. They are not identical to “deny everything.” A practical implementation begins with a defined business task, maps that task to required actions, and removes permissions that are not justified.

2. Identity Federation and Single Sign-On

Cloud services frequently rely on an external identity provider (IdP), such as an enterprise directory or a specialist authentication service. Identity federation allows one organization to trust authentication assertions issued by another system. The cloud service is the service provider or relying party; the IdP authenticates the user and communicates an assertion or token.

Federation reduces the need to create independent passwords in every cloud service. It can centralize MFA, account disablement, authentication policy, and audit collection. Common federation technologies include SAML-based web federation and OpenID Connect (OIDC), which is an identity layer built on OAuth 2.0. OAuth 2.0 primarily concerns delegated authorization; OIDC adds standardized authentication and identity claims.

A simplified federated sign-in sequence is:

1. A user requests a protected cloud application.
2. The application redirects the user to the IdP.
3. The IdP authenticates the user and applies relevant policy, such as MFA.
4. The IdP returns a signed assertion or token.
5. The application validates issuer, audience, signature, time validity, and required claims.
6. The application creates a session and maps claims to local permissions.

The security of federation depends on correct trust configuration. An application must validate the token issuer and intended audience, reject expired or replayed tokens where applicable, protect signing keys, and avoid accepting arbitrary claims as administrative instructions. A federation outage may affect many services, so organizations should define recovery procedures and carefully controlled emergency access.

Single sign-on

Single sign-on (SSO) allows a user to authenticate once and access multiple authorized applications without repeatedly entering credentials. SSO improves usability and can reduce password reuse, but it also concentrates risk. If an attacker compromises the central identity, many connected services may be exposed. Consequently, SSO should be combined with strong MFA, adaptive policies, session controls, monitoring, and rapid account suspension.

3. Multi-Factor Authentication

MFA substantially reduces the risk associated with stolen passwords, but its effectiveness depends on the factor and attack resistance. Hardware security keys using phishing-resistant protocols are generally stronger than one-time codes sent by text message. Push notifications can be abused through repeated approval requests, often called “push fatigue.” Number matching, device binding, transaction details, and user training can reduce this risk.

Important MFA practices include:

• Require phishing-resistant MFA for administrators and other high-risk roles.
• Protect account recovery as carefully as normal sign-in.
• Register more than one approved authenticator where appropriate, while controlling enrollment.
• Monitor unusual enrollment, factor replacement, and repeated failed challenges.
• Avoid treating SMS as equivalent to a hardware security key for high-risk access.
• Use step-up authentication for sensitive actions such as changing payment details or disabling logging.

MFA does not eliminate session theft, malicious insiders, vulnerable endpoints, or authorization errors. It protects an authentication event; it does not automatically make every subsequent action safe.

4. Authorization Models

Role-based access control

Role-Based Access Control (RBAC) assigns permissions to roles, and users or workloads receive roles. A role represents a job function or operational responsibility, such as “read-only auditor,” “database operator,” or “application deployment service.” RBAC supports manageable administration and separation of duties.

A simplified relationship is:

Good roles are task-oriented and understandable. Poor roles accumulate unrelated permissions until they become “super roles.” Role design should distinguish read, write, delete, administrative, and policy-management actions. Where possible, production and non-production roles should be separate.

Attribute-based access control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, resource, action, and environment. An example policy may permit a user with department = finance to read resources labelled classification = internal during an approved business period, provided the device is managed.

ABAC can express context-sensitive decisions and reduce the number of manually created roles. However, it is harder to test and explain when many attributes interact. Attributes must be trustworthy, current, consistently named, and protected from unauthorized modification.

RBAC and ABAC are complementary. An organization may use roles for broad job functions and attributes for resource ownership, environment, data classification, or geographic restrictions. Both models should be governed by explicit policies rather than informal administrator knowledge.

Policy evaluation

A policy decision normally considers explicit allows, explicit denies, inherited permissions, resource policies, conditions, and organizational guardrails. The exact evaluation order differs between platforms, so administrators must consult the provider’s documented semantics. A safe operational assumption is that an explicit deny should override an allow where the platform defines such precedence, but this must be verified rather than assumed.

Access policies should be reviewed with questions such as:

• Is the permission needed for a documented task?
• Is the resource scope as narrow as practical?
• Can a temporary permission replace a permanent one?
• Can the action modify identity, logging, encryption, or network controls?
• Is the permission inherited through a group, role, or organization hierarchy?

5. Privileged Access Management

Privileged Access Management (PAM) protects identities that can alter systems, access sensitive data, create credentials, or change security controls. Privileged accounts should not be used for routine email, browsing, or general work.

A practical PAM program includes:

1. Separate standard and administrative identities.
2. Strong MFA and phishing-resistant authenticators.
3. Just-in-time or time-limited elevation.
4. Approval for high-risk activities.
5. Session logging or command recording where lawful and proportionate.
6. Credential vaulting, rotation, and controlled checkout.
7. Emergency or “break-glass” accounts with strict monitoring.
8. Regular review of standing privileges and administrator membership.

Break-glass access is necessary for some outages, but it must not become an unmonitored bypass. Emergency credentials should be stored securely, tested periodically, protected by independent controls, and investigated after use.

6. Workload Identities

A workload identity represents software rather than a person. Examples include a virtual machine, container, serverless function, CI/CD pipeline, or managed application. Workloads need identities to call storage, databases, queues, and APIs.

The safest general approach is to issue a workload a short-lived, audience-restricted credential through the cloud platform’s identity mechanism. Avoid embedding long-lived access keys in source code, container images, configuration files, or build logs. Where a workload runs outside the cloud provider, federation from its platform identity to the cloud can avoid permanent static keys.

Workload identity design should address:

• Unique identity per application or service function.
• Separate identities for development, testing, and production.
• Narrow permissions and resource scopes.
• Short credential lifetime and automatic rotation.
• Clear ownership and inventory.
• Monitoring of unusual call patterns.
• Protection against impersonation through compromised build systems or metadata services.

A workload identity is not automatically trustworthy merely because it is machine-generated. A compromised application may use all permissions assigned to its identity; least privilege and runtime isolation therefore remain essential.

7. Secrets Management

A secret is sensitive information used to authenticate or authorize, including passwords, API keys, private keys, database credentials, tokens, and encryption-related material. Secrets management covers generation, storage, distribution, use, rotation, revocation, and destruction.

Secrets should be stored in a dedicated secrets manager or protected platform service, not in source repositories or ordinary environment files. Access should be granted to the workload identity rather than copied among developers. Secrets should be encrypted in transit and at rest, with access logged and monitored. Rotation must be operationally tested; a theoretical rotation schedule is ineffective if applications cannot reload credentials safely.

Common failures include:

• Committing credentials to version control.
• Reusing one key across many applications.
• Logging authorization headers or connection strings.
• Using production secrets in development.
• Failing to revoke credentials after personnel or vendor changes.
• Treating encryption keys and application secrets as interchangeable.

If a secret is exposed, the response should include containment, revocation, replacement, investigation of use, log preservation, and assessment of affected systems. Removing a secret from the latest source file does not remove it from historical commits, backups, logs, or forks.

8. Identity Lifecycle Controls

Identity security is a lifecycle, not a one-time provisioning task. The principal stages are:

The joiner–mover–leaver model is especially important in federated cloud environments. Disabling a local directory account may not immediately invalidate an existing cloud session or token. Organizations should understand session lifetime, token revocation, cached credentials, service accounts, and external collaborators.

Access certification should be meaningful rather than a routine approval exercise. Reviewers need understandable entitlement descriptions, resource ownership, last-use information, and a clear method for removing access. Dormant identities, orphaned service accounts, unused keys, and unmanaged external users are high-value review targets.

9. Applied Case: Regional Health Analytics Service

The following is an illustrative case.

Background

A regional health organization operates a cloud analytics platform. Analysts, clinicians, developers, contractors, and automated data pipelines access different environments. The platform processes identifiable health information, so confidentiality, traceability, and controlled sharing are essential.

Problem

An internal review finds shared administrator credentials, permanent API keys in a deployment repository, excessive analyst access to production data, and delayed removal of contractor accounts. The organization also uses separate passwords for several cloud applications.

Analysis

The findings indicate failures in identity ownership, lifecycle control, privileged access, workload identity, and authorization design. The principal risks are credential theft, untraceable actions, unauthorized data access, and persistence after a person leaves.

Approach and solution

The organization establishes a central IdP with SSO and phishing-resistant MFA for privileged users. Analysts authenticate through federated identities and receive a read-only role limited by environment and data classification. ABAC conditions require a managed device and restrict access to approved data domains.

Administrative access is separated from ordinary accounts and granted through PAM for approved tasks. Elevation expires automatically. The deployment pipeline receives a workload identity through federation rather than a stored long-lived key. Database passwords are moved to a secrets manager, with automated rotation and access logging.

The human-resources system triggers a deprovisioning workflow. The workflow disables the identity, revokes sessions where supported, removes group membership, reviews owned resources, and alerts application owners about remaining service dependencies. Quarterly access reviews examine privileged roles, external users, dormant accounts, and exceptions.

Outcome

The organization gains centralized authentication, stronger administrator protection, better attribution of actions, and reduced exposure from static credentials. It also discovers that some legacy applications cannot support modern federation and therefore places them behind a controlled access gateway while developing a replacement plan.

Learning points

IAM improvement is architectural and organizational. Technology alone cannot solve unclear ownership, poor approval processes, or untested recovery procedures. Federation, MFA, PAM, workload identity, secrets management, and lifecycle automation must operate as a connected control system.

10. Governance, Ethics, and Contemporary Practice

IAM systems process personal and employment information, including login history, device attributes, location signals, and behavioral indicators. Monitoring must have a legitimate purpose, appropriate transparency, access restrictions, retention limits, and lawful processing. Biometric authentication requires particular care because biometric characteristics cannot be replaced like passwords.

Organizations should align IAM with applicable privacy, sector, contractual, and cybersecurity requirements. They should maintain policy ownership, evidence of access reviews, incident procedures, and documented exceptions. Automated risk scoring and artificial intelligence may help identify anomalous sign-ins or unusual privilege use, but such systems can produce false positives, discriminate through biased data, or be manipulated by attackers. AI-generated recommendations should support, not replace, accountable human decisions for high-impact access changes.

Contemporary IAM is moving toward passwordless authentication, phishing-resistant credentials, continuous or adaptive authorization, zero-trust architectures, decentralized workload identity, and policy-as-code. These developments improve security when implemented carefully, but complexity can create new failure modes. Every new control should be tested for usability, recovery, interoperability, logging, and administrative abuse.

Best-Practice Checklist

• Maintain a complete inventory of human, external, device, and workload identities.
• Centralize authentication where practical through a trusted IdP.
• Require strong MFA, especially for privileged access.
• Apply least privilege, separation of duties, and explicit ownership.
• Prefer temporary, scoped credentials over permanent keys.
• Use federation or platform identity for workloads.
• Store secrets in a managed service and rotate them safely.
• Automate joiner, mover, and leaver processes.
• Review dormant, excessive, orphaned, and externally shared access.
• Log authentication, authorization, privilege elevation, and administrative changes.
• Test emergency access and account-recovery procedures.
• Treat IAM configuration as security-sensitive code subject to review and change control.

Chapter Summary

IAM controls access by connecting identity, authentication, authorization, accountability, and lifecycle governance. Federation and SSO centralize authentication across cloud services, while MFA reduces the effect of stolen passwords. RBAC assigns permissions through job-oriented roles; ABAC evaluates subject, resource, action, and environmental attributes. PAM protects high-impact administrative identities through separation, approval, time-limited elevation, and monitoring. Workload identities allow applications and automated services to authenticate without embedding permanent keys. Secrets management protects credentials throughout their lifecycle. Joiner–mover–leaver processes, access certification, session control, and prompt deprovisioning prevent obsolete access from becoming a persistent risk. Effective IAM is therefore a combination of technology, policy, organizational accountability, and continuous review.

Key Terms

Identity: A representation of a person, device, application, or other subject.

Authentication: Verification of a claimed identity.

Authorization: A decision about whether an authenticated subject may perform an action.

Federation: A trust arrangement in which one identity system provides authentication information to another service.

Identity provider: A system that authenticates subjects and issues assertions or tokens.

Single sign-on: Access to multiple authorized services after one authentication event.

Multi-factor authentication: Authentication using independent factors or strong multi-factor mechanisms.

Least privilege: Granting only the access required for an approved task.

RBAC: Authorization based on roles associated with job functions.

ABAC: Authorization based on attributes of subjects, resources, actions, and context.

Privileged access management: Controls for identities with powerful administrative permissions.

Workload identity: An identity assigned to software or an automated service.

Secret: Sensitive authentication or authorization material.

Secrets manager: A controlled service for storing, distributing, rotating, and auditing secrets.

Identity lifecycle: The sequence of provisioning, changing, reviewing, and removing access.

Joiner–mover–leaver: Lifecycle model for personnel who enter, change roles, or leave an organization.

Break-glass account: Emergency access account used when normal administrative paths are unavailable.

Step-up authentication: Stronger authentication required for a sensitive action or elevated risk.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is the purpose of identity federation?
3. Why is a password plus a second password not normally considered MFA?
4. State two advantages of workload identities over long-lived access keys.
5. What activities should occur when an employee leaves an organization?

Long Answer Questions

1. Explain how SSO, MFA, and federation can be combined in a secure cloud architecture.
2. Compare RBAC and ABAC, including an example where each is most useful.
3. Describe a PAM design for cloud administrators and explain how it supports least privilege.
4. Explain the complete lifecycle of a cloud secret from creation to revocation.
5. Discuss why IAM must be treated as both a technical and organizational control system.

Analytical / Application Questions

1. A developer has permanent production administrator access and stores a deployment key in a public repository. Analyze the risks and propose a prioritized remediation plan.
2. Design an access model for a cloud application containing development, testing, and production environments. Include human roles, workload identities, MFA, and lifecycle controls.
3. A contractor’s directory account is disabled, but the contractor can still access a cloud dashboard using an existing session. Explain possible causes and recommend preventive and corrective controls.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication grants permissions, while authorization verifies identity.

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

C. Authentication records activity, while authorization encrypts data.

D. Authentication creates roles, while authorization issues passwords.

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

Question 2

Which authentication method is generally most resistant to phishing?

A. A password reused across services

B. An SMS one-time code

C. A hardware security key using a phishing-resistant protocol

D. A security question

Correct Answer: C. A hardware security key using a phishing-resistant protocol

Question 3

What is the main purpose of identity federation?

A. To eliminate the need for authorization policies

B. To allow one trusted identity system to provide authentication to another service

C. To store all application data in one database

D. To replace audit logging

Correct Answer: B. To allow one trusted identity system to provide authentication to another service

Question 4

Which example best represents ABAC?

A. Every analyst receives the same fixed role

B. A user may read data when department, device status, and data-classification conditions are satisfied

C. All administrators share one account

D. A password is changed every year

Correct Answer: B. A user may read data when department, device status, and data-classification conditions are satisfied

Question 5

Which control is most characteristic of privileged access management?

A. Permanent administrator access for all developers

B. Time-limited elevation with approval and monitoring

C. Disabling all audit logs

D. Using one API key for every workload

Correct Answer: B. Time-limited elevation with approval and monitoring

Question 6

Which practice is safest for a cloud workload?

A. Embedding a permanent access key in source code

B. Sharing a human administrator’s password with the application

C. Using a short-lived workload identity with narrowly scoped permissions

D. Printing credentials in deployment documentation

Correct Answer: C. Using a short-lived workload identity with narrowly scoped permissions

Question 7

What is the primary purpose of a secrets manager?

A. To publish credentials publicly for convenience

B. To store, distribute, rotate, and audit sensitive credentials

C. To replace network segmentation

D. To make all users administrators

Correct Answer: B. To store, distribute, rotate, and audit sensitive credentials

Question 8

In the joiner–mover–leaver model, what is a key requirement when a person changes departments?

A. Keep all previous permissions permanently

B. Remove incompatible old access and assign only approved new access

C. Disable MFA temporarily

D. Create a shared account

Correct Answer: B. Remove incompatible old access and assign only approved new access

Question 9

Which principle is illustrated by requiring one employee to request a production change and another to approve it?

A. Single sign-on

B. Separation of duties

C. Credential reuse

D. Data duplication

Correct Answer: B. Separation of duties

Question 10

Why can SSO increase the impact of a compromised identity provider account?

A. It prevents all auditing

B. It may provide access to multiple connected services

C. It disables authorization policies

D. It makes MFA impossible

Correct Answer: B. It may provide access to multiple connected services