Identity & Access Management Intermediate

Identity and Access Management (IAM) answers a deceptively simple question: who can do what? Three distinct ideas are often blurred together, so keep them separate.

• Identity — who you claim to be. A username, an email, an employee number. It is just an assertion until it is proven.
• Authentication (AuthN) — proving that claim. You present evidence (a password, a token, a fingerprint) and the system verifies it.
• Authorization (AuthZ) — once your identity is proven, deciding what you are allowed to do. Reading a file, deleting a record, approving a payment.

The classic framework is AAA: Authentication, Authorization, and Accounting. Accounting (also called auditing) records what authenticated users actually did — login times, resources accessed, changes made — so activity can be reviewed, billed, or investigated after the fact.

A useful mantra: authentication asks "are you really you?", authorization asks "are you allowed?", and accounting asks "what did you do?"

Authentication evidence falls into three categories, traditionally called factors:

• Something you know — a password, PIN, or passphrase.
• Something you have — a phone, a hardware security key, a smart card, a one-time-code app.
• Something you are — a biometric such as a fingerprint, face, or iris.

Multi-Factor Authentication (MFA) requires evidence from two or more different categories. The strength comes from the categories being different: a password plus a PIN is still only one factor (both are "know"), whereas a password plus a code from your phone is genuine MFA (know + have).

MFA dramatically reduces account takeover because an attacker who steals your password still lacks your second factor. Some sources add somewhere you are (location) and something you do (behaviour) as additional signals, but the core three remain the foundation.

Passwords are the oldest and most common authentication method, and the most troublesome. Their weaknesses are structural:

• Reuse — people use the same password across many sites, so one breach unlocks many accounts (credential stuffing).
• Guessability — short or common passwords fall to brute-force and dictionary attacks.
• Phishing — users can be tricked into typing their password into a fake site.
• Storage — if a server stores passwords poorly, a breach exposes them. Servers should store a salted hash (using a slow algorithm such as bcrypt, scrypt, or Argon2), never the plaintext.

Modern guidance (e.g. NIST) favours long passphrases over forced complexity and frequent rotation, blocks known-breached passwords, and pairs passwords with MFA. A password manager lets each site have a unique, random password.

Passwordless authentication removes the shared secret entirely. Instead of a password that can be phished or leaked, you prove possession of a private key held on your device.

FIDO2 is the standard that makes this work, combining two parts: WebAuthn (a browser/web API) and CTAP (the protocol to talk to authenticators like security keys or your phone). The model uses public-key cryptography:

• When you register, your device generates a key pair unique to that site. The public key goes to the server; the private key never leaves your device.
• To log in, the server sends a challenge; your device signs it with the private key (often unlocked by a fingerprint or PIN), and the server verifies the signature with the public key.

Because the secret is never transmitted and each credential is bound to the real site origin, FIDO2 is inherently phishing-resistant. Passkeys are a consumer-friendly, syncable form of FIDO2 credentials.

Biometrics authenticate you by a physical or behavioural trait — fingerprint, face, iris, voice. They are convenient (nothing to remember or carry) and hard to share.

But biometrics are probabilistic: a scan rarely matches a stored template exactly, so the system uses a threshold. This produces two error rates:

• False Acceptance Rate (FAR) — the system wrongly accepts an impostor. A security failure.
• False Rejection Rate (FRR) — the system wrongly rejects the legitimate user. A usability failure.

Tightening the threshold lowers FAR but raises FRR, and vice versa; the Crossover Error Rate (CER), where the two are equal, is a common measure of overall accuracy. Key drawbacks: biometrics cannot be changed if stolen (you can reset a password, not your fingerprint), they raise privacy concerns, and some can be spoofed. For these reasons biometrics are best used as one factor among several, not the sole gate.

An access-control model defines the rules by which authorization decisions are made. Four are central:

• DAC (Discretionary Access Control) — the owner of a resource decides who may access it (e.g. file permissions you set yourself). Flexible but easy to misconfigure.
• MAC (Mandatory Access Control) — access is enforced by a central policy based on labels/classifications (e.g. Secret, Top Secret). Users cannot override it. Used in high-security/military settings.
• RBAC (Role-Based Access Control) — permissions attach to roles (e.g. "Accountant"), and users get permissions by being assigned roles. Scales well in organisations.
• ABAC (Attribute-Based Access Control) — decisions use attributes of the user, resource, action, and environment (e.g. "allow if department = Finance AND time is business hours AND device is managed"). The most flexible and context-aware.

RBAC answers "what role are you?"; ABAC answers "what are all the relevant attributes right now?"

Two foundational principles shape good authorization design.

Principle of Least Privilege (PoLP) — every user, process, and service should have only the access it needs to do its job, and no more. If a clerk only needs to read invoices, they should not be able to delete customers. Least privilege shrinks the blast radius: a compromised account or buggy service can do only limited damage.

Separation of Duties (SoD) — split a sensitive task so that no single person can complete it alone. For example, one employee submits a payment and a different one approves it. This prevents both error and fraud, because collusion would be required to abuse the process.

A related idea is privilege creep: over time, as people change roles, they accumulate access they no longer need. Least privilege must be maintained, not just set once — which is why access reviews exist.

An identity is not static — it has a lifecycle often summarised as Joiner, Mover, Leaver (JML):

• Joiner — a new person arrives and must be provisioned: an account is created and granted the access appropriate to their role (often automatically, based on their job).
• Mover — the person changes role, team, or location. Their access must be adjusted: new rights added and old rights removed. Skipping the removal is the main cause of privilege creep.
• Leaver — the person departs and must be deprovisioned: access revoked promptly across all systems, accounts disabled or deleted.

Prompt deprovisioning is a critical security control. Forgotten, still-active accounts of former employees (orphaned accounts) are a classic way attackers and disgruntled insiders gain access. Automating JML through an IAM system reduces both human error and the window of exposure.

Organisations need a central store of identities and their attributes. That store is a directory service.

LDAP (Lightweight Directory Access Protocol) is the standard protocol for querying and modifying directory data. Entries are organised in a hierarchical tree and identified by a Distinguished Name (DN); each entry has attributes (name, email, group memberships).

Active Directory (AD) is Microsoft’s widely used directory service. It speaks LDAP, authenticates users (often via Kerberos), and organises objects into domains and Organizational Units (OUs).

Groups are the key to manageable access: rather than granting permissions to individuals one by one, you put users into groups (e.g. "Finance", "HR-Admins") and grant permissions to the group. This pairs naturally with RBAC and makes the JML lifecycle far easier — add or remove a group membership instead of editing dozens of resources.

Single Sign-On (SSO) lets a user authenticate once with a central Identity Provider (IdP) and then access many separate applications without logging in again to each one. The applications (the Service Providers or relying parties) trust the IdP to vouch for the user.

Benefits:

• Better security — one strong login (ideally with MFA) instead of many weak, reused passwords. Credentials are entered in fewer places, reducing phishing exposure.
• Easier user experience — fewer prompts, less password fatigue.
• Central control — disabling a user at the IdP instantly cuts their access to all connected apps, which makes deprovisioning fast and reliable.

The trade-off is concentration of risk: the IdP becomes a high-value target, so it must be hardened and protected with MFA. SSO is about convenient, centralised authentication; it does not by itself decide authorization within each app.

Federation extends trust across organisational boundaries, so an identity from one domain can be accepted by another (the basis of "log in with…" and cross-company SSO). Three protocols dominate, and confusing them is a common mistake:

• SAML 2.0 — an XML-based protocol for enterprise SSO. An IdP sends a signed XML assertion to a service provider to authenticate a user. Mature, common in corporate and B2B web apps.
• OAuth 2.0 — an authorization / delegation framework. It lets an app obtain limited access to resources on a user’s behalf (via an access token and scopes) without sharing the password. Crucially, OAuth 2.0 is not an authentication protocol — it is about granting access, not proving who someone is.
• OpenID Connect (OIDC) — an authentication layer built on top of OAuth 2.0. It adds an ID token (a JWT) that actually identifies the user, filling the gap OAuth leaves. Modern "Sign in with Google/Apple" uses OIDC.

