Identity and Access Management

Introduction and Context

Identity and Access Management (IAM) is the discipline of establishing who or what is requesting access, verifying that identity, deciding what the subject may do, recording the activity, and continuously governing the identity throughout its lifecycle. It applies to employees, contractors, customers, applications, devices, services, and automated agents.

IAM is a central cybersecurity control because most attacks ultimately seek to obtain, misuse, or escalate privileges. A compromised user account may provide an attacker with access to email and collaboration systems; a stolen administrator credential may enable widespread compromise; and an incorrectly configured service identity may expose databases or cloud resources. Effective IAM therefore combines technology, policy, human processes, and assurance activities.

A useful access-control sequence is:

1. Identification: a subject claims an identity.
2. Authentication: the system verifies the claim.
3. Authorisation: policy determines what the authenticated subject may do.
4. Accounting and auditing: activity is recorded, reviewed, and investigated.

These functions are related but not interchangeable. Authentication does not itself grant permission, and authorisation cannot be trusted if identity verification is weak.

Learning Objectives

After completing this chapter, students should be able to:

• distinguish identification, authentication, authorisation, accounting, and auditing;
• compare discretionary, mandatory, role-based, and attribute-based access control;
• design appropriate multifactor authentication and privileged access controls;
• explain federation, single sign-on, and common identity protocols;
• apply identity lifecycle controls from provisioning through deprovisioning;
• analyse IAM risks in a realistic organisational scenario; and
• evaluate governance, privacy, usability, and operational limitations of IAM solutions.

The IAM Reference Model

An IAM system contains several interacting elements:

• Subject: an entity requesting access, such as a person, service, device, or application.
• Digital identity: attributes and credentials associated with a subject.
• Credential: evidence used during authentication, such as a password, cryptographic key, or biometric.
• Resource: an object requiring protection, such as a file, API, database, or facility.
• Policy: a rule specifying permitted or denied actions.
• Policy decision point (PDP): evaluates a request against policy.
• Policy enforcement point (PEP): enforces the decision at the resource boundary.
• Identity provider (IdP): authenticates subjects and issues assertions or tokens.
• Service provider (SP) or relying party: consumes an identity assertion to provide a service.

A typical request can be represented conceptually as:

Here, Decision is normally permit or deny; Subject is the requesting identity; Resource is the protected object; Action is an operation such as read or delete; Context may include time, location, device posture, and risk; and Policy contains the governing rules. This is a conceptual policy function rather than a universal software formula. Its value lies in showing that modern authorisation depends on more than a username.

Identification, Authentication, and Authorisation

Identification assigns a claimed identity to a request. Examples include entering a username, presenting an account identifier, or supplying a client certificate identity.

Authentication tests the claim. Authentication factors are commonly grouped as:

Multifactor authentication (MFA) requires evidence from at least two different factor categories. Two passwords are two credentials from the same category, not MFA. A phishing-resistant security key is generally stronger than a one-time code sent through a potentially compromised channel.

Authorisation determines whether an authenticated subject may perform a requested operation. It should enforce least privilege, separation of duties, and need to know. A user may be authenticated successfully but denied access to a particular payroll record.

Accounting and auditing record events such as successful and failed logins, privilege changes, policy decisions, administrative actions, and data access. Logs should support detection, investigation, compliance, and accountability. They require accurate time synchronisation, protection against alteration, suitable retention, and controlled access.

Access-Control Models

Discretionary Access Control

In Discretionary Access Control (DAC), the owner of a resource can decide who may access it. Traditional file permissions and access-control lists are common examples. DAC is flexible and easy to understand, but permissions may spread through uncontrolled sharing. A user who owns a document might grant access to another person without central review.

DAC is appropriate where local ownership and collaboration are important, but organisations should supplement it with sharing restrictions, periodic reviews, and data classification.

Mandatory Access Control

