Identity and Access Management

Introduction

Identity and Access Management (IAM) is the discipline of ensuring that the right users, devices, services, and applications receive the right access to the right resources at the right time. It is a core part of cybersecurity because most attacks ultimately seek to obtain, misuse, or escalate digital privileges. A technically secure network can still be compromised if an attacker obtains a valid password, exploits excessive permissions, or abuses an inactive employee account.

IAM is broader than logging in. It includes identifying a subject, authenticating its claimed identity, authorizing permitted actions, recording activity, managing identity information throughout its lifecycle, and withdrawing access when it is no longer justified. These functions support confidentiality, integrity, availability, privacy, regulatory compliance, and operational accountability.

A useful conceptual sequence is:

Identification → Authentication → Authorization → Accountability

The sequence is not always strictly linear in implementation. For example, authorization decisions may be reevaluated during a session, and accountability depends on reliable identity information and event logging. Nevertheless, the sequence provides a foundation for analyzing access-control systems.

Learning Objectives

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

1. Distinguish identification, authentication, authorization, and accountability.
2. Explain passwords, password storage, multifactor authentication, and biometrics.
3. Compare discretionary, mandatory, role-based, attribute-based, and risk-adaptive access control.
4. Describe single sign-on, federation, and common identity protocols.
5. Explain privileged access management and separation of duties.
6. Apply identity lifecycle management to joiner, mover, and leaver processes.
7. Evaluate IAM risks, governance requirements, usability issues, and emerging developments.

The Four Core Functions of IAM

Identification

Identification is the act of claiming an identity. A subject may identify itself using a username, email address, employee number, device identifier, certificate subject, or service-account name. Identification does not prove that the claimant is genuine. A username is an assertion, not evidence.

IAM subjects include:

• Human users, such as employees, students, contractors, and customers.
• Devices, such as laptops, mobile phones, sensors, and servers.
• Applications and services, which may call application programming interfaces (APIs).
• Organizations, which may participate in federated trust relationships.

A principal is an entity recognized by an access-control system. An account is a record that associates a principal with credentials, attributes, permissions, and lifecycle status.

Authentication

Authentication verifies an identity claim. Authentication factors are generally classified as:

Traditional multifactor authentication (MFA) requires evidence from at least two independent factor categories. Entering a password and answering a security question generally remains single-factor authentication because both are knowledge factors.

Authentication assurance depends on the strength, independence, and protection of the factors. A password plus a one-time code delivered through a compromised email account may provide less assurance than a password plus a phishing-resistant hardware security key.

Authorization

Authorization determines what an authenticated subject is allowed to do. A decision may depend on:

• Subject identity and role
• Resource or object being accessed
• Requested operation, such as read, write, delete, or approve
• Environmental conditions, such as time, location, device health, and network
• Business rules, legal obligations, and risk level

Authorization should be based on least privilege: a subject receives only the access needed to perform an approved task. It should also follow default deny, meaning access is refused unless an explicit rule permits it.

Accountability

Accountability links actions to identifiable subjects and provides evidence for investigation, compliance, and improvement. It includes logging authentication events, authorization decisions, administrative changes, data access, and security alerts.

A useful audit record commonly contains the subject, timestamp, event type, resource, action, outcome, source device or address, and correlation identifier. Logs must be protected against unauthorized alteration, retained for an appropriate period, and monitored. Accountability is weakened by shared accounts, poor time synchronization, missing logs, and excessive administrative privileges.

Accountability is not identical to nonrepudiation. Audit records provide evidence that an account was used; they do not automatically prove that a particular human was physically responsible. Stronger attribution requires controls such as individual accounts, protected credentials, reliable time, tamper-evident logging, and appropriate investigation.

Passwords and Secrets

Passwords remain widespread because they are inexpensive and familiar, but they are vulnerable to guessing, credential stuffing, phishing, malware, reuse, and social engineering. Password security therefore requires both technical and behavioral controls.

Password storage

A password should not be stored as plaintext or encrypted in a reversible form merely for convenience. A verifier should store a password-derived value produced by a deliberately slow, memory-hard password hashing function, together with a unique salt. Modern examples include Argon2id, scrypt, and bcrypt, subject to secure configuration and current guidance.

