Identity and Access Management

Introduction

Identity and Access Management (IAM) is the discipline of ensuring that the right people, devices, services, and processes obtain the right access to the right resources at the right time, for the right reasons. It is a central component of cybersecurity because most modern attacks ultimately seek to misuse identity: an attacker steals a password, hijacks a session, abuses excessive privileges, creates a fraudulent account, or compromises a service identity.

IAM is broader than login technology. It includes identity proofing, account creation, authentication, authorization, access review, monitoring, incident response, and account deprovisioning. Effective IAM supports the principles of least privilege, separation of duties, zero trust, accountability, and regulatory compliance.

In a traditional perimeter-based model, an organization often trusted users who connected from an internal network. Cloud computing, remote work, mobile devices, software-as-a-service, and application programming interfaces have weakened that assumption. Contemporary security therefore increasingly follows an identity-first approach: every access request is evaluated according to the identity, device, context, resource, and requested action.

Learning Objectives

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

• distinguish identification, authentication, authorization, and accountability;
• explain passwords, password hashing, multifactor authentication, biometrics, and adaptive authentication;
• compare role-based and attribute-based access control;
• describe federation, single sign-on, and common identity protocols;
• design an identity lifecycle and privileged-access management process;
• analyze credential theft and propose identity-first security controls;
• evaluate IAM through technical, ethical, governance, and operational perspectives.

1. The IAM Security Model

IAM can be understood as a sequence of related decisions:

1. Identification: a subject claims an identity, such as a username, employee number, device identifier, or service name.
2. Authentication: the system verifies the claim.
3. Authorization: the system determines what the authenticated subject may do.
4. Accountability: the organization records actions so that they can be traced, reviewed, and investigated.

These stages must not be confused. A username identifies a claim but does not prove it. Authentication proves control of one or more authenticators, but it does not automatically grant access to every resource. Authorization establishes permissions, while accountability connects actions to an identity and a time.

A useful abstraction is:

This is a conceptual policy function rather than a universal numerical equation. The variables represent the subject identity, confidence in authentication, protected resource, requested action, contextual information, and applicable policy. Context may include device health, network location, time, risk signals, and transaction value.

Subjects, objects, and permissions

A subject is an active entity requesting access. It may be a human user, application, process, device, or service account. An object is a resource being accessed, such as a file, database record, API, virtual machine, or administrative function. A permission specifies an allowed operation, such as read, write, execute, approve, or delete.

A practical authorization statement can be represented as:

Subject: payroll analyst; object: payroll reports; action: read; condition: authenticated through approved MFA and using a managed device.

This structure helps security designers avoid vague permissions such as “trusted employee.”

2. Authentication Factors and Methods

Authentication factors are traditionally divided into three categories:

A fourth category is sometimes used: somewhere the user is, such as a trusted location. Location is generally a contextual signal rather than a strong independent factor because locations can be spoofed or shared.

Passwords and passphrases

Passwords remain widely used because they are inexpensive and easy to deploy. Their weakness is that users select, reuse, disclose, and enter them into fraudulent sites. Common attacks include brute force, password spraying, credential stuffing, phishing, malware-based keylogging, and offline cracking after a database breach.

A secure password system should:

• store passwords only as salted, slow, adaptive cryptographic hashes;
• never store or transmit plaintext passwords unnecessarily;
• block known compromised passwords;
• permit long passphrases and password-manager use;
• rate-limit online guesses and detect password spraying;
• support secure recovery and reset procedures;
• avoid arbitrary composition rules that encourage predictable patterns.

A salt is a unique random value stored with each password hash. It prevents identical passwords from producing identical stored values and makes precomputed rainbow-table attacks less effective. A password hash is not encryption: encryption is designed to be reversed with a key, whereas password hashing is designed to be computationally difficult to reverse.

Password hashing algorithms should be designed for password storage, such as Argon2id, scrypt, or bcrypt, with parameters selected according to current hardware and organizational risk. General-purpose hashes such as unsalted SHA-256 are not suitable as the sole password-storage mechanism because attackers can test guesses too quickly.

Multifactor authentication

Multifactor authentication (MFA) requires evidence from at least two different factor categories. Entering a password and answering a security question usually does not qualify because both are knowledge factors. A password combined with a hardware security key is a stronger example.

