Identity and Access Control Models

Identity is a process, not a database

Every access control system in the world runs the same four-line script. A subject claims an identity. The system proves the claim. The system decides what the proven identity may do. The system records what it actually did. Claim, prove, permit, record. The order matters, the failure modes are different at each step, and almost every Domain 5 exam scenario is a story about exactly one of those four lines breaking.

It is tempting to think of identity and access management as a database problem: get the right accounts in the right directory and the work is done. That is a comfortable and wrong picture. The database is the least interesting part. What the exam actually tests is the logic that surrounds the database: how a claim becomes a proof, how a proof becomes a permission, and how a permission becomes a record that can be held against the person who used it. A directory full of perfect accounts is worthless if authentication can be replayed, if authorization is enforced by the wrong model, or if nothing is logged. IAM is not the storage of identity. It is the discipline of identity: a set of decisions about how much to trust a claim, what proof to demand, who gets to make the permission call, and what evidence survives the interaction.

That discipline is why Domain 5 carries 13 percent of the exam, and why the questions in this domain are rarely about a specific product. The questions hand you a scenario and ask you to name the broken step, select the factor, choose the model, or judge the administration arrangement. This chapter gives you the decision framework for all four moves. It covers the identity four-step itself, the authentication factors with the standards that govern them, the access control models that turn identity into permission, and the administration structures that decide who runs the shop. Chapter 20 continues from here: the identity lifecycle, directories, federation protocols, and privileged access management. This chapter is the grammar; Chapter 20 is the usage.

One habit will carry you through the whole domain, so adopt it now. When you read a scenario, ask which of the four steps is under attack before you reach for a control. A stolen password is an authentication failure. A user who can see files they should not see is an authorization failure. A shared account with no audit trail is an accountability failure. An account that survives a firing is a lifecycle failure. If you can classify the step, the correct answer usually names itself, because each step has its own family of controls and its own exam vocabulary.

The identity four-step: claim, prove, permit, record

The four-step process is the spine of Domain 5, and the exam is exact about the seams between the steps.

Identification is the claim. The subject presents an identity: a username, an account name, a smart card serial, a distinguished name in a directory. Identification answers “who do you say you are?” and nothing else. It carries no proof. A username is identification. That is why the exam treats “user enters their username” as a different act from “user enters their password”: one is a claim, the other is proof of the claim.

Authentication is the proof. The subject demonstrates, through one or more factors, that they are who they claim to be. Authentication answers “prove it.” The proof is what the entire middle of this chapter is about: factors, multi-factor combinations, protocols that carry the proof, and the standards that grade the strength of the proof.

Authorization is the permission. After the identity is proven, the system determines what that identity may do: which files, which actions, which transactions, at which times. Authorization answers “now that we know who you are, what are you allowed to touch?” It is performed by the access control models this chapter covers: discretionary, mandatory, role-based, attribute-based, and the rest. Authorization presupposes authentication, and the exam will punish you for confusing the two. A user with a valid password who lacks the right role is authenticated but not authorized.

Accountability is the record. The system attributes actions to an identity and preserves evidence of them: audit logs, transaction records, access reviews. Accountability answers “who did what, and can they deny it?” It requires that identities be unique and not shared, that actions be logged, and that the logs survive with integrity. Accountability is the step that makes the other three meaningful. Without it, a breach investigation cannot attribute the action, and a user can plausibly deny a transaction. Non-repudiation, the property that prevents a party from denying an action they performed, is the cryptographic cousin of accountability: it is what strong authentication and signed records give you. The exam likes to pair the terms, and you should treat accountability as the management-layer concept and non-repudiation as the technical mechanism that underwrites it.

Three common confusions, and how to beat them. First, identification is not authentication. Presenting a claim is not proving it. Second, authentication is not authorization. Being proven to be Alice does not give Alice everything; it gives Alice what Alice’s profile permits. Third, authorization is not accountability. Granting the right to do something is not the same as recording that it was done. Every time a scenario blurs two of the steps, the correct answer is usually the one that keeps them separate.

What “prove” really means: the three classic factors

Authentication works by factors. A factor is a category of evidence, and the classic taxonomy has three, with two honorary additions the exam occasionally tests.

Something you know is knowledge: a password, a PIN, a passphrase, a security question answer. It is the cheapest factor to issue, the easiest to steal, and the most likely to be shared. Something you have is possession: a hardware token, a smart card, a one-time password generator, a mobile device, a certificate stored in a protected module. It is stronger against remote attackers because the attacker must obtain the physical thing or a copy of its secret, but it can be lost, stolen, or cloned. Something you are is inherence: a biometric such as a fingerprint, an iris pattern, a face image, a voiceprint. It is hard to leave at home, which is also its weakness, because a compromised biometric cannot be reissued the way a password can.

