Most breaches involve a stolen or misused identity at some point. Identity and Access Management (IAM) is the set of processes and technology that answers four questions: who is this, can they prove it, what may they do, and what did they do. The short version lives in Security Concepts; this page goes one level deeper.
Identification, Authentication, Authorization, Accounting
Identification -> "I am alice" (claim)
Authentication -> password / key / fingerprint (proof)
Authorization -> alice may read /finance, not write (permission)
Accounting -> alice read /finance at 09:14 (audit trail)
| Step | Question | Example control |
|---|---|---|
| Identification | Who do you claim to be? | Username, email, employee ID |
| Authentication | Can you prove it? | Password, token, biometric |
| Authorization | What are you allowed to do? | ACLs, roles, policies |
| Accounting | What did you do? | Logs, audit trails, SIEM |
Accounting is what gives non-repudiation: without reliable logs you cannot hold anyone accountable.
Authentication Factors
| Factor | Category | Examples | Weakness |
|---|---|---|---|
| Something you know | Knowledge | Password, PIN, security answers | Guessed, phished, reused |
| Something you have | Possession | Hardware key, authenticator app, smart card | Lost, stolen, SIM-swapped (SMS) |
| Something you are | Inherence | Fingerprint, face, iris | Cannot be changed if leaked; false accepts/rejects |
| Somewhere you are / something you do | Context | Geo-location, IP range, typing pattern | Spoofable; used as a risk signal, not proof |
Multi-factor authentication (MFA)
MFA combines two or more different categories. A password plus a security question is still one factor (both are knowledge). MFA stops most credential-stuffing, but not all of it:
- Strongest: phishing-resistant FIDO2/WebAuthn keys, smart cards.
- Good: authenticator-app TOTP codes, push approval with number matching.
- Weaker: SMS and voice codes (SIM swap, interception), push prompts without number matching (MFA fatigue / prompt bombing).
Passwordless and FIDO2
FIDO2 (WebAuthn + CTAP) replaces the shared secret with a public/private key pair. The private key stays on the device or security key and is unlocked locally with a PIN or biometric. The server stores only the public key and the login is bound to the real site's origin, so a look-alike phishing site cannot replay it. Passkeys are the synced, consumer-friendly form of the same idea. See Public Key Infrastructure for the key-pair concepts.
Passwords: Policy and Storage
Current guidance (NIST SP 800-63B style) favours length and screening over forced complexity and rotation:
- Minimum length of 12+ characters; allow passphrases and paste into password fields.
- Check new passwords against breached and common-password lists.
- Rotate only on evidence of compromise, not on a calendar.
- Lockout or throttling after repeated failures; MFA for anything important.
- Provide a password manager; never reuse passwords across systems.
Storage: servers must never keep plaintext or reversibly encrypted passwords. They store a salted, deliberately slow hash (bcrypt, scrypt, Argon2, PBKDF2). Salting defeats rainbow tables and the slow cost factor makes offline cracking expensive. The hashing concepts are covered in Cryptography Fundamentals; attack side in Cryptography Attacks.
Single Sign-On and Federation
SSO lets a user authenticate once and reach many applications. Federation extends that across organisations: an Identity Provider (IdP) vouches for the user to a Service Provider (SP/relying party) via signed tokens, so the SP never sees the password.
User --1 open app--> Service Provider
User <-2 redirect--- Service Provider
User --3 login+MFA-> Identity Provider
User <-4 signed assertion/token- IdP
User --5 present token--> Service Provider -> access granted
| Protocol | Purpose | Token / format |
|---|---|---|
| SAML 2.0 | Enterprise web SSO (authentication) | XML assertions |
| OAuth 2.0 | Delegated authorization — "let this app access my calendar" | Access tokens |
| OpenID Connect (OIDC) | Authentication layer on top of OAuth 2.0 | JWT ID token |
Common mistake: OAuth 2.0 alone is not an authentication protocol; OIDC adds the identity part. Risks include token theft, weak redirect-URI validation and overly broad scopes.
Directory and network authentication protocols
| Protocol | One-liner |
|---|---|
| LDAP | Query/modify a directory (users, groups); LDAPS or StartTLS to protect it |
| Kerberos | Ticket-based authentication in Active Directory; a KDC issues tickets so passwords are not sent repeatedly. Attacks: Active Directory Attacks |
| RADIUS / TACACS+ | Central AAA for network devices, VPN and Wi-Fi; see RADIUS and the AAA server and 802.1x |
Access Control Models
| Model | Who decides | Idea | Typical use |
|---|---|---|---|
| DAC (Discretionary) | Resource owner | Owner grants others access (file permissions, ACLs) | Operating systems, file shares |
| MAC (Mandatory) | Central policy | Labels on subjects and objects (e.g. Secret, Confidential); users cannot override | Military, SELinux |
| RBAC (Role-Based) | Admin via roles | Permissions attach to roles; users get roles | Most enterprises |
| ABAC (Attribute-Based) | Policy engine | Decision from attributes of user, resource, action, environment ("finance staff, managed device, work hours") | Cloud IAM, zero trust |
| Rule-based | System rules | Fixed rules such as firewall ACLs or time-of-day limits | Network devices |
RBAC is simple to audit but suffers role explosion; ABAC is flexible but harder to reason about. Labelling-based models such as Bell-LaPadula and Biba are summarised in the Security Principles lab note.
Governing Principles
- Least privilege: grant only the access needed for the task, for the time needed. Includes service accounts and API keys.
- Need to know: even with clearance, access only what the job requires.
- Separation of duties (SoD): split critical tasks so no one person can complete fraud alone (the person who requests a payment cannot approve it). See Security Architecture Principles.
- Job rotation and mandatory leave: surface fraud and cross-train.
- Default deny: no access unless explicitly granted.
Account Lifecycle (Joiner / Mover / Leaver)
Joiner -> create account, assign baseline role, enrol MFA
Mover -> change role: ADD new access, REMOVE old access
Leaver -> disable at once, revoke tokens/keys, recover assets, archive
\-> periodic access reviews (recertification) catch drift
The usual failures are privilege creep (movers keep old rights), orphaned accounts (leavers never disabled) and shared or generic accounts that destroy accountability. Automated provisioning from the HR system and quarterly access reviews are the standard fix.
Privileged Access Management (PAM)
Admin and service accounts are the most valuable targets, so they get extra controls:
- Separate admin accounts from daily-use accounts; no browsing or email as admin.
- Just-in-time (JIT) elevation with approval and expiry instead of standing admin rights.
- A vault stores and rotates credentials; sessions are proxied and recorded.
- Break-glass emergency accounts that are sealed, monitored and alerted on.
- Log and review every privileged action in the SIEM.
Key Points
- AAA: identify, authenticate, authorize, account. Each step needs its own control.
- Real MFA mixes factor categories; phishing-resistant FIDO2 is the best option available.
- Store passwords as salted slow hashes, and favour length and breach screening.
- SAML and OIDC authenticate, OAuth 2.0 delegates authorization.
- Choose an access control model (DAC, MAC, RBAC, ABAC) and enforce least privilege and SoD.
- Manage the whole lifecycle: joiners, movers, leavers, and review privileged access.
Related
- Security Concepts | Security Controls | CIA Triad | Operating System Security
- Security Technologies (802.1x, RADIUS, NAC)
- Active Directory Attacks
- Hands-on: THM: Identity and Access Management