MFA substantially reduces the value of stolen passwords, but not all MFA is equally resistant to attack. SMS codes can be exposed through SIM swapping, phone-number takeover, malware, or social engineering. Push-notification systems may suffer from approval fatigue, in which an attacker repeatedly sends prompts until a user accepts one. Phishing-resistant methods, especially hardware-backed WebAuthn or FIDO2 credentials, bind authentication to the legitimate website and are generally stronger.

MFA implementation should include secure enrollment, recovery controls, device replacement procedures, backup authenticators, user education, and monitoring of unusual factor changes. Recovery is often the weakest part of an MFA system; an attacker who cannot defeat MFA may instead persuade a help-desk employee to reset it.

Biometrics

Biometric authentication uses measurable biological or behavioral characteristics. It offers convenience and can reduce dependence on memorized secrets. However, biometric data is not a perfect secret. A fingerprint or face cannot normally be replaced in the same way as a password after compromise.

Biometric systems compare a sample with a stored template and make a probabilistic decision. Important error concepts include:

• False acceptance: an unauthorized person is accepted.
• False rejection: an authorized person is rejected.
• Equal error rate: the operating point at which false-acceptance and false-rejection rates are equal.

Biometrics should generally be used as one component of a broader authentication design. Organizations must address consent, accessibility, demographic performance differences, template protection, retention, and lawful processing of sensitive personal data.

3. Authorization Models

Authentication answers “Who are you?” Authorization answers “What may you do?” Authorization should be explicit, reviewable, and based on business need.

Access control lists and capability models

An access control list (ACL) attaches permissions to an object. For example, a document may list users and their read or write rights. A capability model instead gives a subject a protected token or capability representing authority over an object. ACLs are intuitive for file ownership, while capabilities can support delegation and distributed systems.

Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to roles and roles to users. A user may hold roles such as student, lecturer, examiner, or system administrator. RBAC reduces the need to manage permissions individually and fits organizations with stable job functions.

The core relationships are:

• users are assigned roles;
• roles are assigned permissions;
• permissions apply to operations on resources.

RBAC can support role hierarchies, in which a senior role inherits permissions from a junior role, and separation-of-duty constraints, such as preventing one person from both creating and approving a payment. Its limitations include role explosion, slow adaptation to changing context, and difficulty representing temporary or data-specific conditions.

Attribute-Based Access Control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, object, action, and environment. An example policy might state:

Permit a clinician to read a patient record when the clinician is assigned to that patient, is using an approved device, and is within an active treatment period.

ABAC is expressive and suitable for cloud, data-sharing, and dynamic environments. Its complexity can make policies difficult to test and explain. Attribute quality is critical: inaccurate job, device, location, or classification data can produce unsafe decisions.

Many organizations combine the models. A role provides a baseline, while attributes impose conditions such as device compliance, time, sensitivity, or geographic restrictions.

Least privilege and zero trust

Least privilege gives a subject only the permissions necessary for an approved task, for the minimum practical duration. It limits damage when an account is compromised. Least privilege is not the same as “deny everything permanently”; legitimate work must remain possible through carefully controlled elevation.

Zero trust is a security approach rather than a single product. Its central idea is that no user, device, network, or application should receive implicit trust merely because of its location. Access is continuously evaluated using identity, device posture, resource sensitivity, policy, and risk. Zero trust does not mean that trust is never used; it means that trust is conditional, explicit, and subject to reassessment.

4. Federation and Single Sign-On

Organizations often use many applications, cloud services, and partner systems. Requiring a separate password for every service increases user burden and password reuse. Single Sign-On (SSO) allows a user to authenticate once and access multiple authorized applications.

In federated identity, one organization or service acts as an identity provider (IdP) and another acts as a service provider (SP) or relying party. The IdP authenticates the user and issues an assertion or token describing the authentication event and identity claims. The service provider validates the token and makes its own authorization decision.

Common technologies include:

• SAML: an XML-based federation framework widely used in enterprise web applications;
• OAuth 2.0: an authorization framework for delegated access, not by itself an authentication protocol;
• OpenID Connect (OIDC): an identity layer built on OAuth 2.0, commonly using JSON Web Tokens;
• Kerberos: a ticket-based protocol used in many enterprise directory environments.

SSO improves usability, centralizes policy, and supports rapid deprovisioning. It also creates concentration risk: compromise of the IdP may affect many connected applications. Federation therefore requires strong IdP protection, careful token validation, limited scopes, correct audience and issuer checks, secure redirect configuration, clock management, logging, and rapid key rotation.