Mandatory Access Control (MAC) uses centrally defined labels and rules. Subjects and objects receive classifications, such as Confidential, Secret, or Top Secret, and access is determined by an authority rather than by the resource owner. MAC is valuable in military, intelligence, and high-assurance environments where information flows must be tightly controlled.

Its strength is resistance to casual permission changes. Its weaknesses include administrative complexity, reduced flexibility, and the difficulty of maintaining accurate classifications.

Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to roles, and users receive roles based on job responsibilities. For example, a claims examiner may receive permissions to view and update claims, while an auditor receives read-only access.

RBAC reduces direct user-permission assignments and supports joiner, mover, and leaver processes. However, role explosion can occur when organisations create excessive combinations of department, location, project, and seniority. Role design should begin with business functions and use least privilege rather than reproducing every existing permission.

Attribute-Based Access Control

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might state: “Permit a clinician to view a patient record when the clinician is assigned to the patient, the device is managed, and the request occurs during an approved session.”

ABAC supports fine-grained and contextual decisions, particularly in cloud and application environments. Its challenges include attribute quality, policy complexity, explainability, and testing. Incorrect or stale attributes can create serious access errors.

Comparing the Models

These models are not always mutually exclusive. An enterprise may use RBAC for baseline permissions, ABAC for device and location conditions, and MAC labels for particularly sensitive information.

Authentication Engineering

Passwords and Credential Storage

Passwords should be long, unique, and protected against guessing, reuse, phishing, and automated credential stuffing. Systems must not store plaintext passwords. They should use a salted, adaptive password-hashing function, with parameters selected according to current security guidance and operational capacity. Encryption alone is not an adequate substitute for password hashing because encryption keys can expose all stored passwords.

Password policy should avoid unnecessary periodic changes that encourage predictable variations. Changes should be required after compromise, recovery events, or credible evidence of exposure. Password managers and breached-password screening can improve security.

One-Time Passwords and Push Authentication

Time-based one-time passwords generate codes from a shared secret and time interval. Push authentication can be convenient but may be vulnerable to approval fatigue, in which an attacker repeatedly sends prompts until a user accepts one. Number matching, rate limiting, risk detection, and user education reduce this risk.

Cryptographic and Phishing-Resistant Authentication

Public-key authentication uses a private key held by the authenticator and a public key registered with the service. The private key need not be transmitted to the service. Hardware-backed authenticators and WebAuthn/FIDO2-style mechanisms can resist many phishing attacks because authentication is bound to the legitimate relying-party origin.

Biometrics are useful for unlocking a device or authenticator, but they are not secrets in the same sense as passwords. Biometric templates require strong protection, limited use, clear retention rules, and fallback procedures.

Adaptive Authentication

Adaptive or risk-based authentication evaluates contextual signals such as unfamiliar device, impossible travel, unusual transaction, malware indicators, or anomalous behaviour. A high-risk event may require a stronger factor or a fresh authentication. Risk engines should not become an opaque source of unjustified denial; decisions need monitoring, appeal paths, and testing for bias and accessibility impacts.

Federation and Single Sign-On

Single sign-on (SSO) allows a user to authenticate once and access multiple authorised services without separately entering credentials for every service. SSO improves usability and can reduce password reuse, but compromise of the central identity provider may affect many applications. Strong IdP protection, MFA, session controls, and emergency access procedures are therefore essential.

Federation allows separate security domains to trust identity assertions issued by one another. Common technologies include:

• SAML: an XML-based framework widely used for browser-based enterprise federation;
• OAuth 2.0: an authorisation framework for delegated access, not an authentication protocol by itself;
• OpenID Connect: an authentication identity layer built on OAuth 2.0 using ID tokens;
• LDAP and Active Directory protocols: commonly used for directory queries and enterprise identity services.

Trust relationships must define issuer validation, audience restrictions, token lifetime, signing-key rotation, claim minimisation, clock tolerance, logout behaviour, and incident response. A service should accept tokens only from intended issuers and for the intended audience. Access tokens should receive only the scopes required for the task.

Privileged Access Management