The two honorary factors appear in some taxonomies and in occasional questions. Somewhere you are is location: the network address, the geolocation, the building the badge reader sits in. It is weak as a standalone factor because location can be spoofed, but strong as a constraint on other factors, which is why risk-based systems flag logins from a new country. Something you do is behavior: keystroke dynamics, signature dynamics, mouse movement patterns. Behavioral traits are continuous rather than discrete, which makes them better for ongoing verification than for a single login event.

Multi-factor authentication, MFA, means the proof uses two or more factors from different categories. The independence is the whole point. A password plus a second password is one factor used twice; an attacker who phishes one password can phish the other. A password plus a one-time code from a token is two factors: a compromise of the password alone is not enough, and theft of the token alone is not enough. The exam treats MFA as a response to the weakness of any single factor, and the phrase “two-factor” is a special case of “multi-factor” with exactly two categories.

NIST SP 800-63B, “Digital Identity Guidelines: Authentication and Lifecycle Management,” grades this strength with three authenticator assurance levels. AAL1 requires a single factor and works for low-risk applications. AAL2 requires two distinct factors and covers most business use. AAL3 requires two factors with a hardware-based authenticator that resists verifier impersonation, which is the level for the most sensitive systems. The level names matter less than the ladder: the standard exists to let an organization match proof strength to risk, and that matching instinct is exactly what the exam rewards.

A note on factor hygiene that the exam loves. A factor is only as good as its independence from the others and its resistance to the channel. A one-time code delivered by SMS depends on the phone network and can be intercepted through SIM-swap attacks, which is why NIST’s own guidance has discouraged SMS for out-of-band verification where stronger options exist. A biometric checked against a photo on the same device that stores the template is not two factors, because one attacker with the device controls both. When a scenario describes a scheme where two “factors” live on one device or one channel, the correct answer is usually that the scheme is weaker than it looks.

Memorized secrets and the password question

Passwords are the oldest factor, the most common, and the most instructive, because the guidance about them changed dramatically, and the exam reflects the modern guidance.

NIST SP 800-63B sets the current bar for memorized secrets. The headline rules: a memorized secret should be at least 8 characters when the subscriber chooses it; the system should allow long secrets, so passphrases are possible; the system must not impose composition rules that force arbitrary mixtures of uppercase, digits, and symbols, because those rules make secrets harder to remember and no more resistant to real attacks; the system must not require periodic rotation of secrets chosen by the subscriber, because forced rotation pushes people into predictable patterns and the standard has concluded the cost exceeds the benefit; and the system must screen new secrets against a list of known compromised values, so “Password1!” is rejected before it can be used. Storage must be salted and hashed, never reversible, and the authentication endpoint must rate-limit guessing attempts.

Read the standard the way the exam reads it. The enemy of password security is not a weak algorithm in the abstract; it is credential stuffing and password spraying, where attackers use secrets stolen from one site or common passwords, against every account they can reach. Blocklists and rate limiting attack that enemy directly. Complexity rules and forced rotation attack a cartoon enemy, and they push users toward writing secrets down and reusing them. When a question offers “force 90-day rotation with 12-character complexity” against “screen new passwords against a known-compromised list and rate-limit attempts,” the modern answer is the second one. The manager-perspective reason: a policy is a control like any other, and the best controls are the ones that actually reduce the specific risk, not the ones that look strict on a poster.

Three password-era facts are worth carrying into the exam hall. First, a breached password database is not a reason to rotate everything; it is a reason to invalidate the breached secrets, because the risk is the stolen credential being replayed, and rotation of unrelated secrets does nothing about that. Second, length beats complexity for resisting brute force, which is why passphrases are recommended and why the standard removed the artificial ceiling on secret length. Third, the password is one factor; the strongest password in the world still loses to a keystroke logger, which is why the exam pairs password controls with phishing resistance and MFA rather than treating the password itself as a fortress.

Possession: tokens, one-time passwords, and hardware keys

The possession factor comes in a ladder of increasing strength, and the exam expects you to know which rung is which.

The one-time password is the workhorse. HOTP, the HMAC-based one-time password defined in RFC 4226, derives a code from a secret and a moving counter; each code is valid once, and the server tracks the counter to accept the next expected values. TOTP, the time-based one-time password defined in RFC 6238, replaces the counter with the current time, so codes change every 30 seconds or so and the server accepts a small window around the expected value. Both require the client and server to share a secret, and both produce short codes that an attacker cannot guess in the valid window. The authenticator app on a phone is the consumer incarnation; the dedicated hardware token is the enterprise incarnation. The classic failure mode is the shared-secret bootstrap: if the secret is provisioned over a channel an attacker controls, the whole scheme is theater, which is why enrollment and provisioning are treated as security events in their own right.

