Identity and Access Management

Introduction

Identity and access management (IAM) is the discipline of ensuring that the right person, device, application, or service receives the right access to the right resource at the right time and for the right reason. IAM is therefore more than a login screen. It connects identity records, authentication technologies, authorization rules, administrative processes, monitoring, and accountability.

Modern organisations depend on IAM because information systems are distributed across on-premises networks, cloud platforms, mobile devices, software-as-a-service applications, and operational technology. A stolen password, excessive administrator privilege, or forgotten account can permit unauthorised access even when firewalls and endpoint controls are functioning correctly.

IAM supports the confidentiality, integrity, and availability of information. It also supports privacy, regulatory compliance, fraud reduction, and efficient service delivery. A sound IAM programme combines technical controls with governance and well-defined lifecycle processes.

Learning Objectives

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

• distinguish identification, authentication, authorization, and accountability;
• explain password security, multifactor authentication, and biometric authentication;
• compare role-based and attribute-based access control;
• apply least privilege and separation of duties;
• describe privileged access management and single sign-on;
• explain federation and common identity protocols;
• apply joiner, mover, and leaver identity lifecycle processes;
• evaluate IAM risks, controls, ethical issues, and implementation decisions.

1. The IAM Security Model

An access decision normally involves five elements:

1. Subject – an entity requesting access, such as a user, service, device, or process.
2. Identity – a representation of the subject in an identity system.
3. Resource – data, software, devices, networks, or services being protected.
4. Policy – rules describing what access is permitted.
5. Decision and enforcement point – components that evaluate and apply the policy.

A useful access sequence is:

Identification → Authentication → Authorization → Access → Accountability

These stages are related but not interchangeable.

Identification

Identification is the claim of an identity. Examples include entering a username, presenting an email address, selecting a smart-card certificate, or supplying a device identifier. Identification does not prove that the claimant is the legitimate entity.

Authentication

Authentication is the process of verifying a claimed identity. Authentication factors are usually classified as:

Multifactor authentication (MFA) requires two or more independent factor categories. Using a password and a PIN is generally two knowledge factors, not genuine MFA. A password combined with a hardware security key is an example of MFA.

Authorization

Authorization determines what an authenticated subject may do. It includes both the resource and the operation. For example, an employee may be authorized to read customer records but not export them, delete them, or change billing information.

Authorization should be based on business need, least privilege, and explicit policy rather than convenience. Authentication answers “Who are you?” Authorization answers “What are you allowed to do?”

Accountability

Accountability links actions to responsible identities and provides evidence for investigation, compliance, and operational improvement. It depends on unique accounts, reliable time sources, complete logs, protected audit records, and processes for reviewing events. Shared administrator accounts weaken accountability because an action cannot be confidently attributed to one person.

Accountability is not identical to non-repudiation. Accountability is an organisational and technical ability to associate activity with an actor; non-repudiation is stronger evidence, often involving cryptographic signatures and controlled procedures, that makes denial of an action difficult.

2. Authentication and Credential Security

Passwords and passphrases

Passwords remain widespread because they are inexpensive and familiar, but they are vulnerable to guessing, reuse, phishing, credential stuffing, malware, and database breaches. Effective password policy should focus on length, uniqueness, screening against known-compromised passwords, and resistance to automated attacks rather than arbitrary complexity rules alone.

A password must never be stored in plaintext. Systems should store a salted, slow password hash produced by a password-specific key-derivation function such as Argon2id, scrypt, or an appropriately configured PBKDF2 implementation. A salt is a unique random value stored with the password record. It prevents identical passwords from producing identical stored values and defeats precomputed rainbow tables. A salt does not make a weak password strong, so work-factor selection remains important.

A simplified password-verification process is:

1. receive a password over a protected connection;
2. retrieve the user’s salt and hashing parameters;
3. derive a hash using the submitted password;
4. compare the result using a secure comparison method;
5. apply rate limits, detection, and account-protection controls.

Passwords should be transmitted only through protected protocols such as TLS. Organisations should not require routine password changes without evidence of compromise, because frequent arbitrary changes can encourage predictable patterns. Password managers, passkeys, phishing-resistant MFA, and breached-password screening are generally stronger improvements.

Password risk and search space

For a uniformly random password selected from an alphabet of size A and length L, the number of possible strings is:

where N is the number of possible strings. The corresponding idealized entropy is:

where H is measured in bits. These equations assume independent, uniformly random character selection. Human-created passwords do not satisfy that assumption; predictable words and patterns greatly reduce effective security. Consequently, measured character count should not be confused with real-world password strength.

For an online attack, rate limiting, MFA, detection, and lockout controls can restrict attempts. Offline attacks against a stolen password database are different: the attacker can test guesses locally, making a slow password hash and a strong password especially important.

Multifactor authentication

MFA reduces the effect of password theft, but it does not eliminate all risk. SMS codes may be exposed through SIM swapping or interception. One-time codes can be phished. Push notifications may be abused through repeated approval prompts, known as prompt bombing or MFA fatigue.

The strongest widely deployed methods include hardware security keys and passkeys based on public-key cryptography. In public-key authentication, the private key remains under the user’s control while the public key is registered with the service. During authentication, the service issues a challenge, and the authenticator signs it. A phished website cannot normally use the credential for the legitimate site because the credential is bound to the correct origin.

Good MFA implementation includes recovery procedures, enrolment verification, device replacement controls, phishing-resistant options for high-risk users, and monitoring for unusual authentication patterns.

Biometrics

Biometric systems use measurable human characteristics to support recognition. They typically involve enrolment, feature extraction, template storage, matching, and a threshold decision. Biometric data is sensitive: unlike a password, a fingerprint or facial characteristic cannot easily be replaced if compromised.

Important performance terms include:

• False acceptance rate (FAR): probability that an unauthorized person is accepted.
• False rejection rate (FRR): probability that an authorized person is rejected.
• Equal error rate (EER): a comparison point at which FAR and FRR are equal, although operational systems may choose another threshold.

A lower acceptance threshold may improve convenience but increase false acceptance. A higher threshold may improve security but increase false rejection. Biometrics are often best used as an activation factor for a secure device or credential rather than as a standalone secret.

Biometric deployment must address consent, data minimization, accessibility, demographic performance differences, retention, legal basis, and alternative authentication for people unable to use the selected modality.

3. Authorization Models

Access control principles

Important principles include:

• Least privilege: grant only the access needed for an approved task.
• Need to know: restrict information access to what a subject requires.
• Separation of duties: divide incompatible responsibilities among people or systems.
• Default deny: deny access unless a policy explicitly permits it.
• Fail safely: security failures should not silently create excessive access.
• Periodic review: remove permissions that are no longer justified.

Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. For example, a “claims assessor” role may read claims and update assessment decisions, while a “finance officer” role may approve payments.

RBAC reduces administrative complexity when job responsibilities are stable. It also supports separation of duties by preventing one role from combining conflicting permissions. However, poorly designed roles can create role explosion, excessive privilege, or permissions that remain after a person changes duties.

A useful RBAC structure distinguishes:

• Users or subjects;
• Roles, representing job functions;
• Permissions, representing allowed operations on resources;
• Sessions, representing active use of assigned roles.

A permission should be specific enough to support review. “Access to the finance system” is less useful than “read invoices” or “approve payments below an authorised threshold.”

Attribute-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might permit a clinician to view a patient record when the clinician is assigned to the patient, the purpose is treatment, the device meets security requirements, and the request occurs during an approved session.

ABAC supports fine-grained and contextual decisions, but it requires accurate attributes, consistent policy administration, and strong testing. Incorrect or stale attributes can cause either unauthorized access or operational disruption.

In practice, organisations often combine models. A user may need an appropriate role, a compliant device, a permitted location, and a resource classification before access is allowed.

4. Privileged Access Management

Privileged accounts can change security settings, create identities, alter databases, install software, or disable controls. They are therefore high-value targets. Privileged access management (PAM) limits, controls, monitors, and records privileged activity.

PAM practices include:

• separate administrative and ordinary user accounts;
• just-in-time or time-limited elevation;
• approval for sensitive operations;
• secure storage and rotation of privileged credentials;
• session recording where lawful and proportionate;
• command logging and alerting;
• emergency “break-glass” access with retrospective review;
• removal of standing administrative rights.

PAM should cover human administrators, service accounts, cloud roles, application identities, and automation pipelines. Service accounts require named ownership, limited permissions, rotation, monitoring, and a documented purpose. A password vault alone is not a complete PAM programme if users retain unrestricted standing privilege.

5. Single Sign-On and Federation

