Identity, Authentication and Access Control

Introduction

Identity is the security property that answers “who or what is requesting access?” Authentication establishes confidence in that identity; authorization determines what the authenticated subject may do; accounting records what occurred. Together, these functions form the identity and access management (IAM) lifecycle. In contemporary environments, identity is no longer confined to a corporate directory. Users, service accounts, devices, workloads, APIs, applications, and automated agents all request access across cloud, mobile, operational-technology, and partner environments.

Identity-centric security is therefore a central component of zero-trust architecture. A network location is not treated as sufficient evidence of trust. Each request is evaluated using identity, device posture, resource sensitivity, environmental context, and policy. Effective IAM reduces unauthorized access, limits the impact of compromised accounts, supports regulatory accountability, and improves operational efficiency.

Learning Objectives

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

1. Distinguish identification, authentication, authorization, and accounting.
2. Evaluate authentication factors, MFA, biometrics, and passwordless methods.
3. Explain RBAC, ABAC, privileged access management, and identity-centric security decisions.
4. Compare OAuth 2.0, OpenID Connect, SAML, and Kerberos.
5. Design controls for lifecycle management, federation, auditing, and privileged access.
6. Critically assess usability, privacy, interoperability, and governance risks.

The IAM Security Model

Identification, authentication, authorization, and accounting

Identification is the claim of an identity, such as a username, certificate subject, or workload identifier. Identification alone provides no proof. Authentication verifies the claim using evidence. Authorization evaluates a policy to decide whether an authenticated subject may perform an action on a resource. Accounting, also called auditing or accountability, records relevant events such as login, privilege use, data access, and administrative change.

A useful abstraction is:

Here, Subject is a user, service, device, or workload; Action is an operation such as read or approve; Resource is the protected object; and Context includes time, location, device state, risk, and requested assurance. The expression is a policy model rather than a numerical equation. Its applicability depends on reliable identity evidence, complete policy definitions, and trustworthy contextual signals.

The security lifecycle normally includes identity proofing, account creation, authentication, authorization, monitoring, review, suspension, and deletion. Failure at any stage can create risk. For example, strong MFA cannot compensate for an account that remains active after an employee leaves.

Subjects, principals, credentials, and resources

A principal is an entity recognized by a security system. A principal may be a human user, application, device, container, service account, or robotic process. A credential is evidence used to authenticate a principal. An account is an administrative representation of a principal and may contain attributes, group memberships, credentials, and lifecycle status.

Resources include files, databases, APIs, cloud objects, physical facilities, cryptographic keys, and administrative functions. Security policies should specify not only who can access a resource, but also which actions are permitted, under what conditions, and for how long.

Authentication Factors and Assurance

Authentication factors are commonly classified as:

A factor is not simply a separate device or prompt. Two passwords are generally two instances of the same knowledge factor, not MFA. MFA requires evidence from at least two independent factor categories. Independence matters because compromise of one attack channel should not automatically compromise the other.

Authentication assurance depends on the quality of identity proofing, credential protection, protocol design, resistance to phishing, recovery procedures, and session management. A high-assurance system may require a verified identity, a phishing-resistant authenticator, device binding, and explicit transaction confirmation.

Passwords and credential protection

Passwords remain common because they are inexpensive and familiar, but they are vulnerable to phishing, password spraying, credential stuffing, malware, and reuse. Organizations should use long passwords or passphrases, screen new passwords against known-compromised lists, rate-limit attempts, provide secure recovery, and avoid arbitrary composition rules that encourage predictable substitutions.

Passwords must not be stored in plaintext. A verifier should use a deliberately slow, memory-hard password hashing function such as Argon2id, with a unique salt per password and parameters selected through current risk and performance testing. Encryption is not a substitute for password hashing: encryption is reversible with a key, whereas a password verifier should be computationally difficult to reverse.

MFA and phishing resistance

MFA substantially reduces the value of stolen passwords, but not all MFA is equally resistant to phishing. One-time codes entered into a fraudulent website can be relayed to an attacker. Push notifications can suffer from approval fatigue. Hardware-backed public-key authenticators, including FIDO2/WebAuthn, bind authentication to the legitimate relying-party origin and are therefore substantially more resistant to credential phishing.

