Identity and Access Management

Introduction and Context

Identity and Access Management (IAM) is the discipline of ensuring that the right person, device, service, or process receives the right access to the right resource for the right period and for an authorised purpose. It is a central control in cyber security because most attacks ultimately seek to misuse identity: stealing credentials, impersonating users, abusing privileges, or retaining access after a role has ended.

IAM is broader than a login screen. It includes identity proofing, account creation, authentication, authorisation, privilege management, access review, logging, federation, and account removal. A mature IAM programme supports confidentiality, integrity, availability, privacy, regulatory compliance, and operational accountability.

The fundamental access decision can be expressed as:

Here, subject is the user, device, or service requesting access; resource is the protected object; action is the requested operation; context includes time, location, device posture, and risk; and policy defines the conditions under which access is allowed. The expression is conceptual rather than a numerical equation.

Learning Objectives

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

1. Distinguish identification, authentication, authorisation, and accountability.
2. Explain authentication factors, multifactor authentication, passwordless authentication, and biometrics.
3. Compare role-based access control, attribute-based access control, and discretionary or mandatory models.
4. Design practical privileged access management and identity lifecycle controls.
5. Explain federation using standards such as SAML, OAuth 2.0, and OpenID Connect.
6. Evaluate IAM risks, governance requirements, privacy implications, and implementation trade-offs.
7. Apply IAM principles to a realistic organisational case.

1. The Identity and Access Chain

IAM is commonly understood through four related functions.

Identification alone provides no assurance. Authentication establishes confidence that the subject controls the claimed identity. Authorisation should then apply least privilege: a subject receives only the access necessary for legitimate work. Accountability makes actions traceable and supports detection, investigation, and non-repudiation. Strictly, logging supports accountability; it cannot guarantee that an action was performed by the genuine person if an account was compromised.

IAM subjects include employees, contractors, customers, administrators, applications, APIs, servers, containers, and Internet of Things devices. Modern environments therefore require both human and machine identities. Service accounts and application identities must be governed as carefully as employee accounts.

Identity, account, credential, and entitlement

An identity is a representation of an entity in a system. An account is a system record associated with that identity. A credential is evidence used during authentication, such as a password, cryptographic private key, or token. An entitlement is a permission or membership granted to an account. Confusing these concepts causes weak designs; deleting a credential, for example, does not necessarily remove an entitlement or disable an account.

2. Authentication Factors and Assurance

Authentication factors are grouped into categories:

• Knowledge: something the subject knows, such as a password or PIN.
• Possession: something the subject has, such as a hardware security key or authenticator device.
• Inherence: something the subject is, such as a fingerprint or facial characteristic.
• Location or network context: where the request originates.
• Behaviour: a behavioural pattern, such as typing rhythm.

A factor is not simply a separate step. Two passwords are generally two knowledge elements, not multifactor authentication. Multifactor authentication (MFA) requires evidence from at least two distinct factor categories. MFA reduces the impact of password theft, although phishing-resistant MFA is stronger than methods that can be relayed or socially engineered.

Authentication assurance depends on the enrolment process, factor strength, resistance to replay, recovery procedures, device security, and fraud monitoring. A highly secure factor can be undermined by a weak account-recovery process.

Passwords

Passwords remain common because they are inexpensive and widely supported. Effective password controls include salted, adaptive password hashing; rate limiting; breached-password screening; secure recovery; and prevention of plaintext storage. Password databases should store a password-derived verifier, not the password itself. Salts should be unique and non-secret, while the hashing work factor should be selected and periodically reviewed for the organisation’s hardware and risk.

Complexity rules alone are not sufficient. Long, unique passwords or passphrases, combined with password managers and MFA, generally provide better protection than short passwords with arbitrary composition rules. Passwords must never be transmitted or stored in plaintext.

One-time passwords and push authentication

Time-based one-time passwords (TOTP) generate codes from a shared secret and time. They are stronger than passwords alone but remain vulnerable to phishing because a user may disclose the current code to an attacker. Push notifications improve usability but can suffer from notification fatigue, in which an attacker repeatedly sends prompts until the user accepts one. Number matching, device binding, rate limits, and user education reduce this risk.

Passwordless authentication

Passwordless methods replace memorised secrets with stronger credentials, commonly public-key cryptography. During enrolment, a device generates a key pair. The private key remains protected by the authenticator, while the public key is registered with the service. During login, the service sends a challenge; the authenticator signs it after local user verification, such as a PIN or biometric. The service validates the signature using the public key.