The salt prevents identical passwords from producing identical stored values and makes precomputed rainbow tables less useful. It is not a secret. A password-hashing process may be represented abstractly as:

Here, p is the password, s is a unique random salt, c represents cost parameters such as time or memory, H is the password-hashing function, and v is the stored verifier. The equation is a model, not a recommendation to use a general-purpose hash such as SHA-256 alone. Password hashing must be slow enough to resist offline guessing but practical for legitimate authentication.

During login, the system retrieves the salt and cost parameters, hashes the submitted password, and compares the result using a safe comparison method. Password reset links and recovery codes must also be treated as authentication secrets.

Password policy

A sound policy should encourage long, memorable passwords or passphrases, block commonly breached passwords, prevent unnecessary reuse, and support password managers. Forced periodic changes can reduce risk after suspected compromise but may cause predictable patterns when applied without evidence. Organizations should prioritize phishing-resistant MFA, monitoring, and breach-response procedures rather than relying on arbitrary complexity rules alone.

Multifactor Authentication and Biometrics

MFA reduces the effect of a stolen password, but it does not eliminate risk. Attackers may use phishing proxies, prompt bombing, malware, stolen recovery codes, or social engineering against support staff.

Authentication methods vary in resistance to phishing:

• SMS codes are better than passwords alone but vulnerable to number takeover and interception.
• Time-based one-time passwords are useful but can still be entered into phishing sites.
• Push notifications are convenient but may be abused through repeated prompts.
• Hardware security keys using public-key cryptography provide strong phishing resistance when correctly deployed.
• Passkeys use public-key credentials and can provide convenient, phishing-resistant authentication across supported devices.

Biometrics measure a physical or behavioral characteristic. A biometric system compares a live sample with a stored template and produces a similarity decision. It is important to distinguish false acceptance, in which an unauthorized person is accepted, from false rejection, in which an authorized person is rejected. Reducing one error rate may increase the other, depending on the decision threshold and system design.

Biometrics are not secrets in the same sense as passwords. A fingerprint or face cannot easily be replaced if compromised. Therefore, biometrics are often most appropriate as a local unlock factor for a protected device, combined with a cryptographic credential, rather than as a universal remotely transmitted identifier. Privacy, accessibility, demographic performance differences, template protection, consent, and lawful processing must be considered.

Access-Control Models

Discretionary access control

In discretionary access control (DAC), resource owners can determine who may access an object. File permissions and access-control lists are common examples. DAC is flexible but can permit uncontrolled propagation of access and privilege accumulation.

Mandatory access control

Mandatory access control (MAC) applies centrally enforced labels and clearance rules. Users generally cannot override the policy. It is useful where information classification and formal security boundaries are critical, such as high-assurance or military environments.

Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. For example, a billing clerk may enter invoices but not approve payments. RBAC simplifies administration when job functions are stable. Its weakness is role explosion: large organizations may create hundreds of narrowly tailored roles that are difficult to manage.

Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might allow a physician to read a patient's record only when the physician is assigned to that patient, is using an approved device, and is acting during an authorized clinical context. ABAC supports fine-grained decisions but requires accurate, trusted attributes and policies that administrators can understand and test.

Risk-adaptive and zero-trust access

Risk-adaptive systems evaluate signals such as unfamiliar device, impossible travel, unusual data volume, or malware indicators. They may require additional verification, restrict functions, or terminate a session. Zero trust is not a single product or an assumption that a particular network is safe. It is an architectural approach that continuously evaluates identity, device, resource, and context and grants narrowly scoped access rather than trusting location alone.

Single Sign-On and Federation

Single sign-on (SSO) allows a user to authenticate once and access multiple applications without separately entering credentials for each application. SSO improves usability, reduces password reuse, and centralizes policy enforcement. However, compromise of the identity provider can affect many connected services, so the provider requires strong protection, resilient recovery, monitoring, and administrative separation.

Federation allows one organization or identity provider to assert identity and authentication information to another organization or relying party. The relying party trusts defined claims under an agreement and technical protocol. Federation is especially useful for universities, cloud services, suppliers, and business partners.

Common technologies include:

• SAML, widely used for browser-based enterprise federation.
• OAuth 2.0, an authorization framework for delegated access to resources; it is not, by itself, an authentication protocol.
• OpenID Connect, an authentication and identity layer built on OAuth 2.0.
• Kerberos, a ticket-based protocol commonly used in enterprise directory environments.

Federation introduces risks involving token theft, incorrect audience validation, excessive claims, weak redirect-URI controls, signing-key compromise, and poor trust governance. Relying parties should validate issuer, audience, signature, expiration, nonce or state where applicable, and required claims. Tokens should be short-lived and limited in scope.

Privileged Access Management

Privileged accounts can change security policies, install software, access sensitive data, create accounts, or disable controls. Examples include domain administrators, cloud root users, database administrators, and emergency recovery accounts.

Privileged Access Management (PAM) reduces risk through:

1. Separate administrative and ordinary user accounts.
2. Just-in-time or time-limited elevation.
3. Approval workflows for high-risk operations.
4. Credential vaulting, rotation, and controlled checkout.
5. Session recording or command logging where legally and operationally appropriate.
6. Strong MFA and phishing-resistant authentication.
7. Break-glass accounts protected, monitored, and tested for emergencies.
8. Periodic review of privileged permissions.

A common failure is treating a highly privileged account as a normal account. Administrative credentials should not be used for email or web browsing, because a phishing event could immediately become a system-wide compromise.

Separation of duties prevents one person from completing a sensitive process alone. For example, one employee may create a supplier and another may approve payment. Separation of duties may be preventive, detective, or compensating, depending on system design and organizational size.

Identity Lifecycle Management

Identity lifecycle management governs identities from creation to deletion. It is often described through the joiner–mover–leaver model.

Provisioning may be manual, automated through directory synchronization, or governed by identity governance and administration tools. Automation improves speed and consistency but can propagate errors if source data or role mappings are incorrect.

Lifecycle controls should include authoritative identity data, approval records, access recertification, service-account ownership, contractor expiration dates, orphan-account detection, and periodic reconciliation between HR, directories, cloud platforms, and applications. Deprovisioning must address active sessions, API tokens, certificates, SSH keys, mobile devices, shared secrets, and delegated access—not only the primary password.

Applied Case: University Cloud Access

Background

Consider a fictional university that uses a cloud learning platform, research storage, finance applications, and a central identity provider. Faculty, students, contractors, and visiting researchers are represented in separate administrative systems.

Problem

An audit finds three weaknesses: former contractors retain access to research storage, several laboratory administrators use shared accounts, and students receive excessive access through broad directory groups. Logs also lack consistent user identifiers across cloud applications.

Analysis

The university has weaknesses in all four IAM functions. Identity records are not synchronized reliably; authentication is weakened by shared accounts; authorization is overly broad; and accountability is incomplete because actions cannot always be attributed to an individual. The problem is not solved merely by purchasing MFA.

Approach

The university establishes the HR and student-information systems as authoritative sources for lifecycle events. It introduces individual accounts, phishing-resistant MFA for administrators, RBAC for standard teaching functions, and ABAC conditions for sensitive research repositories. Privileged administrators receive separate accounts and just-in-time elevation. Contractors receive automatically expiring identities tied to sponsor approval. Cloud applications accept federation tokens only after validating issuer, audience, signature, and expiration. Centralized logs use a consistent subject identifier and are sent to protected security monitoring systems.

Access reviews occur each semester and whenever a role changes. Break-glass accounts are documented and tested. Service accounts have named owners, limited scopes, and rotation procedures.

Outcome

The university reduces dormant accounts, improves attribution, limits administrative exposure, and makes access reviews more meaningful. Some users initially resist additional authentication steps, so training, self-service recovery, accessibility accommodations, and clear support procedures are included.

Learning Points

The case demonstrates that IAM is a governance and process discipline as well as a technical capability. Effective implementation combines authoritative identity data, strong authentication, least-privilege authorization, protected logging, lifecycle automation, and human oversight.

Governance, Ethics, and Regulation

IAM decisions affect privacy, equality, employment, academic freedom, and access to essential services. Organizations should collect only identity attributes necessary for a defined purpose, restrict their use, protect them throughout their lifecycle, and provide transparent procedures for correction and appeal.