Privileged accounts can change security settings, create users, access sensitive data, or control infrastructure. Privileged Access Management (PAM) reduces their exposure through:

• separate administrator and everyday accounts;
• just-in-time and time-limited elevation;
• approval workflows for high-risk actions;
• credential vaulting and automated rotation;
• session recording and command auditing;
• restrictions on direct internet access from administrative sessions;
• emergency or break-glass accounts with strong monitoring; and
• regular review of standing privileges.

PAM must cover non-human privileged identities as well as people. Cloud roles, CI/CD service accounts, database service principals, and cryptographic keys should have owners, limited permissions, rotation arrangements, and monitoring.

Identity Lifecycle Management

Identity governance begins before account creation and continues until all access is removed. The lifecycle is often described as joiner, mover, and leaver management.

1. Request and proofing: verify identity and employment or business need.
2. Provisioning: create the account, assign a unique identifier, and grant approved baseline access.
3. Access review: confirm that access remains necessary and appropriate.
4. Change management: adjust access when duties, department, location, or risk changes.
5. Suspension or deprovisioning: disable accounts promptly when employment or access need ends.
6. Evidence and retention: preserve approvals, changes, and audit records according to policy.

Automated provisioning through authoritative sources, such as a human-resources system, reduces delay and error. Automation must nevertheless fail safely. If an HR feed is incorrect, automatic mass deprovisioning can disrupt operations; reconciliation, approval thresholds, and rollback procedures are necessary.

Periodic access certification should be risk-based. Administrators and owners of sensitive systems deserve more frequent and detailed review than ordinary low-risk application access. Reviews should examine actual use, not merely confirm that an account exists.

Auditing, Monitoring, and Assurance

IAM logs should answer: who acted, what was accessed, which action occurred, when and where it occurred, which device or service was involved, and whether the request was permitted or denied. Important events include authentication failures, MFA changes, password resets, new API keys, role changes, privilege elevation, policy edits, and access to sensitive records.

Logs should be sent to protected central storage or a security information and event management platform. Controls should include integrity protection, restricted administrative access, time synchronisation, retention schedules, and alert tuning. Excessive collection can create privacy and storage problems; insufficient collection prevents reliable investigation.

Useful operational measures include:

• percentage of privileged accounts protected by MFA;
• number and age of orphaned accounts;
• time from termination to account disablement;
• percentage of access reviews completed on time;
• number of standing privileged assignments;
• authentication failure and lockout trends; and
• mean time to detect and revoke compromised credentials.

Metrics must be interpreted carefully. A high number of blocked logins may reflect an attack, a poorly designed application, or legitimate usability problems.

Applied Case: Illustrative Regional Healthcare Provider

Background

Northbridge Health operates hospitals, clinics, laboratories, and a patient portal. It has 8,000 employees, contractors, medical devices, and cloud applications. Users currently maintain separate passwords for clinical, finance, and collaboration systems.

Problem

An attacker used a reused contractor password to access email and then persuaded an employee to approve repeated MFA prompts. The attacker accessed internal documents and attempted to obtain elevated privileges. The organisation also discovered former contractors whose accounts remained enabled and several shared administrator accounts with poor accountability.

Analysis

The incident involved weaknesses in authentication, lifecycle management, privileged access, and auditing. Password reuse increased the likelihood of compromise; push fatigue weakened MFA; delayed deprovisioning created unnecessary exposure; and shared accounts prevented attribution. The organisation also lacked a complete inventory of service identities.

Approach and Solution

Northbridge implemented a central IdP with phishing-resistant authentication for administrators and high-risk clinical applications. Push MFA was retained temporarily for lower-risk users but received number matching and rate limits. SSO reduced password duplication, while application access was governed through RBAC for job functions and ABAC conditions for managed devices and clinical assignment.

The organisation introduced separate administrator accounts, a PAM vault, just-in-time elevation, session recording, and emergency-account testing. HR became the authoritative source for workforce status, with automated disablement on termination and manual review for contractors. Quarterly access certification was introduced for sensitive systems, and a central monitoring service alerted on impossible travel, new authentication methods, privilege changes, and unusual data access.