MFA design must include enrollment, replacement, recovery, help-desk verification, and emergency access. Weak recovery can bypass strong primary authentication. High-risk actions may require step-up authentication, such as reauthentication before changing a payment beneficiary or exporting sensitive data.

Biometrics

Biometric systems compare a captured characteristic with a stored reference. They produce false acceptance and false rejection rather than absolute proof. If FAR is the false acceptance rate and FRR is the false rejection rate, changing the decision threshold usually creates a trade-off: reducing FAR often increases FRR. Biometric templates should be protected because, unlike passwords, fingerprints and facial features cannot easily be replaced. Local matching, template protection, liveness detection, consent, and alternative authentication channels are important safeguards.

Biometrics are best treated as an authentication factor, often unlocking a device-held cryptographic key, rather than as a secret transmitted to every service. Accuracy can vary across populations and operating conditions; therefore, organizations must test for performance differences and provide equitable alternatives.

Authorization Models

Access control principles

Authorization should follow least privilege, deny by default, separation of duties, need to know, and time limitation. Least privilege gives a subject only the permissions necessary for an approved task. Separation of duties prevents one person from completing a sensitive process alone, such as creating a supplier and approving payment.

Access control lists (ACLs) attach permissions to resources or identities. Capability systems instead provide unforgeable tokens representing authority. Both approaches can be effective, but large enterprises commonly combine directory groups, policy engines, resource labels, and application-level checks.

Role-Based Access Control

RBAC assigns permissions to roles and assigns users to roles. A role such as “claims assessor” may include permissions to read claim records and approve claims below a defined threshold. RBAC simplifies administration where job functions are stable and well understood.

Its limitations include role explosion, stale memberships, and difficulty representing contextual rules. A role should represent a business function, not merely a convenient collection of permissions. Role engineering requires ownership, approval, periodic review, and clear handling of temporary assignments.

Attribute-Based Access Control

ABAC evaluates attributes of the subject, resource, action, and environment. A policy might allow a clinician to read a patient record when the clinician is assigned to that patient, the purpose is treatment, the device is managed, and the session has adequate assurance.

ABAC is expressive and suitable for distributed, dynamic environments, but it depends on accurate attributes and policy governance. Poorly defined attributes, conflicting rules, excessive policy complexity, or missing logs can make decisions difficult to explain. A practical architecture often combines RBAC for stable job functions with ABAC for context and constraints.

Privileged Access Management

Privileged accounts can alter security controls, access sensitive data, or create other accounts. Privileged access management (PAM) reduces their risk through separate administrative identities, just-in-time elevation, approval workflows, credential vaulting, session recording, command monitoring, and automatic expiry.

Shared administrator accounts weaken accountability. Where technically unavoidable, organizations should use a controlled vault, checkout approval, individual attribution, strong logging, and rapid credential rotation. PAM is not merely a product; it is a governance process defining who may elevate, why, for how long, and subject to which review.

Federation and Identity Protocols

OAuth 2.0

OAuth 2.0 is an authorization framework for delegated access. A resource owner grants a client limited access through an authorization server, which issues an access token for a resource server. OAuth access tokens represent authorization; they do not, by themselves, provide a reliable identity assertion for the client application or end user.

The authorization-code flow with Proof Key for Code Exchange (PKCE) is widely recommended for public clients. Redirect URIs should be exact and registered, state should defend against request forgery, scopes should be minimal, tokens should be short-lived, and refresh-token protection should be carefully designed. Implicit and password-grant patterns are unsuitable for many modern deployments.

OpenID Connect

OpenID Connect (OIDC) adds an identity layer to OAuth 2.0. It provides an ID token, normally a signed JSON Web Token, containing claims about authentication and the subject. The client must validate the issuer, signature, audience, expiry, nonce, and relevant authentication claims. An access token should not be confused with an ID token: the former is intended for an API, while the latter is intended for the client relying party.

SAML

