Access control and authentication
Access control and authentication tests the path from proving an identity to enforcing least privilege. Questions often separate authentication - who you are - from authorization - what you may do - and accounting - what you did, then ask which control fits a scenario.
Core rules and concepts
- Authentication factors: something you know, something you have, something you are, plus location and behavior as contextual signals. MFA requires different factor types, not two passwords.
- Access control models: discretionary where the owner grants access; mandatory using labels and clearances; role-based by job function; attribute-based using context and attributes. Least privilege, separation of duties, and need-to-know constrain every model.
- Federation and SSO let one identity provider authenticate users to many services. SAML is common for browser SSO; OpenID Connect adds an identity layer over OAuth 2.0, which is an authorization framework, not an authentication protocol by itself.
- Privileged access management vaults credentials, brokers sessions, and records administrative activity. Kerberos uses tickets; RADIUS and TACACS+ centralize network device authentication.
Worked example
A contractor needs read-only access to one project repository for 30 days. Granting a permanent employee role would violate least privilege. A role-based group scoped to the repository, plus time-bound membership and MFA at the identity provider, fits the requirement. Access reviews and session logging provide accounting. If the contractor also needs production data, require a separate approved request rather than extending the broad role.
Traps that cost marks
Do not treat SSO as MFA. Do not call OAuth 2.0 an authentication protocol. Do not accept something you know plus a security question as MFA. Do not confuse authorization with accounting, or role-based access with rule-based access.