Single sign-on (SSO) allows a user to authenticate once and access multiple authorized services without separately entering credentials for each service. SSO improves usability and can reduce password reuse, but it creates concentration risk: compromise of the central identity provider may affect many applications.

SSO should therefore be protected with strong MFA, risk-based detection, resilient recovery, administrative separation, and carefully controlled application integration.

Federation

Identity federation allows one organisation or service to rely on authentication performed by another trusted identity provider. The identity provider (IdP) authenticates the user and issues an assertion or token. The relying party or service provider (SP) validates the assertion and applies its own authorization policy.

Common technologies include:

• SAML: widely used for browser-based enterprise federation;
• OAuth 2.0: an authorization framework for delegated access to resources;
• OpenID Connect: an authentication and identity layer built on OAuth 2.0;
• SCIM: a protocol used to provision and manage identity records across services.

OAuth 2.0 should not be described as an authentication protocol by itself. OpenID Connect adds identity claims and an ID token for authentication use cases. Federation requires secure redirect handling, audience and issuer validation, signature verification, appropriate token lifetimes, replay protection, and careful scope management.

6. Identity Lifecycle Management

Identity lifecycle management governs identities from creation through modification to retirement. The common operational model is joiner–mover–leaver.

Joiners

When a person joins, HR or an authoritative source should trigger identity creation. The organisation verifies identity, assigns a unique identifier, enrols approved authentication methods, assigns an initial role, and provides only the access required for the person’s duties.

Movers

When a person changes department, location, responsibilities, or employment status, access must be recalculated. A common failure is additive provisioning: new permissions are added while old permissions remain. Mover processes should remove obsolete access, reassess separation-of-duties conflicts, and require approval for sensitive privileges.

Leavers

When employment or a contract ends, access should be disabled promptly and consistently across directories, applications, VPNs, cloud services, privileged systems, tokens, devices, and physical access systems. The timing should reflect risk and policy. Ownership of files, service accounts, certificates, and business processes must also be transferred safely.

Governance and review

Lifecycle governance requires authoritative identity data, clear ownership, reconciliation between directories and applications, access certifications, exception management, and evidence of completed actions. Periodic access reviews should ask whether access is still needed, appropriate, and being used—not merely whether a manager recognizes the person’s name.

7. Accountability, Logging, and Access Reviews

IAM logs should record events such as successful and failed authentication, MFA changes, password resets, privilege elevation, policy changes, account creation, account disabling, and sensitive data access. Useful records include the identity, time, source, target, action, result, and relevant device or session information.

Logs must be protected against unauthorized alteration and should use synchronized clocks. Retention should reflect investigation requirements, legal obligations, storage cost, and privacy principles. Excessive collection can itself create privacy and breach risk.

Access reviews should be risk-based. Administrators, service accounts, financial systems, production environments, and sensitive personal data generally require more frequent and detailed review than low-risk resources. Reviewers should have enough context to make a meaningful decision and should not approve their own access.

8. Applied Case: Northbridge Health Services

The following is an illustrative case.

Background

Northbridge Health Services operates clinics, laboratories, and a cloud-based patient-record platform. Staff previously used separate passwords for email, clinical applications, and laboratory systems. Contractors retained access after projects ended, and several administrators shared a database account.

Problem

An attacker obtained a contractor’s reused password through credential stuffing. The account had access to patient scheduling and a reporting portal. Investigators could not determine which administrator had changed a database record because the shared account produced a single ambiguous log identity.

Analysis

The incident revealed failures in authentication, authorization, lifecycle management, and accountability. Password reuse was not adequately addressed. Contractor offboarding was manual and inconsistent. Privileged access was standing and shared. The organisation also lacked reliable correlation between identity, device, and application events.

Approach

Northbridge implemented the following measures:

1. a central identity provider with phishing-resistant MFA for administrators and MFA for all staff;
2. SSO for approved clinical and corporate applications;
3. automated joiner–mover–leaver integration with the HR system;
4. RBAC for standard clinical roles, supplemented by ABAC rules for patient assignment and device posture;
5. a PAM vault with named administrator accounts, time-limited elevation, and session logging;
6. password-manager deployment and screening against compromised passwords;
7. quarterly access certification for sensitive systems;
8. centralized logs with synchronized time and alerts for unusual authentication activity.

Outcome