Smart cards and PIV cards put the possession factor in hardware with a private key that never leaves the card. FIPS 201, the Personal Identity Verification standard, defines the PIV card used across US federal agencies: a tamper-resistant card whose private key is generated inside the card or loaded into it under controlled conditions, so that authentication requires both the physical card and a PIN, and the secret cannot be extracted by malware on the host. The Common Access Card used by the US Department of Defense is the same family of design. The exam treats smart cards as the answer to “possession factor that resists remote compromise” and to “two-factor in one device, because the card is the possession factor and the PIN is the knowledge factor.”

Hardware security keys extend the same idea to web authentication. The FIDO2 and WebAuthn family let a browser prove possession of a device that holds a key, with the server receiving a signed assertion rather than a reusable secret, which makes phishing against the credential itself substantially harder. The exam does not demand FIDO trivia, but it does expect you to recognize the design property: the proof is bound to the origin and the device, so a credential phished at a lookalike site is useless.

The weakness of every possession factor is the same: the thing can be lost, stolen, or cloned, and the possession check only proves the thing was present. That is why possession is always paired with something you know, a PIN or password, and why “we require a token” is not a complete answer to “how do we authenticate.” The token authenticates the token; the PIN authenticates the human holding it.

Inherence: biometrics and the threshold trade

Biometrics authenticate by measuring the body, and the exam treats them with a skeptical respect: powerful when used well, dangerous when used alone.

The taxonomy first. Physiological biometrics measure a stable physical trait: fingerprint, iris pattern, retina scan, facial geometry, hand geometry, palm print. Behavioral biometrics measure a pattern of action: voice patterns, keystroke dynamics, signature dynamics, gait. The distinction matters for one exam reason: physiological traits are relatively stable over a life, while behavioral patterns drift with mood, fatigue, and practice, so behavioral systems usually demand ongoing verification rather than a one-time enrollment.

The mechanics that matter. Enrollment captures the reference, the biometric template, and stores it. Verification compares a fresh sample to the stored template to confirm a claimed identity, which is authentication. Identification compares the fresh sample against a database of many templates to find who it matches, which is a search problem, and it is far harder than verification. The exam will hand you a scenario where a system claims to identify someone against a large database and expect you to know that this is a materially harder problem than verifying a claimed identity against a single template.

The accuracy vocabulary is the part the exam actually tests, and it is a threshold trade, not a fixed property. Every biometric system has a decision threshold, the similarity score above which a sample is accepted. Lower the threshold and you accept more true matches but also more false ones; raise it and you reject more impostors but also reject more legitimate users. False accept rate, FAR, is the proportion of impostor attempts accepted. False reject rate, FRR, is the proportion of genuine attempts rejected. The two move in opposite directions as the threshold moves, and the crossover error rate, CER, is the point where they are equal; it is the standard single number for comparing system accuracy, and a lower CER means a better system. The exam will ask you the direction of the trade, so hold it firmly: tightening the threshold lowers FAR and raises FRR, and loosening it raises FAR and lowers FRR.

Two more exam habits about biometrics. First, a biometric is a username, not a password, is a phrase that circulates in security writing, and its kernel is right: the body is a persistent identifier that cannot be reissued, so a stolen template is a permanent credential problem. That is why templates must be stored as protected references, why liveness detection, the check that the presented finger or face is alive and not a photo or a cast, is part of a serious system, and why presentation attacks, a printed photo, a silicon fingerprint, a recorded voice, are the standard threat model for biometric readers. Second, biometrics are usually a factor in an MFA stack, not a complete solution. The exam’s best answer to a biometric scenario is often the one that pairs the biometric with a PIN or a token and protects the template pipeline.

Authentication protocols and AAA: the network layer of proof

Factors prove identity locally. Protocols carry the proof across a network, and the exam expects the protocol family tree, with its aging branch, its modern branch, and its AAA spine.

The aging branch is the direct password protocols. PAP, the Password Authentication Protocol, sends the password in the clear and exists in the exam as a cautionary example: any scenario that chooses PAP is a scenario that should choose something else. CHAP, the Challenge-Handshake Authentication Protocol defined in RFC 1994, replaces the transmitted secret with a challenge-response exchange: the server sends a random challenge, the client returns a hash of the challenge and the secret, and the server verifies the hash. The secret never crosses the wire, which is the property CHAP exists to demonstrate. The response is only valid for the challenge, which defeats replay of a captured response. The lineage continues in modern point-to-point authentication, but the exam cares about the design insight, not the deployment status.