The private key is not sent to the service, and a properly designed protocol binds the authentication to the legitimate website or service, reducing phishing and replay. FIDO2 and WebAuthn are important examples. Recovery remains a design challenge: backup authenticators, supervised re-enrolment, and carefully controlled support processes are preferable to insecure fallback questions.

Biometrics

Biometrics use measurable human characteristics. They offer convenience and can unlock a local device or cryptographic key. However, biometric data is sensitive: unlike a password, a fingerprint or face cannot be changed easily after compromise. Biometric matching is probabilistic, producing false acceptance and false rejection.

Important measures include:

• False Acceptance Rate (FAR): the proportion of unauthorised attempts incorrectly accepted.
• False Rejection Rate (FRR): the proportion of legitimate attempts incorrectly rejected.
• Equal Error Rate (EER): the operating point at which FAR and FRR are approximately equal.

These measures depend on the algorithm, threshold, population, environment, and quality of samples. Biometrics should normally be used as a local verification factor rather than as a central database of reusable biometric secrets. Organisations must address consent, proportionality, accessibility, demographic performance differences, retention, and lawful processing.

3. Authorisation Models

Authentication answers “Who are you?” Authorisation answers “What may you do?” Authorisation should be evaluated on every relevant request, not only at initial login. A secure design uses deny-by-default, least privilege, separation of duties, and explicit handling of administrative functions.

Role-Based Access Control

Role-Based Access Control (RBAC) assigns permissions to roles and users to roles. For example, the role Accounts Payable Clerk may create invoices, while Accounts Payable Manager may approve them. RBAC is understandable and administratively efficient where job responsibilities are stable.

RBAC can be represented as a relation between users, roles, and permissions. A user receives a permission when the user is assigned a role that contains it. Role hierarchies allow senior roles to inherit permissions from junior roles, but inheritance must be reviewed carefully. Excessive roles create “role explosion”, while overly broad roles create excessive privilege.

Constraints improve RBAC. A mutually exclusive constraint might prevent one user from both creating and approving the same payment. Cardinality constraints may limit the number of users assigned to a sensitive role.

Attribute-Based Access Control

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

ABAC is expressive and well suited to cloud, zero-trust, and dynamic environments. It is also harder to design, test, explain, and audit. Attribute quality is critical: an inaccurate department, device status, or data classification can produce an incorrect decision.

Other models

Discretionary Access Control (DAC) allows resource owners to grant permissions. It is flexible but can lead to uncontrolled sharing. Mandatory Access Control (MAC) applies centrally defined classifications and clearances; it is useful in high-assurance environments but can be rigid. Rule-based access control applies explicit conditions, such as allowing a network connection only during approved maintenance windows.

A practical organisation may combine models: RBAC for baseline employment permissions, ABAC for contextual decisions, and MAC-like classifications for highly sensitive information.

4. Privileged Access Management

Privileged accounts can change security controls, access sensitive data, create identities, or disable monitoring. Examples include domain administrators, cloud root users, database administrators, security engineers, and emergency “break-glass” accounts. Because compromise of one privileged account can affect an entire environment, privileged access management (PAM) is a high-priority control.

A mature PAM programme includes:

1. Separate administrative accounts from ordinary productivity accounts.
2. Eliminate shared administrator accounts where possible.
3. Use just-in-time or time-limited elevation.
4. Require strong, preferably phishing-resistant MFA.
5. Store secrets in a controlled vault and rotate them automatically.
6. Record privileged sessions and commands where lawful and proportionate.
7. Apply approval, ticket, or dual-control requirements to high-risk actions.
8. Monitor unusual administrative behaviour.
9. Maintain tested emergency access with post-event review.
10. Review privileged memberships regularly.

Standing privilege is dangerous because it provides an attacker with a persistent opportunity. Just-in-time access reduces exposure by granting privilege only for an approved task and period. However, emergency procedures must remain usable; controls that prevent legitimate recovery can create availability risks.

5. Federation and Single Sign-On

Federation allows one identity provider (IdP) to establish identity information for a relying application or service provider (SP). Single Sign-On (SSO) lets a user authenticate once and access multiple permitted services. SSO improves usability and centralises policy, but it also increases the impact of IdP compromise.

Common technologies include:

• SAML: an XML-based framework widely used for enterprise browser SSO.
• OAuth 2.0: an authorisation framework allowing a client to obtain delegated access to a resource; OAuth is not, by itself, an authentication protocol.
• OpenID Connect: an identity layer built on OAuth 2.0 that provides authentication information through an ID token.
• SCIM: a protocol used to provision and deprovision identities and groups between systems.

Tokens must be audience-restricted, short-lived where appropriate, protected in transit, and validated for issuer, signature, expiry, audience, and relevant claims. Redirect URIs, client secrets, consent screens, and scopes require careful configuration. Overly broad scopes violate least privilege.

Federation creates trust relationships. Before accepting assertions or tokens, an organisation should assess the provider, signing-key management, incident notification, availability, privacy practices, account recovery, and termination process. SSO does not remove the need for authorisation inside each application.

6. Identity Lifecycle Management

Identity lifecycle management controls an identity from creation to retirement. The principal stages are joiner, mover, and leaver processes.

Joiners

A joiner process should begin with an authoritative source, normally a human-resources or supplier-management record. Identity proofing, approval, unique identifier allocation, role assignment, device issuance, and MFA enrolment should be completed before access is granted. The process should distinguish employees, contractors, students, partners, and service identities.

Movers

When a person changes department, location, duties, or employment status, old access must be removed and new access granted according to the revised role. A common failure is additive provisioning: new permissions are added while obsolete permissions remain. Changes should therefore trigger recalculation or review of entitlements.

Leavers

Termination should disable interactive access promptly, revoke sessions and tokens, recover devices, rotate shared secrets, transfer business records appropriately, and preserve evidence where required. The timing should reflect risk and employment policy. Privileged or high-risk departures may require immediate action coordinated with legal and human-resources teams.

Governance and access reviews

Access certifications require managers or data owners to confirm that permissions remain necessary. Reviews should be risk-based rather than superficial. Evidence should show who reviewed access, what was reviewed, decisions made, exceptions, and remediation dates. Orphaned accounts, dormant accounts, excessive privileges, and accounts without owners are important indicators of control weakness.

7. Zero Trust and Continuous Evaluation

Zero trust is a security approach in which no user, device, or network location is automatically trusted. Access is evaluated using identity, device health, resource sensitivity, request context, and current risk. The approach is commonly summarised as verify explicitly, use least privilege, and assume breach.

Zero trust does not mean that trust is literally zero or that every request must be manually approved. It means that access decisions should be evidence-based, continuously monitored, and capable of changing when conditions change. For example, a session may be restricted if a device becomes non-compliant, a token is replayed, or behaviour indicates account takeover.

Useful telemetry includes authentication events, device posture, network signals, privilege changes, data access, impossible-travel indicators, and endpoint detections. Privacy and proportionality must constrain monitoring; collecting more data is not automatically better security.

8. Accountability, Logging, and Metrics

Accountability requires reliable records linking actions to identities and time. Logs should include subject identifier, event type, target resource, result, timestamp, source, authentication method, and correlation identifier. Clocks should be synchronised sufficiently for investigations. Logs must be protected against unauthorised modification and retained according to legal, operational, and privacy requirements.

Useful IAM metrics include MFA coverage, percentage of privileged accounts using separate identities, time to disable leavers, number of orphaned accounts, access-review completion, excessive-permission findings, and authentication anomaly rates. Metrics should measure risk reduction rather than encourage gaming. For example, “100% of reviews completed” is weak if reviews are completed without meaningful examination.

9. Applied Case: Northbridge Health Services

This is an illustrative fictional case.

Background

Northbridge Health Services operates clinics, laboratories, and a patient portal. Employees use several applications, including electronic health records, payroll, laboratory systems, and cloud collaboration tools. Contractors and visiting clinicians require temporary access.

Problem

An audit found shared administrator accounts, delayed removal of leavers, password reuse, inconsistent MFA, and excessive access for reception staff. A former contractor’s account remained active for three months. The organisation also used email links for password recovery without adequately verifying identity.

Analysis

The weaknesses were not caused by one technology alone. The organisation lacked an authoritative identity source, a consistent joiner-mover-leaver process, application ownership, and a clear access model. Shared accounts prevented reliable accountability. The patient portal and clinical systems also had different authentication policies, creating uneven assurance.

Approach and solution

Northbridge established an identity governance process linked to its human-resources and contractor systems. Each person received a unique identity, while service accounts were separately registered with named owners. Baseline access was assigned through RBAC, including distinct roles for reception, clinicians, laboratory staff, and billing. ABAC conditions restricted patient-record access to assigned care teams and approved purposes.