Security Assertion Markup Language (SAML), especially SAML 2.0, exchanges XML-based authentication and attribute assertions between an identity provider and a service provider. It remains common in enterprise web single sign-on. Trust depends on metadata, certificate management, audience restriction, time conditions, secure signature validation, and careful handling of assertion consumption endpoints. XML complexity and interoperability differences make robust library use and testing essential.

Kerberos

Kerberos is a ticket-based authentication protocol using a trusted Key Distribution Center (KDC). A client first obtains a ticket-granting ticket and then requests a service ticket for a particular service. The service verifies the ticket without receiving the user’s password. Kerberos supports mutual authentication and single sign-on within a managed realm.

Its security depends on KDC protection, synchronized clocks, secure key management, correct service principals, and careful delegation controls. Compromise of a KDC is especially serious because it can affect the entire realm. Kerberos is powerful in controlled domains but is not a universal replacement for internet federation protocols.

Passwordless and Workload Identity

Passwordless authentication usually relies on a public-private key pair. The private key remains in a protected authenticator, while the public key is registered with the service. During authentication, the service sends a challenge; the authenticator signs it after verifying user presence or verification. The service validates the signature using the stored public key.

This design avoids reusable shared secrets and can resist phishing when the authenticator checks the relying-party origin. Recovery, device loss, account portability, accessibility, and enterprise lifecycle management remain important design issues.

Workload identity is equally important. Services should use short-lived, narrowly scoped credentials, workload-attested identities, mutual TLS where appropriate, and automated rotation. Long-lived static cloud keys embedded in source code are a major risk. Service-to-service authorization should identify the workload, validate the intended audience, and enforce least privilege just as human access does.

Identity-Centric Security Decisions

A zero-trust decision commonly involves a policy enforcement point, policy decision point, identity provider, device-management system, risk engine, and protected resource. The decision may consider:

• authenticated identity and assurance level;
• role, department, employment status, and purpose;
• device ownership, patch state, encryption, and compromise indicators;
• resource classification and requested action;
• network and geographic signals;
• time, transaction value, and behavioural anomalies;
• previous activity and risk intelligence.

Contextual signals are not infallible. Location may be masked, device posture may be stale, and behavioural models may discriminate or generate false positives. High-impact decisions should be explainable, reviewable, and supported by an appeal or override process. Risk scoring should guide proportional controls rather than become an unquestionable automated verdict.

Identity Governance and Accounting

Identity governance includes joiner–mover–leaver processes, entitlement reviews, ownership, segregation-of-duties analysis, access requests, approvals, and recertification. The organization should know who owns each application and permission, why access exists, when it expires, and how it will be removed.

Logs should capture subject, event, resource, action, timestamp, source, outcome, and relevant correlation identifiers. Time synchronization is essential for reconstructing events. Logs must be protected against alteration, access-controlled, retained according to legal and operational requirements, and monitored for suspicious patterns. Excessive collection creates privacy and storage risks; logging should be purposeful and proportionate.

Useful operational measures include MFA coverage, privileged-account inventory, dormant-account age, time to revoke leavers, percentage of access reviews completed, authentication failure patterns, and mean time to detect account compromise. Metrics should measure risk reduction rather than encourage superficial compliance.

Illustrative Case: Federated Access for a University Research Cloud

Background. A university operates laboratories, a central identity provider, and a cloud platform used by staff, students, and external collaborators. Researchers require access to datasets and compute resources, while administrators need controlled privilege.

Problem. Accounts were manually created in individual laboratories. Departing researchers retained access, external collaborators shared passwords, and administrators used a common cloud account. Audit evidence was incomplete.

Analysis. The institution identified four requirements: authoritative lifecycle information, federation for internal and external users, strong authentication for sensitive work, and traceable temporary administration. It also recognized that a single broad role would violate least privilege.

Approach. The university connected the human-resources and student systems to a central identity lifecycle service. Internal users authenticate through OIDC with phishing-resistant authenticators. A federation gateway supports collaborators using approved identity providers. Cloud applications receive scoped authorization claims, while ABAC policies evaluate affiliation, dataset classification, project membership, device posture, and purpose. Administrators receive separate privileged identities and just-in-time cloud roles through PAM. All access and elevation events are sent to a protected, time-synchronized logging service.