Summary: OAuth = authorization/delegation, OIDC = authentication on top of OAuth, SAML = enterprise SSO (older, XML).

After you authenticate, the system must remember you across requests without re-checking your password each time. Two approaches:

• Sessions — the server creates a session, stores its state, and gives the browser a session ID (usually in a cookie). The server looks up the session on each request. State lives server-side, so revocation is easy.
• Tokens — the server issues a signed token the client presents on each request. A common format is the JWT (JSON Web Token): a base64url-encoded header, a payload of claims (such as user id and an exp expiry), and a signature. The server verifies the signature and trusts the claims without a lookup, so JWTs are self-contained (stateless).

Important points: a JWT is signed, not necessarily encrypted — anyone can read its payload, so never put secrets in it. Tokens must have a short expiry (exp) to limit damage if stolen; refresh tokens let clients get new short-lived access tokens. Because a valid JWT is trusted until it expires, instant revocation is harder than with server sessions.

Not all accounts are equal. Privileged accounts — administrators, root, domain admins, service accounts with broad rights — are the keys to the kingdom and the prime target of attackers. Privileged Access Management (PAM) is the discipline of securing, controlling and monitoring this high-power access.

Core PAM practices:

• Vaulting — privileged credentials are stored in a secure, encrypted vault rather than known to individuals. The vault can rotate passwords automatically and broker logins so admins never see the raw password.
• Just-In-Time (JIT) access — instead of standing admin rights, a user requests elevated access only when needed, for a limited time, after which it is automatically removed. This shrinks the window of attack and enforces least privilege over time.
• Session monitoring/recording — privileged sessions are logged and often recorded for audit.
• Strong MFA on every privileged login.

PAM is essentially least privilege applied with extra rigour to the most dangerous access.

Traditional security trusted anything "inside" the corporate network perimeter. Zero Trust rejects that assumption with a simple maxim: never trust, always verify. There is no trusted inside; every request must be authenticated and authorized on its own merits, regardless of network location.

Key Zero Trust ideas:

• Verify explicitly — use all available signals (user identity, device health, location, behaviour) for every access decision.
• Least-privilege access — grant the minimum needed, per request.
• Assume breach — design as if attackers are already inside; segment and limit lateral movement.

This drives continuous (adaptive) authentication: rather than authenticating once at login and trusting forever, the system keeps assessing risk. A change in device, an unusual location, or odd behaviour raises the risk score and can trigger a step-up challenge (extra MFA) or block the action. Authentication becomes an ongoing, context-aware process, not a one-time gate.

Granting access is only half the job; IAM governance ensures access stays correct and accountable over time. Two pillars:

Access reviews / recertification — periodically (e.g. quarterly), the appropriate managers or resource owners review who has access to what and confirm it is still needed, revoking what is not. This is the main defence against privilege creep and a common compliance requirement. The review proves access is deliberate, not accidental leftovers.

Audit logs — the "accounting" pillar of AAA in practice. Authentication events, authorization decisions, and privileged actions are recorded in tamper-resistant logs. Good logs let you detect anomalies, investigate incidents (who did what, when), and demonstrate compliance. They are only useful if protected from tampering and actually monitored.

Together, reviews keep entitlements clean and logs keep activity accountable — closing the loop on "who can do what, and what did they actually do."

IAM is best understood as one continuous loop rather than a pile of separate features. Trace a single user through it:

1. Identity created — a joiner is provisioned in the directory, placed in groups/roles (RBAC) with least privilege.
2. Authentication — they log in once via SSO to an IdP, proving identity with MFA or a phishing-resistant passkey.
3. Federation — that login flows to apps via SAML or OIDC; OAuth delegates limited resource access where needed; a short-lived token/session carries the result.
4. Authorization — each app decides what is allowed using its model (RBAC/ABAC), continuously re-evaluated under Zero Trust.
5. Privileged actions — any admin power is brokered through PAM with just-in-time, vaulted, recorded access.
6. Governance — access reviews trim entitlements, audit logs record activity, and when the person becomes a mover or leaver, access is adjusted or deprovisioned.

Every concept in this course is one stage of that loop. Keep asking the two governing questions: who is this, really? and what should they be allowed to do, right now?