The modern branch is EAP, the Extensible Authentication Protocol defined in RFC 3748, which is a framework for authentication methods rather than a single method. EAP carries whatever method the two sides negotiate, which is what makes it extensible: EAP-TLS (RFC 5216) runs certificate-based mutual authentication inside the EAP exchange, PEAP wraps a protected tunnel around inner authentication, and EAP-TTLS does the same with a different tunnel structure. The framework design matters more than the method names: the transport carries methods, and the method determines the strength. IEEE 802.1X uses EAP for port-based network access control, so a device that wants onto the network proves itself before the switch port carries its traffic, with EAP over LAN frames carrying the exchange. The exam pairing to remember: 802.1X and EAP for “we want to authenticate the device or user before granting network access,” and EAP-TLS for “certificates on both sides.”

The AAA spine is RADIUS and TACACS+. AAA stands for authentication, authorization, and accounting, and the two protocols are the standard vehicles for centralizing all three. RADIUS, the Remote Authentication Dial In User Service defined in RFC 2865, is the ubiquitous AAA protocol for network access, VPN, and wireless: it authenticates the user, returns authorization attributes such as a VLAN or an access list, and produces accounting records for sessions. It runs over UDP, conventionally on port 1812 for authentication and 1813 for accounting, and it encrypts only the password and a handful of attributes, leaving much of the exchange readable on the wire. TACACS+ is the Cisco-developed alternative, published in RFC 8907, which runs over TCP on port 49, encrypts the entire body of the exchange, and separates the three A functions so that authorization and accounting decisions can differ per command. The exam discriminator: when a scenario needs per-command authorization and full encryption of the exchange, TACACS+ is the answer; when the question is about standard network-access authentication at scale, RADIUS is the answer.

Kerberos deserves its own paragraph because it is the enterprise workhorse and the subject of a later chapter’s federation material. Defined in RFC 4120, Kerberos authenticates users to services across a network using symmetric keys and tickets, with a Key Distribution Center, KDC, playing the trusted third party. The KDC hosts two services: the Authentication Service, AS, which issues a ticket-granting ticket, TGT, to a user who proves their password, and the Ticket-Granting Service, TGS, which accepts the TGT and issues service tickets for specific servers. A ticket contains a session key and an expiry, encrypted with keys the client and the server share with the KDC, so neither side ever transmits a password over the network. Mutual authentication is built in: the service proves possession of its key, and the client proves possession of its ticket. Kerberos is the default authentication protocol in Windows Active Directory, which is why the exam treats it as the answer to “single sign-on inside a trusted domain” and why Chapter 20 takes it up in the federation context. The vocabulary to hold: KDC, AS, TGS, TGT, service ticket, session key, and the weakness family, pass-the-ticket and pass-the-hash, where an attacker replays captured tickets or hashes instead of breaking cryptography.

The access models: who decides, and how

Authorization is performed by a model, and the models are the heart of Domain 5’s decision framework. Every model answers the same three questions differently: who has the authority to grant access, what determines the grant, and who can override it.

The shared vocabulary first. A subject is the active party, a user, a process, a service. An object is the passive target, a file, a database, a device, a service. An operation is the action, read, write, execute, delete. An access control list, ACL, is the list attached to an object stating which subjects may perform which operations on it. A capability is the token attached to a subject stating what it may access. The two are the columns and rows of the same access matrix: the matrix lists subjects down the side, objects across the top, and authorized operations in the cells, and you read it as ACLs by looking down a column or capabilities by looking across a row. The exam rarely asks for the matrix by name, but the ACL-versus-capability distinction recurs, and it is worth holding: ACLs are object-centric, capabilities are subject-centric, and real systems mix both.

Discretionary Access Control, DAC, gives the owner of an object the authority to decide who may access it. The Trusted Computer System Evaluation Criteria, the DoD Orange Book, defined DAC as access control that is discretionary in the sense that a subject with a certain access permission is capable of passing that permission on to another subject. That is the property the exam tests: in DAC, the object owner grants and revokes, and grants can propagate. Unix file permissions and Windows NTFS ACLs are DAC in the ordinary case, because the file owner sets them. DAC is flexible and cheap, and its weakness is that it inherits the owner’s judgment and the owner’s session: a trojan that runs inside the owner’s process enjoys the owner’s rights, and a careless owner can grant more than policy intends. DAC is the model of “the person who owns it decides.”

Mandatory Access Control, MAC, removes the decision from the owner. The system enforces access according to labels and clearances: objects carry sensitivity labels, subjects carry clearances, and the system decides based on the relationship between the two, with users unable to override the decision or alter the labels. The same TCSEC that defined DAC defined MAC as access control based on the sensitivity of the information and the formal authorization of the subject, enforced by the system rather than the owner. MAC is the model of the classified world, and of modern systems like SELinux and AppArmor, where even the most privileged user on the system is constrained by the enforced policy. Its strengths are discipline and resistance to the trojan problem: a malicious process cannot hand the attacker more than the labels allow. Its weaknesses are cost, complexity, and the brittleness of a centrally defined policy.