The organisation reduced standing privilege, improved auditability, and shortened contractor deprovisioning time. Clinical users reported fewer passwords to remember. The programme did not remove all risk: phishing, compromised endpoints, incorrect role assignments, and availability failures remained possible. Northbridge therefore retained incident-response procedures, emergency access controls, and regular control testing.

Learning points

The case demonstrates that IAM is a system of interdependent controls. SSO without MFA can centralize risk. RBAC without lifecycle governance creates stale permissions. MFA without recovery controls can cause unsafe workarounds. Logging without unique identities cannot provide reliable accountability.

9. Implementation Guidance and Common Limitations

An IAM implementation should begin with an inventory of identities, applications, privileged accounts, data owners, and trust relationships. The organisation should identify authoritative sources, define ownership, classify resources, and prioritize high-impact systems.

A practical sequence is:

1. establish governance, owners, and risk priorities;
2. eliminate shared accounts where possible;
3. centralize identity records and enforce unique identities;
4. deploy strong MFA, beginning with administrators and remote access;
5. define and test roles and attributes;
6. automate lifecycle events;
7. implement PAM for privileged and service identities;
8. integrate SSO and federation securely;
9. centralize monitoring and conduct access reviews;
10. measure outcomes and improve continuously.

Important metrics may include the percentage of privileged accounts protected by MFA, time to disable leavers, number of orphaned accounts, percentage of applications integrated with SSO, age of unresolved access-review exceptions, and the proportion of privileged activity performed through approved workflows. Metrics should be interpreted carefully: a high SSO adoption rate does not prove that authorization is correct.

IAM also has limitations. Identity providers can become critical points of failure. Automated provisioning can propagate incorrect HR data at scale. Biometric systems can create privacy and fairness concerns. Conditional access can block legitimate users. Federation introduces trust dependencies between organisations. Security controls must therefore be resilient, tested, explainable, and supported by recovery procedures.

10. Ethical, Legal, and Contemporary Issues

IAM decisions affect employment, privacy, safety, and access to essential services. Organisations should collect only necessary identity and biometric information, provide transparency, restrict administrative access, and retain data only as long as justified. Access decisions should not discriminate unfairly or rely blindly on opaque risk scores.

Regulatory requirements vary by jurisdiction and sector, but common expectations include access control, auditability, data protection, breach response, segregation of duties, and documented governance. Organisations should map IAM controls to applicable laws, contracts, and standards rather than treating a certification as proof of complete security.

Artificial intelligence is increasingly used for anomaly detection, adaptive authentication, identity proofing, and access-review prioritization. AI can help identify unusual travel, impossible login sequences, compromised credentials, or anomalous privilege use. However, AI outputs can be inaccurate, biased, difficult to explain, or vulnerable to manipulation. Human review, testing, data governance, and an appeal or override process remain important for consequential decisions.

Contemporary IAM is moving toward zero-trust architectures, in which no user or device receives implicit trust merely because it is inside a network. Access is evaluated continuously using identity, device state, resource sensitivity, session risk, and policy. Passkeys, decentralized identity research, workload identity, and machine-to-machine authorization are also developing areas. Regardless of technology, the fundamental requirements remain least privilege, reliable authentication, controlled authorization, and accountability.

Chapter Summary

Identity and access management protects systems by managing identities, verifying claims, deciding permissions, enforcing policy, and recording activity. Identification claims an identity; authentication verifies it; authorization determines permitted actions; and accountability connects activity to responsible actors.

Strong IAM uses unique identities, secure password storage, MFA, carefully governed biometrics, least privilege, separation of duties, and default-deny policies. RBAC organizes access around job functions, while ABAC evaluates subject, resource, action, and environmental attributes. PAM controls high-risk administrative and service identities. SSO improves usability, while federation allows trusted identity providers and services to work together through technologies such as SAML, OAuth 2.0, OpenID Connect, and SCIM.

Identity lifecycle management must handle joiners, movers, and leavers, supported by authoritative records, automation, access reviews, and exception management. Effective IAM is not a single product; it is a continuing combination of architecture, policy, technology, governance, privacy protection, and operational discipline.

Key Terms

Accountability: The ability to associate actions with responsible identities and evidence.

Authentication: Verification of a claimed identity.

Authorization: Determination of what an authenticated subject may do.

Attribute-based access control (ABAC): Access control based on attributes and contextual conditions.

Biometric authentication: Authentication using measurable biological or behavioural characteristics.

