Access Controls
From identity to accountability
Every access control question fits a four-step chain: identification (claiming an identity, e.g., a username), authentication (proving it), authorization (what you may do), and accountability/auditing (logging what you did). When a question asks "what is this?", decide which link in the chain is being described.
Authentication factors: something you know (password, PIN), something you have (token, smart card), something you are (biometrics), something you do (keystroke dynamics, signature), somewhere you are (location). MFA requires different categories, not two items from the same category.
Biometrics: FAR (wrongly accepting an impostor), FRR (wrongly rejecting a legitimate user), and the crossover error rate where the two meet - a lower CER means a better system. Sensitivity settings simply trade one error for the other.
Access control models: DAC (owner decides, ACLs), MAC (labels and clearances, need-to-know, mandatory), RBAC (permissions assigned to roles, users assigned to roles - ideal for high turnover), ABAC (attribute- and policy-based), plus rule-based and risk-based variants. Know SSO, Kerberos (KDC, TGT, tickets), and federation: SAML for web SSO, OAuth 2.0 for delegated authorization, OIDC for identity layered on OAuth. RADIUS encrypts only the password; TACACS+ encrypts the whole payload and separates the AAA functions.
Trap: "least privilege" vs "need-to-know" - need-to-know is about data, least privilege is about rights. Another: OAuth 2.0 is authorization, not authentication; that is OIDC.
Worked example: a hospital wants nurses to see only patients on their ward and to lose access automatically on transfer. That is RBAC for the role plus rule/attribute-based restriction on the record - not DAC.
Rule of thumb: when users churn, choose roles; when the decision depends on many contextual attributes, choose ABAC.