A token should not be treated as proof of unlimited authority. The receiving application must validate signature, issuer, audience, expiry, nonce or state where applicable, and required claims. It must then apply local authorization rules.

5. Identity Lifecycle Management

Identity lifecycle management governs an account from creation to removal. A typical lifecycle includes:

1. Joiner: verify the person or system, establish ownership, assign a unique identity, and grant baseline access.
2. Mover: update roles and permissions when responsibilities, departments, contracts, or risk conditions change.
3. Leaver: disable authentication, revoke sessions and tokens, recover devices and credentials, transfer business data, and preserve records appropriately.

Identity proofing should establish that an identity corresponds to a real and authorized subject. The level of proof should match the risk of the account. A temporary visitor account should not receive the same proofing process as a database administrator.

Provisioning may be manual, workflow-based, or automated through standards such as SCIM. Automation improves consistency but can propagate incorrect source data rapidly. Therefore, identity sources, approval paths, exception handling, and reconciliation must be governed.

Periodic access reviews should ask whether each permission remains necessary, whether the manager or owner approved it, whether dormant accounts exist, and whether conflicting duties are present. Reviews that merely generate large reports without meaningful ownership are weak controls.

6. Privileged-Access Management

Privileged accounts can change security controls, access sensitive data, create identities, or modify infrastructure. Examples include domain administrators, database administrators, cloud root accounts, network engineers, and emergency “break-glass” accounts.

Privileged-Access Management (PAM) reduces risk through:

• separate administrative accounts rather than using an everyday account for administration;
• just-in-time and time-limited privilege elevation;
• approval workflows for sensitive operations;
• password vaulting and automatic credential rotation;
• session recording and command logging where lawful and proportionate;
• strong MFA and phishing-resistant authentication;
• restrictions on direct use of shared accounts;
• emergency access with post-event review.

A PAM design must avoid becoming an operational obstacle. If legitimate administrators cannot obtain timely access, they may create bypasses. Usability, availability, documented emergency procedures, and tested recovery are therefore part of security design.

7. Accountability, Monitoring, and Metrics

Accountability requires reliable records. IAM logs should capture authentication successes and failures, MFA changes, password resets, account creation and deletion, privilege elevation, policy decisions, token issuance, and administrative actions. Logs should include a consistent timestamp, subject, source, target resource, action, result, and correlation identifier.

Logs must be protected against unauthorized alteration and excessive disclosure. Sensitive values such as passwords, access tokens, and biometric templates should never be recorded in ordinary security logs.

Useful IAM metrics include:

• percentage of privileged accounts protected by MFA;
• time between employee departure and account disablement;
• number and age of dormant accounts;
• percentage of access reviews completed on time;
• number of failed and anomalous authentication events;
• number of standing privileged permissions;
• mean time to revoke compromised credentials.

Metrics should guide decisions rather than reward superficial compliance. A high MFA enrollment rate is valuable, but it does not prove that recovery channels are secure or that phishing-resistant methods are deployed for high-risk users.

8. Credential Theft and Identity-First Security

Credential theft may begin with a phishing message, malicious browser extension, infostealer malware, exposed secrets in source code, password reuse, or compromise of a third-party provider. Attackers may then use valid credentials to appear legitimate.

Defensive measures include:

• phishing-resistant MFA for administrators and sensitive applications;
• password managers and breached-password screening;
• conditional access based on device and risk signals;
• impossible-travel and anomalous-session detection, used cautiously because location signals can be inaccurate;
• token protection and short, appropriately managed session lifetimes;
• endpoint detection and response;
• secrets management for applications and automated rotation;
• network and application segmentation;
• rapid revocation of sessions, refresh tokens, keys, and certificates;
• user and help-desk training against social engineering.

Identity-first security does not imply that identity replaces network, endpoint, application, or data security. Rather, identity becomes a central control plane that must be combined with defense in depth.

9. Illustrative Case: University Research Cloud

Background

A university research group stores sensitive medical-imaging data in a cloud platform. Researchers, clinical partners, students, and automated analysis services require different levels of access.

Problem

The group initially uses shared accounts, long-lived access keys, and broad permissions. A student leaves the project, but the account remains active. An attacker later obtains an access key from a public code repository and downloads data.

Analysis

The university has failures in identification, lifecycle management, authorization, and accountability. Shared accounts prevent reliable attribution. Long-lived keys increase exposure. Broad permissions violate least privilege, and the absence of a reliable leaver process leaves dormant access.