Role-Based Access Control, RBAC, assigns permissions to roles and subjects to roles, so that access follows the job, not the person. The ANSI RBAC standard, INCITS 359-2004, formalizes the core model: role assignment, permission assignment, and the constraint structures, including hierarchical roles and separation-of-duties constraints that forbid a single role from containing mutually exclusive permissions. RBAC is the enterprise model, because jobs are stable and people change jobs: when an employee moves from finance to sales, the administrator changes the role assignment, and the permissions follow automatically. Its strengths are administrative economy and alignment with the organization chart; its weakness is role explosion when fine-grained needs outgrow the role catalogue. RBAC is the model of “permissions belong to the job, not the person.”

Attribute-Based Access Control, ABAC, grants based on attributes of the subject, the object, the action, and the environment, evaluated against policies. NIST SP 800-162, “Guide to Attribute Based Access Control,” describes the model and its policy vocabulary: a request is evaluated against policies that combine attributes, and the decision can incorporate context such as time, location, and device posture. A policy that reads “allow read when subject.department equals ‘finance’ and object.classification equals ‘internal’ and access time is within business hours” is pure ABAC. Its strength is expressiveness and fine granularity, which is why it dominates cloud and data-centric scenarios; its weakness is the burden of policy management and the risk of policy errors that are invisible until a decision goes wrong. The exam pairing to remember: ABAC for “attributes and policies,” with SP 800-162 as the citation.

Two more entries complete the model family. Rule-based access control grants according to rules evaluated by the system rather than by an owner, which is how firewall rules, content filters, and time-of-day restrictions work; it is often discussed alongside RBAC, and the exam distinction is that RBAC centers on the subject’s role while rule-based centers on system-wide conditions. Lattice-based access control organizes the label space as a lattice, a partially ordered structure where labels can be compared, and MAC implementations build on it, which is the mathematical floor under the Bell-LaPadula and Biba models Chapter 14 covers.

The decision framework that runs through all of this is a single question: who decides, and by what basis? DAC decides by owner discretion. MAC decides by label and clearance, regardless of owner. RBAC decides by role. ABAC decides by attributes and policy. Rule-based decides by conditions. When you classify a scenario into the model family, you get the answer for free, because the exam states its scenarios in model terms. A file owner granting rights is DAC. A system refusing a label change is MAC. A new hire getting the “manager” role is RBAC. A policy saying “only on-call engineers from this region during paging hours” is ABAC.

Policy on top of model: least privilege, need-to-know, and separation of duties

The models are the mechanism; the policies are the intent. Three policies recur in every IAM question, and the exam expects you to recognize them instantly, including the exact differences between the ones that sound alike.

Least privilege means every subject operates with only the rights required for its legitimate function, no more. It is the answer to “why does an application service not have domain admin,” “why does a developer not have production write access,” and “why does a breached workstation not immediately expose everything.” The exam treats least privilege as the default response to any scenario about excessive rights, and the follow-up move is usually to name the concrete grant-and-revoke mechanisms: role membership, ACL review, and account lifecycle controls.

Need-to-know is the narrower cousin: among subjects with the same clearance or role, access is limited to the data required for the task. The distinction the exam tests: least privilege bounds the set of actions, need-to-know bounds the set of data. A subject with the “security analyst” role may have broad read capability by least privilege, but need-to-know limits which incidents, which datasets, which customers are actually reachable. The two are often implemented together, and the exam rewards you for using the right word for the right gap.

Separation of duties, SoD, divides a sensitive process so that no single person can complete it alone: one employee initiates a payment, a second approves it; one engineer writes code, another reviews and merges it. The point is to make fraud and error require collusion or coincidence. SoD is a business-control concept that the access models implement: in RBAC, as mutually exclusive roles; in the general case, as access grants that are intentionally split across people. Dual control is the mechanical relative: two people must act together, physically or logically, to perform an operation, which is how a two-person rule for vault access or key custody works. Job rotation and mandatory vacations are the same family of control with a different mechanism: they surface problems that continuous occupancy hides, because the person covering the rotated job notices the anomaly the incumbent has normalized. The exam’s pattern: any scenario about “no one person should be able to do X alone” is answered with separation of duties or dual control, and the discriminator between them is whether the two people must act together for a single operation, dual control, or simply hold separate halves of a process, SoD.

These policies have administrative teeth in the standards. NIST SP 800-53’s access control family, the AC controls, includes account management, AC-2, which requires managing the lifecycle of accounts, reviewing them, and removing them when no longer needed, and least privilege, AC-6, which requires granting only the minimum rights. ISO/IEC 27001:2022 Annex A carries the same obligations in control language: A.5.15 access control, A.5.16 identity management, A.5.17 authentication information, and A.5.18 access rights all require the organization to run identity and access as a controlled, reviewed, and documented process, including the review of access rights at defined intervals. When a question asks what should be done with a departed employee’s accounts, the answer is always the same three moves: revoke, review, remove, plus verify the revocation took effect.