Outcome

The organisation reduced standing administrator privileges, improved termination response, and gained stronger attribution. Clinical leadership raised concerns about workflow interruption, so deployment included clinical pilots, offline contingency procedures, accessibility testing, and a documented emergency process.

Learning Points

IAM is not solved by purchasing an MFA product. Successful implementation requires identity proofing, appropriate policy models, reliable attributes, lifecycle integration, privileged-access controls, monitoring, usability design, and governance. Security controls must protect patients while preserving safe and timely clinical work.

Challenges, Ethics, and Governance

IAM systems create extensive records about people’s activities. Organisations should apply purpose limitation, data minimisation, retention limits, access restrictions, and transparent notices. Biometric processing deserves particular scrutiny because biometric characteristics are difficult to replace after exposure.

Access decisions can reproduce organisational bias if attributes such as job title, location, or risk score are inaccurate or discriminatory. Automated denials should be explainable enough for authorised staff to investigate and correct errors. Accessibility is also essential: users may be unable to use a particular biometric, mobile device, or physical token.

Regulatory requirements vary by jurisdiction and sector, but common governance expectations include least privilege, separation of duties, auditability, protection of personal data, incident response, and demonstrable control effectiveness. Organisations should map IAM controls to applicable laws, contractual obligations, and recognised security frameworks rather than assuming that a single certification guarantees security.

Contemporary Developments and Best Practices

Zero Trust architecture treats authentication and authorisation as continuous decisions rather than one-time checks at a network boundary. It does not mean trusting no one; it means granting access based on verified identity, device posture, resource sensitivity, and current context.

Cloud-native environments increasingly use workload identities, short-lived tokens, infrastructure-as-code, and policy-as-code. These improve repeatability but create risks when secrets are embedded in repositories or when automated roles are overprivileged. AI-assisted detection can identify anomalous identity behaviour, but models may generate false positives, inherit biased data, or be manipulated. Human oversight, protected telemetry, explainable alerts, and safe rollback remain necessary.

Effective IAM practice includes:

• maintain an accurate inventory of human, machine, and service identities;
• use unique identities and prohibit avoidable shared accounts;
• apply least privilege and separation of duties;
• prefer phishing-resistant MFA for privileged and high-risk access;
• centralise identity where appropriate while planning IdP resilience;
• automate joiner, mover, and leaver processes with validation;
• protect and monitor privileged sessions;
• use short-lived credentials and rotate secrets;
• test federation, recovery, break-glass, and deprovisioning procedures;
• review policies and attributes regularly; and
• measure outcomes rather than merely counting deployed controls.

Chapter Summary

Identity and Access Management establishes, verifies, governs, and audits access for people, devices, applications, and services. Identification is a claim, authentication verifies that claim, authorisation applies policy, and accounting provides evidence. DAC gives owners discretion; MAC applies central labels; RBAC connects permissions to job roles; and ABAC evaluates attributes and context. MFA is strongest when factors are independent and resistant to phishing. SSO and federation improve usability but make identity-provider protection critical. PAM limits privileged exposure through separation, time-limited elevation, vaulting, and monitoring. Lifecycle controls ensure that access is approved, changed, reviewed, and removed as organisational circumstances change. Effective IAM also requires privacy protection, accessibility, governance, accurate attributes, resilient operations, and continuous auditing.

Key Terms

Authentication: Verification of a claimed identity.

Authorisation: Determination of whether an authenticated subject may perform an action.

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

Accounting: Recording identity and access events for accountability and investigation.

DAC: Access control in which resource owners decide permissions.

Federation: Trust arrangement allowing identities from one domain to access another domain.

Identity provider: Service that authenticates identities and issues assertions or tokens.

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

MAC: Access control governed by centrally defined classifications and rules.

MFA: Authentication requiring evidence from at least two different factor categories.