Outcome. Access is automatically removed when authoritative affiliation ends; project membership expires unless renewed; collaborators do not share passwords; and administrative actions are attributable to individuals. The institution still must review attributes, protect recovery channels, test federation configurations, and avoid treating a successful login as unlimited trust.

Learning points. Federation reduces duplicated credentials but does not eliminate authorization responsibility. Strong authentication must be paired with lifecycle governance. PAM and logging provide accountability, while ABAC can express research-specific conditions that simple groups cannot.

Challenges, Ethics, and Governance

IAM programs face conflicting goals. Strong controls can increase friction, while convenience can increase compromise risk. Accessibility must be designed from the beginning: biometric alternatives, recovery paths, assistive technology compatibility, and support for users without personal smartphones are essential.

Biometric and behavioural data raise significant privacy concerns because they can reveal sensitive characteristics and are difficult to change after compromise. Collection should have a defined purpose, lawful basis, limited retention, strong protection, and transparent communication. Automated risk decisions should be tested for disparate impact and should not deny essential services without human review.

Regulatory obligations vary by jurisdiction and sector, but common expectations include least privilege, access review, segregation of duties, breach detection, evidence preservation, and protection of personal data. Standards and guidance such as NIST digital identity guidance, zero-trust architecture principles, ISO/IEC 27001 controls, and sector-specific requirements can structure governance; they do not replace local legal analysis.

Artificial intelligence can assist with anomaly detection, entitlement recommendation, and alert prioritization. However, AI outputs may be opaque, biased, poisoned by poor data, or manipulated by attackers. Human accountability, model validation, data minimization, and controlled action boundaries are necessary. An AI system should not silently grant broad privilege merely because a risk score appears low.

Best-Practice Design Principles

1. Establish authoritative identity sources and automate joiner–mover–leaver changes.
2. Prefer phishing-resistant MFA for sensitive access.
3. Use short-lived, scoped credentials and eliminate embedded secrets.
4. Separate authentication from authorization and validate both independently.
5. Combine RBAC with ABAC where context matters.
6. Enforce PAM, just-in-time elevation, and individual accountability.
7. Protect password verifiers with modern salted, adaptive hashing.
8. Design secure enrollment, recovery, replacement, and revocation processes.
9. Log decisions and privileged actions with reliable time and tamper resistance.
10. Review permissions regularly and measure actual risk reduction.
11. Test policies, federation metadata, token validation, and failure modes.
12. Treat privacy, accessibility, explainability, and human oversight as security requirements.

Chapter Summary

Identity management begins with identification and proceeds through authentication, authorization, and accounting. Authentication assurance depends on independent factors, secure credential handling, resistant protocols, and trustworthy recovery. MFA improves security, while phishing-resistant public-key authentication and passwordless designs reduce dependence on reusable secrets. Biometrics provide convenient evidence but introduce privacy, accuracy, and irreversibility concerns.

Authorization models differ in expressive power and administration. RBAC maps permissions to job functions; ABAC evaluates subject, resource, action, and environmental attributes; PAM controls high-impact administrative authority. OAuth 2.0 delegates authorization, OIDC adds identity claims, SAML supports enterprise federation, and Kerberos provides ticket-based authentication in managed realms. Modern identity-centric security combines these technologies with lifecycle governance, device and context signals, least privilege, logging, and human accountability. No protocol compensates for stale accounts, weak recovery, excessive privilege, or poor governance.

Key Terms

Identification: A claim of an identity.

Authentication: Verification of an identity claim.

Authorization: A decision about permitted actions on resources.

Accounting: Recording and reviewing security-relevant activity.

Principal: An entity recognized by a security system.

MFA: Authentication using independent factor categories.

Phishing resistance: Ability to prevent credentials or authentication responses being relayed to a fraudulent service.

Biometric authentication: Authentication using measurable human characteristics.

RBAC: Access control based on roles and permissions.

ABAC: Access control based on attributes and policy conditions.

Least privilege: Granting only the authority required for an approved task.

PAM: Controls for managing privileged identities and elevation.

OAuth 2.0: A delegated authorization framework.

OIDC: An identity layer built on OAuth 2.0.

SAML: An XML-based federation and assertion standard.