Administration: who runs the identity shop

The last dimension of the decision framework is administration: who has authority over the accounts, the roles, and the rights. The exam tests three structures and their trade-offs.

Centralized administration concentrates authority in one place, a directory service, an IAM team, a single identity store. Its strengths are consistency, reviewability, and economy: one policy applies everywhere, one audit trail covers everyone, and a termination in the central store propagates to every system that trusts it. Its weaknesses are scale and failure concentration: the central store is a single point of failure and a single point of compromise, which is why directory availability is treated as a resilience concern and why a compromised directory is treated as a compromised everything. The directory itself is the LDAP story, the Lightweight Directory Access Protocol standardized in RFC 4511, which reads and writes hierarchical directory entries in the X.500 namespace; the directory entry carries the attributes, the distinguished name anchors the identity, and the access controls on the directory decide who may read or change which entries. Windows Active Directory is the exam’s default example of a centralized directory built on LDAP and Kerberos.

Decentralized administration lets each system or business unit run its own accounts and rights. Its strengths are autonomy, speed, and closeness to the user: the local team knows the local needs and can grant them immediately. Its weaknesses are the mirror image of centralization: inconsistent policies, fragmented audit, duplicate and orphan accounts, and the shadow account problem, where someone exists in one system’s directory but not in another’s, or persists after departure in systems nobody remembers to clean. The exam pattern for decentralization is a scenario about an employee who left, or transferred, and whose rights survive somewhere: the missing control is a central inventory of accounts and a reconciliation between systems.

Federated identity is the third structure, and Chapter 20 covers its protocols in depth; the concept belongs here. Federation lets separate organizations trust each other’s identity assertions: an employee of company A authenticates at company A, and company B’s application accepts company A’s assertion instead of demanding its own account. The trust relationship is the product, and the security properties, who asserts, who vouches, what is in the assertion, how the assertion is signed and validated, are the exam material. The single sign-on experience, SSO, is the visible benefit of both centralization and federation: one authentication grants access to many systems. SSO reduces password fatigue and phishing surface, but it concentrates risk, because the token that opens everything becomes the trophy target, and a compromised SSO session is a compromised session everywhere. The exam’s management view: SSO is not a convenience feature, it is a risk concentration decision, justified by the reduction in credential sprawl and protected by strong authentication at the single gateway.

Two administrative practices close the section. Break-glass accounts are the emergency exception: a standing privileged account for outages, normally sealed, used only when the regular process cannot work, and audited the moment it is used. The exam likes the design because it is honest about the conflict between least privilege and emergency access: the control is not the absence of the exception, it is the supervision and audit of the exception. Privileged access management, PAM, the vaulting, rotation, and session recording of admin credentials, is Chapter 20’s territory, but the concept belongs to the administration question: the most sensitive accounts deserve the most controlled administration.

The decision framework: four questions for every scenario

Pull the whole chapter into a question sequence, because that is how you will use it at the exam.

First, which step failed? Identify, authenticate, authorize, account. A claim without proof is an authentication failure. A proof without permission is an authorization failure. An action without a record is an accountability failure. Classify before you answer.

Second, which factor is in play? Knowledge, possession, inherence, location, behavior. A scenario that says “the attacker guessed the user’s secret” is a knowledge-factor attack. “The attacker stole the phone” is a possession-factor attack. “The attacker spoofed the face reader” is an inherence-factor attack. Name the factor and the answer follows, because each factor has a matching control family: blocklists and rate limiting for knowledge, hardware-backed tokens for possession, liveness detection and template protection for inherence.

Third, which model is making the decision? Owner discretion, DAC; labels and clearances, MAC; roles, RBAC; attributes and policies, ABAC; conditions, rule-based. The scenario states the mechanism; name the family.

Fourth, who runs the shop, and how do they prove it? Centralized, decentralized, or federated; reviewed accounts; audited actions; emergency paths that are supervised. The exam’s correct answer to an administration scenario is almost always the one that adds review, reconciliation, or audit, because the manager’s job is not to build the perfect policy but to prove that the policy is alive.

The exam rewards this habit more in Domain 5 than in any other domain, because identity questions are all classification questions wearing scenario costumes. Practise the four questions on every IAM scenario you meet, including the ones in this chapter, and the classification becomes reflexive.

Practice questions

1. A user types a username into an application, then enters a password. Which two steps of the access control process have they performed?

   A. Identification, then authentication B. Identification, then authorization C. Authentication, then identification D. Authentication, then authorization