The organisation deployed phishing-resistant security keys for administrators and high-risk users, with authenticator applications as a transitional method. Privileged accounts were separated from ordinary accounts, placed in a vault, and granted for approved periods. SSO was introduced through a federated identity provider, but each application retained resource-level authorisation. SCIM-style provisioning automated account changes where supported.

Access reviews were assigned to managers and data owners. Leaver events disabled accounts, revoked sessions, recovered devices, and rotated relevant secrets. Emergency accounts were protected by separate controls and reviewed after use. Audit logs were centralised and monitored for unusual privilege changes and impossible travel.

Outcome

The organisation reduced standing privilege, improved termination response, and gained clearer evidence of who accessed patient information. Users experienced fewer passwords, although training and recovery procedures were required. The programme also identified a limitation: automation could not correct inaccurate HR records. Governance and data quality remained essential.

Learning points

1. IAM is a socio-technical process, not merely a product installation.
2. Strong authentication cannot compensate for excessive authorisation.
3. Automation is valuable only when authoritative identity data is accurate.
4. Shared accounts undermine accountability and should be eliminated where possible.
5. Clinical and privacy contexts require purpose limitation, proportionality, and careful audit design.

10. Challenges, Ethics, and Governance

IAM programmes face technical debt, legacy applications, inconsistent directories, fragmented ownership, poor data quality, and user resistance. Excessive centralisation may create a single point of failure, while excessive decentralisation creates policy inconsistency. Availability planning should include redundant identity services, carefully designed offline or emergency procedures, and tested recovery.

Ethically, organisations must balance security with autonomy, accessibility, privacy, and fairness. Biometrics may disadvantage some users or create unacceptable surveillance risks. Behavioural monitoring can reveal sensitive personal information. Policies should specify purpose, minimisation, retention, access to monitoring data, appeal mechanisms, and independent oversight.

Regulatory requirements vary by jurisdiction and sector, but common expectations include least privilege, data protection, auditability, breach response, retention control, and demonstrable governance. IAM controls should be mapped to applicable laws, contractual duties, and recognised security frameworks rather than treated as a compliance checklist.

Artificial intelligence can assist anomaly detection, identity-risk scoring, access recommendation, and role mining. It should not be trusted as an unquestionable authority. Models may reproduce biased historical decisions, generate false positives, or infer sensitive characteristics. Human oversight, explainability appropriate to the decision, secure training data, monitoring, and an appeal process are necessary for high-impact access decisions.

11. Implementation Best Practices

A practical implementation sequence is:

1. Inventory identities, accounts, applications, privileged paths, and data owners.
2. Establish authoritative sources and unique identity ownership.
3. Define access policy, classification, segregation of duties, and exception processes.
4. Protect administrators and high-risk users with phishing-resistant MFA.
5. Implement joiner-mover-leaver automation and rapid leaver disablement.
6. Apply RBAC for stable baseline permissions and ABAC where context matters.
7. Remove shared accounts and control service identities.
8. Deploy PAM for privileged credentials and just-in-time access.
9. Integrate federation carefully and validate tokens and trust relationships.
10. Centralise protected logs and monitor identity threats.
11. Conduct meaningful, risk-based access reviews.
12. Test recovery, emergency access, phishing resistance, and failure scenarios.

The best design is not necessarily the most complex. It is the design that provides appropriate assurance, remains usable, can be governed, and produces evidence that controls operate effectively.

Chapter Summary

Identity and Access Management protects digital resources by connecting identification, authentication, authorisation, and accountability. Authentication factors include knowledge, possession, and inherence; MFA requires distinct factor categories, while passwordless public-key methods can provide strong phishing resistance. Biometrics improve convenience but introduce privacy, probabilistic matching, and irreversibility concerns.

RBAC provides manageable role-based permissions, whereas ABAC supports dynamic decisions using subject, resource, action, and environmental attributes. Privileged access management limits the consequences of administrator compromise through separation, vaulting, just-in-time elevation, monitoring, and review. Federation and SSO improve usability but create trust dependencies that require secure token validation and careful lifecycle management.

Effective IAM depends on accurate joiner-mover-leaver processes, authoritative identity data, least privilege, separation of duties, protected logging, access certification, and continuous risk evaluation. Governance must address privacy, accessibility, ethics, legal duties, and the limitations of automation and AI. IAM is therefore both a technical architecture and an organisational control system.

Key Terms

Accountability: The ability to attribute actions to an identity through controls and evidence.