Approach and solution

The university establishes individual federated identities through its institutional IdP and requires phishing-resistant MFA for staff and administrators. RBAC supplies baseline roles such as researcher, data steward, and platform administrator. ABAC adds conditions based on project membership, data classification, managed-device status, and research approval.

Service identities use a secrets manager and short-lived credentials rather than keys embedded in source code. Administrative actions require PAM-based, time-limited elevation. Cloud storage is separated by project and classification. Access reviews occur at each project milestone and when membership changes. Logs are centralized and correlated with identity, device, and data-access events.

Outcome

The university can attribute actions to named identities, revoke a departing researcher promptly, limit automated services to required datasets, and investigate unusual downloads. The design does not eliminate risk, but it reduces the blast radius of credential compromise and improves regulatory evidence.

Learning points

IAM failures are often process failures as well as technology failures. Federation, MFA, RBAC, ABAC, PAM, lifecycle automation, and monitoring must operate as a connected system. A technically strong login mechanism cannot compensate for excessive authorization or delayed deprovisioning.

10. Governance, Ethics, and Contemporary Developments

IAM processes affect privacy, autonomy, accessibility, and employment. Organizations should collect only necessary identity attributes, restrict their use, define retention periods, and protect them from secondary misuse. Biometric and behavioral data require especially careful governance. Authentication mechanisms must provide accessible alternatives for people who cannot use a particular biometric or device.

Separation of duties can prevent fraud, but excessive monitoring can create a culture of surveillance. Security teams should apply proportionality, transparency, purpose limitation, and due process when investigating users.

Contemporary IAM increasingly includes passwordless authentication, device-bound credentials, continuous risk assessment, decentralized identity proposals, workload identity for cloud-native systems, and machine identities used by APIs and AI agents. Machine identities may outnumber human identities and often have poorly controlled secrets. They require ownership, inventory, scoped permissions, rotation, monitoring, and retirement just as human accounts do.

AI can assist with anomaly detection, identity correlation, and access-review prioritization. However, automated decisions may produce false positives, encode bias, or be difficult to explain. High-impact access denial should have human review, documented policy, and an appeal or recovery process. AI systems themselves require carefully governed identities and least-privilege access to data and tools.

Best-Practice Design Checklist

A sound IAM program should:

• maintain a unique identity for each human and service subject;
• use risk-appropriate identity proofing;
• deploy phishing-resistant MFA for privileged and high-value access;
• store passwords with modern salted adaptive hashing;
• enforce least privilege and separation of duties;
• combine RBAC with contextual ABAC where appropriate;
• centralize federation without creating an uncontrolled single point of failure;
• automate joiner, mover, and leaver processes;
• manage privileged access through time-limited elevation;
• protect, review, and retain IAM logs appropriately;
• test account recovery, emergency access, and incident revocation;
• include privacy, accessibility, and governance in design decisions;
• review both human and machine identities regularly.

Chapter Summary

Identity and Access Management establishes how subjects are identified, authenticated, authorized, and held accountable. Authentication factors include knowledge, possession, and inherence, with phishing-resistant MFA generally providing stronger protection than passwords or SMS codes alone. Passwords must be stored with salted, adaptive password-hashing algorithms rather than plaintext or fast unsalted hashes.

Authorization models determine what authenticated subjects may do. RBAC is manageable for stable job functions, while ABAC supports fine-grained decisions based on subject, object, action, and environmental attributes. Least privilege, separation of duties, and zero trust reduce the consequences of compromised identities.

Federation and SSO improve usability and centralize identity policy, but compromise of an identity provider can create broad impact. Identity lifecycle management must cover joiners, movers, and leavers. PAM protects administrative accounts through separation, vaulting, approval, time-limited elevation, and monitoring. Accountability depends on reliable logs and meaningful access reviews.

An identity-first security program treats credentials, tokens, devices, service accounts, and machine identities as critical security assets. Effective IAM is therefore a combination of technology, governance, process, privacy protection, and continuous review.

Key Terms

Identity: A distinguishable representation of a person, device, service, or process.

Identification: The act of claiming an identity.

Authentication: Verification that a subject controls a claimed identity or authenticator.

Authorization: The decision about which actions an authenticated subject may perform.

Accountability: The ability to associate actions with an identity through records and controls.