Biometric processing deserves particular caution because biometric characteristics are sensitive and difficult to change. Monitoring and behavioral analytics can also create privacy risks or unfairly flag legitimate users. Automated risk decisions should be explainable enough for investigation and should include human review for consequential outcomes.

Regulatory requirements vary by jurisdiction and sector, but common expectations include access control, least privilege, segregation of duties, auditability, retention controls, breach response, and periodic review. Compliance is not equivalent to security: a compliant organization may still have exploitable design weaknesses.

Challenges and Limitations

IAM programs commonly encounter:

• Identity silos and inconsistent identifiers
• Legacy applications that cannot support modern authentication
• Excessive permissions accumulated over time
• Poorly owned service accounts and machine identities
• User resistance and accessibility barriers
• Availability risks when a central identity provider fails
• Token, session, and recovery-process compromise
• Incomplete logging and inaccurate time sources
• Third-party and supply-chain trust problems
• Misconfigured cloud roles and API permissions

A mature program addresses resilience through redundant identity services, tested recovery, offline emergency procedures, monitoring, and carefully controlled break-glass access. It also measures outcomes, such as time to revoke leaver access, percentage of privileged accounts protected by MFA, number of orphaned accounts, age of access reviews, and volume of excessive permissions.

Contemporary Developments and Best Practices

Modern IAM increasingly manages machine identities, workload identities, APIs, containers, and robotic processes in addition to people. These identities require owners, rotation, scoped permissions, inventory, and monitoring. Cloud environments make identity a primary security boundary because infrastructure is frequently accessed through APIs rather than physical networks.

Artificial intelligence can assist with anomaly detection, access-review prioritization, identity matching, and policy analysis. It should not be treated as an unquestionable authorization authority. Poor training data can produce false positives, discriminatory outcomes, or opaque decisions. High-impact access changes should retain human accountability and auditable evidence.

Recommended practices include:

1. Establish authoritative sources for identity data.
2. Use unique individual accounts and prohibit routine sharing.
3. Apply least privilege, default deny, and separation of duties.
4. Deploy phishing-resistant MFA for privileged and high-risk access.
5. Use secure password hashing and support password managers.
6. Automate joiner, mover, and leaver processes with approval controls.
7. Inventory and govern service, application, and machine identities.
8. Review privileged access and remove dormant or excessive permissions.
9. Protect logs, synchronize time, and monitor authentication anomalies.
10. Test federation, recovery, deprovisioning, and emergency access.
11. Design for privacy, accessibility, resilience, and regulatory obligations.
12. Treat identity as a continuously evaluated security control rather than a one-time gate.

Chapter Summary

Identity and Access Management establishes who or what a subject is, verifies its identity, determines what it may do, and records activity for accountability. Identification is an assertion; authentication supplies evidence; authorization applies policy; and accountability creates trustworthy records. Passwords should be protected with salted, deliberately costly password-hashing functions, while MFA—especially phishing-resistant methods—reduces dependence on passwords. Biometrics improve convenience but raise privacy and irreversibility concerns.

DAC, MAC, RBAC, ABAC, and risk-adaptive approaches provide different balances of flexibility, central control, precision, and administrative complexity. SSO and federation improve usability and organizational cooperation but make identity providers and token-validation processes critical security components. PAM protects high-impact administrative capabilities through separation, time limitation, vaulting, monitoring, and strong authentication. Identity lifecycle management ensures that access changes when people join, move roles, or leave. Effective IAM combines technology, governance, privacy, operational processes, and continuous review.

Key Terms

Identification: The act of claiming an identity.

Authentication: Verification of an identity claim.

Authorization: Determination of permitted actions on resources.

Accountability: Attribution of actions through reliable records and controls.

Principal: An entity recognized by an access-control system.

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

Relying party: An application or service that accepts an identity provider’s assertion.

Least privilege: Providing only the access required for an authorized task.

Multifactor authentication: Authentication using evidence from at least two independent factor categories.

Biometrics: Authentication based on physical or behavioral characteristics.

RBAC: Access control based on roles and assigned permissions.

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