2. A system authenticates users with a password and a one-time code generated by an authenticator app on the user’s phone. Which statement about this scheme is correct?

   A. It is single-factor, because both secrets live on the user’s device. B. It is two-factor, because the password is something you know and the code is something you have. C. It is two-step but single-factor, because a compromise of the phone reveals both. D. It is an example of something you are.

3. A biometric system administrator lowers the acceptance threshold so that fewer legitimate users are rejected. What is the likely effect on the false accept rate?

   A. The false accept rate decreases. B. The false accept rate is unaffected, because FAR and FRR are independent. C. The false accept rate increases. D. The false accept rate becomes equal to the false reject rate.

4. Which statement correctly describes the crossover error rate of a biometric system?

   A. The point at which the acceptance threshold is set to zero false accepts. B. The rate at which an impostor is accepted after repeated attempts. C. The rate at which a genuine user must re-enroll. D. The point at which the false accept rate equals the false reject rate.

5. An organization’s file server lets the creator of each folder grant or deny access to other users, and grants can be passed on. Which access control model is in use?

   A. Discretionary access control B. Mandatory access control C. Role-based access control D. Attribute-based access control

6. In a classified system, users cannot change the sensitivity labels on documents, and the system grants access only when the user’s clearance dominates the document’s label. Which model describes this arrangement?

   A. Discretionary access control B. Mandatory access control C. Rule-based access control D. Discretionary with inherited ACLs

7. An administrator creates a “loan officer” role that includes the permissions to approve and to disburse loans, and the policy requires that no single person hold both permissions. What should the administrator do?

   A. Grant both permissions to the role and rely on training. B. Remove the role and assign permissions directly to individuals. C. Split the role into mutually exclusive roles and assign each person only one. D. Keep the role but log every approval for later review.

8. A policy engine evaluates “allow read when subject.department is ‘finance’ and object.classification is ‘internal’ and current time is within business hours” before every access. Which model is this?

   A. Discretionary access control B. Lattice-based access control C. Mandatory access control D. Attribute-based access control

9. An employee transfers between two business units, and each unit runs its own account administration. Six months later, the employee still holds active accounts in the old unit. Which problem does this illustrate?

   A. The shadow account problem in decentralized administration B. A failure of centralized authentication strength C. A biometric enrollment failure D. A broken single sign-on token

10. A network team must centrally authenticate remote users, return per-command authorization for device administrators, and keep full accounting records of every command, with the entire exchange encrypted. Which protocol best fits?

A. RADIUS B. TACACS+ C. CHAP D. PAP

11. In Kerberos, what does a client present to the Ticket-Granting Service to request a ticket for a specific server?

A. Its password, encrypted with the server’s key B. A freshly signed certificate C. Its ticket-granting ticket D. Its biometric template

12. Per NIST SP 800-63B, which practice is recommended for memorized secrets?

A. Require 12 characters with uppercase, digits, and symbols, and rotate every 90 days. B. Require secrets of exactly 8 characters and store them reversibly for account recovery. C. Allow any secret and rely on MFA alone, since the password no longer matters. D. Require at least 8 characters, allow long passphrases, screen new secrets against known-compromised lists, and avoid forced periodic rotation.

13. Which control most directly supports accountability?

A. Requiring unique user identities and logging their actions with integrity-protected audit records B. Encrypting all network traffic with TLS C. Segmenting the network into zones D. Requiring complex passwords

14. A switch refuses to pass traffic for a laptop until the laptop has completed an EAP exchange with a central authentication server. Which mechanism does this describe?

A. Kerberos ticket renewal B. IEEE 802.1X port-based network access control C. Attribute-based policy evaluation D. Dual control

15. Two employees must jointly unlock a safe holding the backup media: each holds one of two keys, and the safe opens only when both are inserted together. Which control is this?

A. Job rotation B. Mandatory vacation C. Dual control D. Need-to-know

16. A developer’s account can modify production data, and a malicious script executed under the developer’s session deletes records using that same authority. Which principle, if enforced, would most directly have prevented the deletion?

A. Need-to-know B. Mandatory vacation C. Dual control D. Least privilege

Answers and rationales

1. A. Presenting a username is identification, a claim of identity with no proof. Presenting the password is authentication, the proof of the claim. Authorization, deciding what the proven identity may do, comes later, and the sequence never runs authentication before identification, because there is nothing to prove without a claim first.

2. B. The password is something you know and the one-time code is something you have, two factors from two categories, so the scheme is multi-factor and, with exactly two, two-factor. The code does not live on the user’s device in any sense that merges it with the password: the authenticator app holds a shared secret, but the password is not stored on the phone, so one compromise of the phone does not reveal both factors.

3. C. Lowering the threshold accepts more samples as matches, so more impostor samples pass: the false accept rate rises. FAR and FRR move in opposite directions as the threshold moves, they are not independent, and equality between them is a specific point on the curve, the crossover error rate, not the automatic result of any threshold change.