MFA: Authentication using at least two different factor categories.

Password hash: A one-way computational representation used to verify a password.

Salt: A unique random value combined with a password before hashing.

Biometrics: Authentication based on biological or behavioral characteristics.

RBAC: Access control based on organizational roles.

ABAC: Access control based on subject, object, action, and environmental attributes.

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

Zero trust: A model that avoids implicit trust and continuously evaluates access.

Federation: Trust between identity and service providers for cross-organization authentication.

SSO: A mechanism allowing access to multiple services after one authentication event.

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

PAM: Controls for protecting and governing privileged accounts.

Provisioning: Creating and assigning an identity and its access.

Deprovisioning: Removing or disabling identity access when it is no longer authorized.

Credential stuffing: Using stolen username-password pairs against other services.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accountability.
2. Why is a salt used in password storage?
3. What is the difference between RBAC and ABAC?
4. State two advantages and one risk of SSO.
5. What is meant by least privilege?

Long Answer Questions

1. Explain the principal authentication factors and evaluate the security of password, SMS, push-notification, hardware-key, and biometric methods.
2. Describe a complete joiner-mover-leaver identity lifecycle and identify common control failures.
3. Compare RBAC and ABAC for a large university or hospital, including their strengths and limitations.
4. Explain how PAM reduces the risk associated with administrator accounts.
5. Discuss how federation, SSO, and zero trust can be combined in a cloud-based organization.

Analytical / Application Questions

1. A company discovers that a departed contractor still has access to cloud storage, while several employees share one administrator account. Analyze the accountability and lifecycle failures and propose a remediation plan.
2. Design an authorization policy for a hospital in which doctors, nurses, billing staff, and researchers access patient information. Use RBAC, ABAC, least privilege, and separation of duties.
3. An employee approves repeated MFA prompts during a phishing attack. Analyze why MFA failed and recommend stronger authentication, recovery, monitoring, and training controls.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a subject controls a claimed identity?

A. Identification

B. Authentication

C. Authorization

D. Accountability

Correct Answer: B. Authentication

Question 2

Which combination is an example of multifactor authentication?

A. Password and PIN

B. Fingerprint and face scan

C. Password and hardware security key

D. Username and password

Correct Answer: C. Password and hardware security key

Question 3

What is the primary purpose of a salt in password storage?

A. To encrypt the password for transmission

B. To make each password hash unique and reduce precomputed attacks

C. To permit administrators to recover plaintext passwords

D. To replace the need for password hashing

Correct Answer: B. To make each password hash unique and reduce precomputed attacks

Question 4

Which access-control model evaluates attributes of the subject, object, action, and environment?

A. RBAC

B. ACL-only control

C. ABAC

D. Single sign-on

Correct Answer: C. ABAC

Question 5

What is a major limitation of role-based access control in highly dynamic environments?

A. It cannot assign permissions to users

B. It may produce role explosion and represent context poorly

C. It requires biometric authentication

D. It prevents separation of duties

Correct Answer: B. It may produce role explosion and represent context poorly

Question 6

In federated identity, what is the usual role of an identity provider?

A. It stores every application’s business data

B. It authenticates subjects and issues assertions or tokens

C. It replaces all authorization decisions made by service providers

D. It disables multifactor authentication

Correct Answer: B. It authenticates subjects and issues assertions or tokens

Question 7

Which practice best supports least privilege for a database administrator?

A. Permanent unrestricted root access

B. A shared administrator password

C. Time-limited elevation for approved administrative tasks

D. Access based only on office location

Correct Answer: C. Time-limited elevation for approved administrative tasks

Question 8

Which event is most directly part of the leaver process?

A. Assigning an initial department role

B. Disabling accounts and revoking active sessions

C. Creating a temporary project identity

D. Adding a new device to inventory

Correct Answer: B. Disabling accounts and revoking active sessions

Question 9

Why are shared administrator accounts a serious accountability problem?

A. They always use weak encryption

B. They prevent reliable attribution of actions to individuals

C. They cannot be protected with passwords

D. They automatically grant external access

Correct Answer: B. They prevent reliable attribution of actions to individuals

Question 10

Which authentication method is generally considered most resistant to ordinary phishing?

A. SMS one-time code

B. Security question

C. Password-only login

D. Phishing-resistant FIDO2 or WebAuthn credential

Correct Answer: D. Phishing-resistant FIDO2 or WebAuthn credential