Federation: Trust-based exchange of identity information across organizational or system boundaries.

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

Privileged access management: Controls for high-impact administrative accounts and actions.

Separation of duties: Dividing sensitive responsibilities to reduce unilateral abuse.

Joiner–mover–leaver: Lifecycle model for creating, changing, and terminating identities.

Service account: An identity used by an application, service, or automated process.

Phishing-resistant authentication: Authentication designed to prevent credentials or assertions being replayed to an impostor site.

Review Questions

Short Answer Questions

1. Distinguish identification from authentication.
2. What is the purpose of a unique salt in password storage?
3. Why is password plus security question generally not MFA?
4. State two benefits and one risk of single sign-on.
5. What should happen to active tokens when an employee leaves an organization?

Long Answer Questions

1. Explain the relationship between identification, authentication, authorization, and accountability using an enterprise example.
2. Compare RBAC and ABAC, including situations in which each is most appropriate.
3. Describe the security architecture and governance controls required for a mature privileged access management program.
4. Explain how SAML, OAuth 2.0, and OpenID Connect differ in purpose.
5. Discuss the privacy, security, and accessibility considerations of biometric authentication.

Analytical / Application Questions

1. A contractor changes from laboratory assistant to finance assistant but retains access to research storage. Analyze the lifecycle and authorization failures and propose corrective controls.
2. An organization has passwords, SMS codes, push notifications, and hardware security keys available. Rank them for phishing resistance and justify the ranking.
3. Design an IAM approach for a university cloud environment containing students, faculty, administrators, contractors, and automated research services. Identify authentication, authorization, lifecycle, logging, and governance controls.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication identifies a resource, while authorization encrypts it.

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

C. Authentication records events, while authorization creates passwords.

D. Authentication assigns roles, while authorization proves identity.

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

Question 2

Which combination is most clearly multifactor authentication?

A. Password and security question

B. PIN and password

C. Password and hardware security key

D. Two different passwords

Correct Answer: C. Password and hardware security key

Question 3

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

A. To make passwords recoverable by administrators

B. To prevent identical passwords from producing identical stored values

C. To replace the need for password hashing

D. To allow passwords to be stored in plaintext safely

Correct Answer: B. To prevent identical passwords from producing identical stored values

Question 4

Which access-control model assigns permissions to job functions and then assigns users to those functions?

A. Role-based access control

B. Discretionary access control

C. Mandatory access control

D. Unrestricted access control

Correct Answer: A. Role-based access control

Question 5

Which statement about OAuth 2.0 is correct?

A. It is primarily a password-hashing algorithm.

B. It is an authorization framework for delegated access.

C. It is a biometric matching standard.

D. It is a physical access-control model.

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

Question 6

Which control most directly reduces the risk of a former employee using an active session?

A. Increasing password length requirements

B. Revoking sessions and tokens during deprovisioning

C. Adding more directory groups

D. Allowing shared administrator accounts

Correct Answer: B. Revoking sessions and tokens during deprovisioning

Question 7

Why are separate administrative accounts recommended?

A. They eliminate the need for logging.

B. They prevent administrators from ever using MFA.

C. They reduce the chance that routine browsing compromises privileged credentials.

D. They give every user permanent administrative access.

Correct Answer: C. They reduce the chance that routine browsing compromises privileged credentials.

Question 8

Which is an example of accountability?

A. A user claiming a username

B. A system recording who approved a sensitive transaction and when

C. A password being entered into a login form

D. A role being created without an owner

Correct Answer: B. A system recording who approved a sensitive transaction and when

Question 9

Which characteristic is a significant limitation of biometrics compared with passwords?

A. Biometrics can never be used on mobile devices.

B. Biometric characteristics are difficult to replace if compromised.

C. Biometrics always require two passwords.

D. Biometrics cannot support local device unlocking.

Correct Answer: B. Biometric characteristics are difficult to replace if compromised.

Question 10

A policy permits a physician to read a patient record only when assigned to that patient and using an approved device. Which model best represents this policy?

A. Attribute-based access control

B. Uncontrolled discretionary access

C. Password-only authentication

D. Shared-account authorization

Correct Answer: A. Attribute-based access control