Authentication: Verification of a claimed identity.

Authorisation: Determination of which actions a subject may perform.

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

Biometrics: Authentication using measurable human characteristics.

Credential: Evidence used to authenticate an identity.

Entitlement: A granted permission or membership.

Federation: A trust arrangement allowing one identity provider to support access to another service.

FAR: False Acceptance Rate; unauthorised attempts incorrectly accepted.

FRR: False Rejection Rate; legitimate attempts incorrectly rejected.

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

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

MFA: Authentication using evidence from at least two distinct factor categories.

PAM: Controls for managing privileged accounts, credentials, sessions, and elevation.

Passwordless authentication: Authentication that does not rely on a memorised password, often using public-key credentials.

RBAC: Access control based on roles and their associated permissions.

SCIM: A protocol for exchanging identity and group provisioning information.

Single Sign-On: Access to multiple services after one authentication event.

Zero trust: An approach that verifies access explicitly and does not grant implicit trust based on location.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorisation, and accountability.
2. Why are two passwords not normally considered multifactor authentication?
3. State two advantages and two risks of single sign-on.
4. What is the purpose of just-in-time privileged access?
5. Explain the difference between RBAC and ABAC.

Long Answer Questions

1. Explain how passwordless public-key authentication works and why it can resist phishing better than passwords and TOTP codes.
2. Discuss the design of a complete joiner-mover-leaver lifecycle process.
3. Compare RBAC, ABAC, DAC, and MAC, including appropriate organisational contexts for each.
4. Describe a privileged access management programme and explain how it supports least privilege and accountability.
5. Analyse the privacy, ethical, and governance issues associated with biometric authentication and identity monitoring.

Analytical / Application Questions

1. A contractor changes from laboratory support to reception work but retains laboratory database access. Identify the lifecycle and authorisation failures, then propose corrective controls.
2. An organisation has MFA based only on SMS and frequent push-notification fatigue. Design a phased plan to improve authentication assurance while maintaining recovery and accessibility.
3. Design an IAM policy for a cloud patient-record system using RBAC, ABAC, PAM, federation, logging, and periodic access review. Explain the assumptions and trade-offs in your design.

Multiple Choice Questions with Answers

Question 1

Which activity verifies that a subject controls a claimed identity?

A. Identification

B. Authentication

C. Authorisation

D. Accountability

Correct Answer: B. Authentication

Question 2

Which combination is an example of multifactor authentication?

A. Password and PIN

B. Two different passwords

C. Password and hardware security key

D. Username and email address

Correct Answer: C. Password and hardware security key

Question 3

What is a major characteristic of ABAC?

A. It grants every user the same permissions

B. It evaluates attributes and context in an access decision

C. It prohibits all role assignments

D. It replaces authentication entirely

Correct Answer: B. It evaluates attributes and context in an access decision

Question 4

Which control most directly reduces standing administrator privilege?

A. Longer usernames

B. Just-in-time elevation

C. Publicly shared passwords

D. Disabling audit logs

Correct Answer: B. Just-in-time elevation

Question 5

What is OAuth 2.0 primarily designed to provide?

A. Delegated authorisation

B. Password hashing

C. Biometric matching

D. Physical access control

Correct Answer: A. Delegated authorisation

Question 6

Which event should normally trigger removal of obsolete permissions?

A. A user changes job role

B. A user changes screen resolution

C. A server changes its IP address

D. A user opens a help page

Correct Answer: A. A user changes job role

Question 7

Why are biometrics not equivalent to ordinary passwords in recovery design?

A. Biometrics are always transmitted in plaintext

B. Biometric characteristics cannot easily be changed after compromise

C. Biometrics cannot be used on mobile devices

D. Biometrics provide no authentication evidence

Correct Answer: B. Biometric characteristics cannot easily be changed after compromise

Question 8

Which principle means that access is granted only when necessary for an authorised task?

A. Least privilege

B. Open trust

C. Maximum availability

D. Role explosion

Correct Answer: A. Least privilege

Question 9

Which protocol is commonly associated with exchanging identity provisioning information between systems?

A. SCIM

B. FTP

C. SMTP

D. ICMP

Correct Answer: A. SCIM

Question 10

What is the principal purpose of IAM audit logs?

A. To increase password length automatically

B. To attribute and investigate identity-related actions

C. To eliminate the need for authorisation

D. To make all resources publicly accessible

Correct Answer: B. To attribute and investigate identity-related actions