PAM: Controls for protecting, monitoring, and limiting privileged access.

PEP: Component that enforces an access-control decision.

PDP: Component that evaluates policy and produces an access decision.

RBAC: Access control based on organisational roles.

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

Service identity: Identity used by an application, workload, device, or automated process.

Separation of duties: Division of sensitive responsibilities to reduce fraud or error.

SSO: Abbreviation for single sign-on.

Zero Trust: Security approach that continuously evaluates access rather than trusting network location alone.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorisation, and accounting.
2. Why are two passwords not considered multifactor authentication?
3. State one strength and one limitation of RBAC.
4. What is the purpose of a policy enforcement point?
5. Identify two controls commonly used in privileged access management.

Long Answer Questions

1. Compare DAC, MAC, RBAC, and ABAC, and recommend suitable uses for each.
2. Explain how federation and SSO work, including their principal security risks.
3. Describe a complete joiner, mover, and leaver lifecycle process.
4. Discuss the design requirements for a secure and privacy-conscious IAM audit system.
5. Explain why IAM is a socio-technical discipline rather than only a software function.

Analytical / Application Questions

1. A university wants students, lecturers, visiting researchers, and automated laboratory systems to access research data. Design a combined RBAC and ABAC policy, identifying relevant roles, attributes, and risk controls.
2. An administrator approves an MFA prompt after receiving twelve unexpected prompts. Analyse the likely attack, identify immediate response actions, and recommend longer-term controls.
3. A company discovers that 15% of terminated contractors still have active accounts and that several cloud workloads use permanent administrator keys. Prioritise the remediation programme and justify your sequence.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a claimed identity is genuine?

A. Identification

B. Authentication

C. Authorisation

D. Accounting

Correct Answer: B. Authentication

Question 2

Which access-control model assigns permissions primarily to job functions?

A. Discretionary Access Control

B. Mandatory Access Control

C. Role-Based Access Control

D. Network Address Control

Correct Answer: C. Role-Based Access Control

Question 3

Which example provides evidence from two different authentication factor categories?

A. Two different passwords

B. A password and a hardware security key

C. A username and an account number

D. Two security questions

Correct Answer: B. A password and a hardware security key

Question 4

What is a principal risk of centralised single sign-on?

A. Users must create more passwords

B. Applications cannot use authorisation policies

C. Compromise of the identity provider may affect many services

D. Audit logs become impossible to generate

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

Question 5

Which control is most directly associated with privileged access management?

A. Permanent administrator access for all IT staff

B. Just-in-time elevation and session recording

C. Removing all audit logs after each session

D. Using shared administrator passwords

Correct Answer: B. Just-in-time elevation and session recording

Question 6

OAuth 2.0 is primarily an authorisation framework. Which technology adds an identity layer using ID tokens?

A. OpenID Connect

B. FTP

C. SNMP

D. SFTP

Correct Answer: A. OpenID Connect

Question 7

A clinician may view a patient record only when assigned to that patient and using a managed device. Which model best expresses this contextual policy?

A. ABAC

B. DAC only

C. MAC only

D. Password-only access

Correct Answer: A. ABAC

Question 8

Which lifecycle action is most important immediately after an employee’s confirmed termination?

A. Increase the employee’s privileges

B. Disable or revoke the employee’s access

C. Create a second active account

D. Extend all tokens indefinitely

Correct Answer: B. Disable or revoke the employee’s access

Question 9

Why should password systems use salted, adaptive password hashing rather than plaintext storage?

A. It makes passwords unnecessary

B. It limits the usefulness of stolen password databases and slows guessing

C. It allows administrators to read user passwords

D. It guarantees immunity from phishing

Correct Answer: B. It limits the usefulness of stolen password databases and slows guessing

Question 10

Which statement best describes a policy decision point?

A. It stores backups of user documents

B. It physically repairs authentication devices

C. It evaluates an access request against policy

D. It replaces all identity providers

Correct Answer: C. It evaluates an access request against policy