Federation: A trust arrangement in which one identity provider authenticates users for another service.

Identity: A representation of a subject in an information system.

Identity provider (IdP): A service that authenticates users and issues identity assertions or tokens.

Joiner–mover–leaver: A lifecycle model for creating, modifying, and disabling identities.

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

Multifactor authentication: Authentication using two or more independent factor categories.

Non-repudiation: Evidence that makes denial of an action difficult.

Privileged access management: Controls for administering, monitoring, and limiting high-risk access.

Role-based access control (RBAC): Access control based on assigned job or system roles.

Salt: A unique random value added to a password before hashing.

Single sign-on (SSO): One authentication event enabling access to multiple authorized services.

Subject: A user, device, process, or service requesting access.

Zero trust: An approach that avoids implicit trust and evaluates access using explicit, continuously relevant signals.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accountability.
2. Why should password databases use salts and slow password-specific hashing functions?
3. What makes two authentication methods genuine MFA rather than two instances of one factor?
4. State two differences between RBAC and ABAC.
5. Why do shared administrator accounts weaken accountability?

Long Answer Questions

1. Explain the principles of least privilege, need to know, separation of duties, and default deny, using organisational examples.
2. Describe how a secure identity lifecycle process should manage joiners, movers, and leavers.
3. Compare passwords, authenticator applications, hardware security keys, and biometrics, including their principal risks.
4. Explain how SSO and federation operate, and discuss the security controls required for a central identity provider.
5. Describe a PAM programme for administrators, service accounts, and emergency access.

Analytical / Application Questions

1. A contractor changes departments but retains permissions from the former department. Analyse the lifecycle and authorization failures and propose corrective controls.
2. A company wants to use facial recognition as the only method for accessing a sensitive system. Evaluate the security, privacy, accessibility, and governance implications and recommend an alternative design.
3. Design an IAM architecture for a medium-sized organisation with cloud applications, remote workers, contractors, and sensitive financial data. Justify your choices of MFA, RBAC or ABAC, SSO, PAM, lifecycle automation, logging, and access review.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may do, while authorization identifies the user.

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

C. Authentication records events, while authorization encrypts passwords.

D. Authentication creates roles, while authorization stores biometric templates.

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

Question 2

Which combination is an example of multifactor authentication?

A. Password and PIN

B. Fingerprint and facial recognition

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 make passwords easier to remember

B. To provide a second authentication factor

C. To prevent identical passwords from producing identical stored values

D. To replace the need for hashing

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

Question 4

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

A. RBAC

B. ABAC

C. Discretionary encryption

D. Biometric access control

Correct Answer: A. RBAC

Question 5

Which practice is most directly associated with privileged access management?

A. Allowing all employees permanent administrator rights

B. Using shared administrator accounts for convenience

C. Providing time-limited elevation and recording privileged sessions

D. Disabling all audit logs

Correct Answer: C. Providing time-limited elevation and recording privileged sessions

Question 6

What is a major risk of single sign-on?

A. Users must remember more passwords

B. Compromise of the central identity provider can affect many services

C. Applications can no longer use authorization policies

D. It prevents the use of MFA

Correct Answer: B. Compromise of the central identity provider can affect many services

Question 7

In an identity lifecycle, which event is a ‘mover’ event?

A. A new employee receives an initial account

B. A contractor’s account is disabled after the contract ends

C. An employee changes departments and requires revised access

D. A user forgets a password

Correct Answer: C. An employee changes departments and requires revised access

Question 8

Which statement about OAuth 2.0 is most accurate?

A. It is exclusively a biometric standard

B. It is an authorization framework and is not, by itself, an authentication protocol

C. It is a password-hashing algorithm

D. It is a hardware security key format

Correct Answer: B. It is an authorization framework and is not, by itself, an authentication protocol

Question 9

What is the principal security weakness of a shared administrator account?

A. It prevents all administrative activity

B. It makes individual accountability difficult

C. It automatically grants least privilege

D. It requires federation

Correct Answer: B. It makes individual accountability difficult

Question 10

Which condition best illustrates ABAC?

A. Every employee in one job title receives identical permissions regardless of context

B. A user is allowed access only when their role, device posture, resource, and purpose satisfy policy

C. A resource owner manually shares a file with another user

D. All users receive administrator privileges during business hours

Correct Answer: B. A user is allowed access only when their role, device posture, resource, and purpose satisfy policy