Kerberos: A ticket-based authentication protocol using a KDC.

Federation: Trust-based exchange of identity or authorization information across domains.

Passwordless authentication: Authentication without a reusable password, often using public-key cryptography.

Zero trust: A security approach that continuously evaluates access rather than trusting network location.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accounting.
2. Why are two passwords not normally considered MFA?
3. State two differences between RBAC and ABAC.
4. What is the purpose of PKCE in an OAuth authorization-code flow?
5. Why should privileged accounts be separated from ordinary user accounts?

Long Answer Questions

1. Explain the complete IAM lifecycle and discuss how failures in one stage can undermine strong authentication.
2. Compare passwords, biometrics, one-time codes, and public-key authenticators in terms of security, usability, and privacy.
3. Explain OAuth 2.0, OIDC, SAML, and Kerberos, identifying the problem each is primarily designed to solve.
4. Design a PAM program for a large enterprise, including technical controls, governance, monitoring, and emergency access.
5. Discuss how zero-trust architecture uses identity, device posture, resource sensitivity, and context to make access decisions.

Analytical / Application Questions

1. A departing contractor remains a member of a cloud administrator group for three weeks. Analyze the lifecycle and governance failures and propose preventive and detective controls.
2. A hospital wants clinicians to access records only for assigned patients from managed devices, with emergency override capability. Design an RBAC-plus-ABAC policy and explain its audit requirements.
3. An organization has high MFA adoption but frequent account takeovers caused by phishing and help-desk recovery fraud. Evaluate the weaknesses and recommend a phased improvement strategy.

Multiple Choice Questions with Answers

Question 1

Which sequence correctly represents the core IAM functions?

A. Authorization, identification, encryption, accounting

B. Identification, authentication, authorization, accounting

C. Authentication, identification, accounting, authorization

D. Accounting, authorization, identification, authentication

Correct Answer: B. Identification, authentication, authorization, accounting

Question 2

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

A. SMS one-time password

B. Password plus security question

C. Origin-bound public-key authentication such as WebAuthn

D. Email verification link

Correct Answer: C. Origin-bound public-key authentication such as WebAuthn

Question 3

What is the primary purpose of OAuth 2.0?

A. Delegated authorization

B. Password hashing

C. Biometric template storage

D. Network time synchronization

Correct Answer: A. Delegated authorization

Question 4

Which statement best describes OIDC?

A. It replaces all access-control policies with encryption

B. It adds an identity layer to OAuth 2.0

C. It is a Kerberos ticket format

D. It is a password database standard

Correct Answer: B. It adds an identity layer to OAuth 2.0

Question 5

Which model evaluates attributes of the subject, resource, action, and environment?

A. DAC only

B. RBAC only

C. ABAC

D. Single sign-on

Correct Answer: C. ABAC

Question 6

Which control is most characteristic of privileged access management?

A. Permanent shared administrator passwords

B. Just-in-time elevation with session recording

C. Disabling all audit logs

D. Granting every employee domain-admin rights

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

Question 7

What is a major limitation of biometric authentication?

A. Biometric characteristics are always secret

B. A compromised biometric characteristic is difficult to replace

C. Biometrics cannot be used with devices

D. Biometrics never produce false matches

Correct Answer: B. A compromised biometric characteristic is difficult to replace

Question 8

In Kerberos, what allows a user to authenticate to services without sending the password to each service?

A. Service tickets issued by a trusted KDC

B. Public DNS records

C. OAuth scopes only

D. Unencrypted password transmission

Correct Answer: A. Service tickets issued by a trusted KDC

Question 9

Which practice best protects stored passwords?

A. Reversible encryption with one shared key

B. Plaintext storage in a restricted file

C. Unique salts and an adaptive password-hashing function

D. Base64 encoding

Correct Answer: C. Unique salts and an adaptive password-hashing function

Question 10

Which statement about an OAuth access token and an OIDC ID token is correct?

A. They are always interchangeable

B. An access token is intended for an API, while an ID token conveys identity to the client

C. An ID token must be sent to every resource server

D. An access token is only a password replacement

Correct Answer: B. An access token is intended for an API, while an ID token conveys identity to the client