4. D. The crossover error rate is the threshold at which the false accept rate equals the false reject rate, and it is the standard single-number comparison of biometric accuracy. It is not a policy of zero false accepts, not a measure of repeated impostor attempts, and not related to re-enrollment.

5. A. The creator of the folder owns it and grants or denies access at the owner’s discretion, and grants can propagate, which is the defining signature of discretionary access control. MAC would enforce by label with no owner override, RBAC would route through roles, and ABAC would evaluate attributes and policies.

6. B. Access is enforced by the system from the relationship between labels and clearances, and users cannot override the labels or the decision: mandatory access control. DAC lets owners decide, rule-based applies conditions, and the presence of ACLs does not make an enforced label system discretionary.

7. C. Separation of duties is implemented by splitting the conflicting permissions into mutually exclusive roles, so the “approve” role and the “disburse” role cannot be held together. Training and logging do not prevent the conflict, and assigning permissions directly to individuals abandons the administrative economy of RBAC without solving the conflict.

8. D. The decision combines attributes of the subject, the object, and the environment, time, evaluated against a policy, which is the definition of attribute-based access control per NIST SP 800-162. DAC is owner discretion, MAC is labels and clearances, and lattice-based describes the structure of a label space, not a department-and-time policy.

9. A. Each unit runs its own administration, and the transferred employee’s old account survives, an orphan or shadow account that decentralization makes easy to create and hard to see. The problem is not authentication strength, biometrics, or token expiry; it is the absence of a central inventory and reconciliation across the units’ stores.

10. B. TACACS+ (RFC 8907) separates authentication, authorization, and accounting, supports per-command authorization, and encrypts the entire exchange, which matches every requirement stated. RADIUS (RFC 2865) encrypts only selected attributes, and CHAP and PAP are single authentication methods, not AAA protocols.

11. C. After the Authentication Service issues a ticket-granting ticket, the client presents the TGT to the Ticket-Granting Service to obtain service tickets. The password is never transmitted, certificates are not part of the ticket flow, and biometrics play no role in the Kerberos design.

12. D. SP 800-63B directs minimum length of 8 characters, allowance of long secrets, screening against known-compromised lists, and no forced periodic rotation. Composition rules and forced rotation are explicitly discouraged, reversible storage is forbidden, and relying on MFA does not justify dropping password controls.

13. A. Accountability requires attribution, unique identities, and records of actions that survive with integrity, which audit logging with unique IDs provides. Encryption protects confidentiality, segmentation reduces reach, and password complexity is an authentication control; none of them attributes an action to a person.

14. B. Blocking the port until the device completes an EAP exchange with an authentication server is IEEE 802.1X port-based network access control. Kerberos renewal, ABAC evaluation, and dual control do not describe gating a switch port on an EAP conversation.

15. C. Two people must act together, each holding a needed key, to perform a single operation, which is dual control. Job rotation and mandatory vacations surface fraud over time and do not require joint action, and need-to-know limits data exposure, which is not what a two-key safe does.

16. D. Least privilege would have limited the developer’s account to only the rights the job requires, so production data modification would not have been possible in the first place. Need-to-know limits data reach among equally cleared subjects, but the developer’s production authority is an action-level grant; vacations and dual control do not constrain a single session’s rights.

Identity and access models on one page

Hold the four-line script: identification claims, authentication proves, authorization permits, accountability records. Classify every scenario into the step that failed before choosing a control. Authentication runs on factors: knowledge, possession, inherence, plus location and behavior, and multi-factor means factors from different categories, with NIST SP 800-63B setting the strength ladder and the password bar: length, blocklists, no forced rotation, salted hashing, rate limiting. Possession lives in HOTP and TOTP (RFC 4226, RFC 6238), smart cards and PIV (FIPS 201), and hardware keys; biometrics trade false accepts against false rejects at a threshold, measured at the crossover error rate, with templates protected and liveness checked. The network carries proof through EAP and 802.1X, RADIUS (RFC 2865) and TACACS+ (RFC 8907), with Kerberos (RFC 4120) as the enterprise ticket system: KDC, TGT, service tickets. Authorization runs on models: DAC is owner discretion, MAC is enforced labels, RBAC is roles (INCITS 359-2004), ABAC is attributes and policies (SP 800-162), rule-based is conditions, and the whole family answers one question, who decides and by what basis. On top of the model sit the policies: least privilege bounds actions, need-to-know bounds data, and separation of duties and dual control split authority so no one person stands alone. Administration is centralized, decentralized, or federated, and the manager’s answer to any administration problem is review, reconciliation, and audit. Four questions, one reflex: which step failed, which factor, which model, who runs the shop.