CISSP IAM: Authorization, Identity Lifecycle, and Authentication Protocols

Introduction

CISSP IAM authorization connects access control models, identity provisioning, and authentication protocols. This lesson covers tasks 5.4, 5.5, and 5.6 of Domain 5, Identity and Access Management (IAM) (13% of the exam, ISC2 exam outline effective 15 April 2024): implement and manage authorization mechanisms, manage the identity and access provisioning lifecycle, and implement authentication systems. The lesson on identification, authentication, and federation explains how a subject proves who it is. This lesson deals with what happens next: what the authenticated identity is allowed to do, how accounts and entitlements are created, changed, reviewed and removed, and which protocols carry authentication and authorization across systems.

Identity-related breaches can result from excessive permissions, orphaned accounts, forgotten service credentials, and badly configured trust between systems, even when the underlying cryptography remains sound. The exam reflects this. Expect scenarios in which you must pick the access control model that fits a requirement, decide which lifecycle step failed, or select the right protocol for a mixed environment.

Learning objectives

After this lesson you can:

1. Compare discretionary, mandatory, role-based, rule-based, attribute-based, and risk-based access control, and choose between them.
2. Explain how access control models relate to least privilege, need to know, and separation of duties.
3. Describe the identity and access provisioning lifecycle: onboarding, changes, review, and offboarding.
4. Manage privileged access, service accounts, and entitlements, including periodic access reviews and the problem of privilege creep.
5. Explain how Kerberos, SAML, OAuth 2.0, OpenID Connect, RADIUS, TACACS+, and LDAP work and where each is used.
6. Select an authentication system for a scenario, including hybrid and cloud environments.
7. Recognize the main attacks against these systems and their mitigations.

1. Authorization mechanisms

Authorization decides which operations an authenticated subject may perform on which objects. It is enforced by a reference monitor concept: a component that mediates every access, cannot be bypassed, is tamper-resistant, and is small enough to be verified. In practice, operating systems, databases, API gateways, and cloud policy engines play this role.

1.1 Discretionary access control (DAC)

In DAC, the owner of an object decides who can access it. Typical examples are file permissions on a Linux or Windows file system, and sharing settings in a collaboration platform.

• Strength: flexible and easy to understand; users handle their own sharing.
• Weakness: security depends on every owner making good decisions. A user can share a sensitive file with the wrong person, and malware running with the user's privileges can misuse the permissions available to that process (a Trojan horse risk). A confused deputy is a different problem: a privileged service is tricked into misusing its own authority on another party's behalf.

1.2 Mandatory access control (MAC)

In MAC, a central authority assigns labels to subjects (clearances) and objects (classifications), and the system enforces rules that owners cannot override. Owners cannot grant access beyond what policy allows. MAC is common in military and intelligence systems, and in hardened operating systems such as those using SELinux.

• Strength: strong protection against both mistakes and malicious insiders who own data.
• Weakness: rigid, costly to administer, and slow to adapt to new business needs.

MAC is typically combined with need to know: a clearance alone is not enough, the subject must also have a legitimate reason to see the specific information (a compartment).

1.3 Role-based access control (RBAC)

In RBAC, permissions are assigned to roles, and users are assigned to roles. A "Payroll Clerk" role carries the permissions needed to run payroll, and an employee in that job receives the role.

• Strength: scales well, maps to job functions, simplifies audits, and supports separation of duties through role conflicts (a person cannot hold both "Create vendor" and "Approve payment").
• Weakness: role explosion appears when organizations create too many narrow roles; poorly designed roles accumulate permissions over time.

Variants include hierarchical RBAC (senior roles inherit junior roles), and constrained RBAC (static and dynamic separation of duties: static prevents holding conflicting roles at all, dynamic prevents activating them in the same session).

1.4 Rule-based access control

Rule-based access control makes decisions through explicit rules, often applied across many subjects. Examples: a firewall rule that allows traffic only from the finance subnet, a policy that blocks access outside business hours, or a rule that denies uploads larger than a given size. Despite the similar name, it is not the same as RBAC. Rules can also refer to identities, groups, or attributes; the useful exam distinction is explicit conditions versus permissions assigned through job roles. These mechanisms can coexist.

1.5 Attribute-based access control (ABAC)

ABAC evaluates attributes of the subject (department, clearance, employment type), the object (classification, owner, project), the action, and the environment (time, location, device posture, threat level) against policies. The standard architecture has a policy decision point (PDP), a policy enforcement point (PEP), a policy information point (PIP), and a policy administration point (PAP).

• Strength: fine-grained, dynamic, and suited to cloud and zero trust, where decisions must account for context.
• Weakness: policies are complex and hard to audit; the quality of decisions depends on the accuracy of the attributes.

1.6 Risk-based and context-aware access control

Risk-based (adaptive) access control adjusts decisions in real time according to risk signals: unfamiliar device, impossible travel, anomalous behavior, sensitivity of the requested action. The result may be allow, require step-up authentication, restrict to read-only, or deny. It is usually an implementation layer on top of ABAC.

1.7 Choosing a model

1.8 Worked example: selecting an authorization model

Scenario. Northwind Logistics is building a shipment portal. Requirements: (1) warehouse staff may update only shipments for their own site; (2) customer service agents may view all shipments but never see customs values; (3) contractors may access the portal only from managed devices; (4) auditors must be able to demonstrate in one report who can do what; (5) the company wants to avoid a separate role for every site and function combination.

Reasoning.

1. Requirement 4 (simple audit) and the job-function nature of requirement 2 suggest RBAC as the backbone: roles such as Warehouse Operator, Service Agent, Auditor.
2. Requirement 1 (own site) and requirement 5 (avoid role explosion) show that pure RBAC would need one role per site. Adding an attribute (site) and evaluating it in policy gives ABAC behavior: the Warehouse Operator role is combined with the condition user.site == shipment.site.
3. Requirement 3 depends on device posture, an environmental attribute, so it is an ABAC or risk-based condition.
4. Requirement 2 (hide customs values) is a field-level restriction, enforced as content-dependent control in the application.

Solution. A hybrid: RBAC for coarse permissions and audit, ABAC conditions for site and device, and field-level controls in the application.

Why the alternatives are weaker. DAC leaves site boundaries to individual users. MAC is too rigid and has no real classification hierarchy here. A role-only design can create dozens of site-specific roles; a managed-device condition requires an additional policy mechanism. Pure ABAC is possible but makes the "who can do what" report much harder than a role listing.

2. Implementing and managing authorization

These controls put the secure design and reference monitor principles into practice.

2.1 Core principles in practice

• Least privilege: each identity has only the permissions required. Implement it through narrow roles, time-bound grants, and removing unused permissions.
• Need to know: applies to information; implemented through groups per project, compartments, and data classification.
• Separation of duties (SoD): split critical tasks among people. Design role conflict matrices, and use dual control when two people must act together (two key custodians).
• Default deny: authorization systems should refuse requests that no rule explicitly permits.
• Job rotation and mandatory vacations: detective measures that reveal fraud because another person takes over the process.

2.2 Managing privileged access

Privileged accounts (domain admins, root, database administrators, cloud tenant owners, break-glass accounts) carry outsized risk. Controls include:

• Privileged access management (PAM): vaulting credentials, session brokering and recording, approval workflows, automatic rotation after use.
• Just-in-time (JIT) elevation: privileges granted for a limited time and removed automatically.
• Separate accounts: administrators use a standard account for email and browsing and a distinct admin account for administrative tasks, ideally from a privileged access workstation.
• Tiered administration: domain controllers (tier 0), servers (tier 1), and workstations (tier 2) have separate admin accounts so that a compromise at a lower tier does not expose the higher one.
• Break-glass accounts: sealed, monitored, tested emergency accounts.

2.3 Entitlement management and access reviews

An entitlement is a specific permission or group membership. Entitlement management tracks who has what, why, and who approved it. Access reviews (recertification) ask managers and data owners to confirm that each assignment is still needed. Good practice:

• Set review frequency according to risk, obligations, and change events; quarterly privileged reviews and annual ordinary-access reviews are examples, not universal requirements.
• Present reviewers with understandable descriptions, not cryptic group names.
• Define an escalation and expiry policy for unanswered reviews; do not silently approve access. Coordinate revocation of critical service access to avoid unplanned outages.
• Record the outcome as audit evidence.

Privilege creep (also called authorization creep) happens when employees who change jobs keep their old permissions and accumulate new ones. Access reviews and a strict "move means re-request" process are the cure.

3. The identity and access provisioning lifecycle

The lifecycle of an identity follows the person, device, or service from creation to removal. Organizations typically describe it as joiner, mover, leaver (JML).

3.1 Account provisioning (joiner)

1. Request and authorization: HR or the sponsoring manager triggers the creation. The authoritative source for employees is usually the HR system. For contractors it is the sponsor, with an end date.
2. Identity proofing: verification of real-world identity before credentials are issued (covered in the previous lesson).
3. Account creation: automated provisioning through an identity governance and administration (IGA) tool, using SCIM or connectors, creates accounts in directories and applications.
4. Role assignment: birthright access (email, intranet) is granted automatically; additional access requires approval.
5. Credential delivery: initial credentials or enrollment of authenticators is done securely, and the user must set their own secrets or enroll MFA.
6. Agreement and training: the user accepts acceptable use policies and completes security awareness training.

Automated provisioning lowers errors and delays, and creates a consistent audit trail. Manual provisioning is slower and more error-prone, but may be needed for legacy systems.

3.2 Account modification (mover)

Role changes, department transfers, promotions, and long leaves of absence all affect access. The principle is to remove old access first or at the time of transfer, then grant new access. Triggers can come from HR events. Without them, privilege creep appears.

3.3 Deprovisioning (leaver)

Termination must remove access quickly and completely:

1. Disable the account immediately upon termination (or earlier for hostile departures); do not delete it at once because investigations and data ownership may require it.
2. Revoke sessions, tokens, VPN certificates, API keys, and remote access across applications. Account disablement alone may leave issued tokens or application sessions usable. Retire device enrollments and wipe corporate data only when authorized, preserving evidence and respecting personal-device boundaries.
3. Collect physical assets: badges, laptops, tokens.
4. Reassign data and mailboxes to a manager or archive them according to retention rules.
5. Remove entitlements and group memberships; rotate shared secrets the person knew.
6. Delete the account after the retention period defined in policy.
7. Reconcile: compare the list of active accounts against HR records to catch missed systems, especially SaaS applications outside central provisioning.

3.4 Service accounts and non-human identities

Service accounts, API keys, certificates, and workload identities need the same lifecycle discipline as people: an owner, a purpose, least privilege, rotation, and decommissioning. Prefer managed identities and short-lived tokens over long-lived passwords stored in code or configuration. Secrets belong in a secrets manager.

3.5 Worked example: finding the lifecycle failure

Scenario. Helix Pharma discovers that a financial analyst, Jordan, who moved from accounts payable to treasury eight months ago, can still create vendors and now also releases wire transfers. An audit also shows that 14 accounts of former contractors are active, three of them with VPN access, and that the service account svc-etl has a password unchanged for six years and domain-wide read access.

Reasoning, step by step.

1. Jordan's situation is privilege creep caused by a failed mover process: old access was never removed. It also creates a SoD violation (create vendor plus release payment).
2. The contractor accounts are orphaned or not deprovisioned: the leaver process did not cover contractors with an end date, or the connector to the VPN failed.
3. svc-etl is a non-human identity without an owner, rotation, or least privilege.

Solution.

• Immediately remove the conflicting entitlements, then review the transactions Jordan performed during the overlap for fraud indicators.
• Disable the contractor accounts, investigate whether the VPN accounts were used after contract end, and add sponsor-based expiry dates to every contractor account.
• Assign an owner to svc-etl, move its credential to a vault with rotation, narrow the permissions to the required data sources, and monitor its use.
• Implement HR-triggered mover workflows, periodic access recertification (quarterly for financial roles), and an SoD rule in the IGA tool.

4. Authentication systems

Authentication systems carry credentials and assertions between users, clients, and services. Know the purpose, the main components, and the typical weaknesses of each.

4.1 Kerberos

Kerberos is a ticket-based, symmetric-key protocol used in Windows Active Directory and many Unix environments. Its trusted third party is the Key Distribution Center (KDC), which has two logical services: the Authentication Service (AS) and the Ticket Granting Service (TGS).

1. The client authenticates to the AS and receives a Ticket Granting Ticket (TGT).
2. The client presents the TGT to the TGS to request a service ticket for a specific service.
3. The client presents the service ticket to the service, which can verify it without contacting the KDC.

Important characteristics:

• Passwords are never sent over the network; tickets are encrypted with keys derived from secrets.
• Time synchronization is required: excessive clock skew causes authentication failures (five minutes is a common configurable tolerance). Replay defenses also depend on authenticators and replay caches; synchronized clocks alone do not prevent replay.
• The KDC is a single point of failure and a very high-value target; deploy redundant KDCs and protect them as tier 0 assets.
• Known attacks: pass-the-ticket, Kerberoasting (requesting service tickets for accounts with service principal names and cracking them offline), golden ticket (forged TGTs after compromising the krbtgt secret), and silver ticket (forged service tickets). Mitigations: long random service account passwords or managed service accounts, resetting krbtgt twice during coordinated domain recovery with replication and ticket-lifetime waits between resets, strong encryption types, and monitoring. Follow Microsoft recovery guidance; two immediate resets can disrupt authentication.

4.2 SAML

The Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for exchanging authentication and authorization assertions between an identity provider (IdP) and a service provider (SP). It is widely used for enterprise single sign-on to SaaS applications through the browser.

• The IdP issues a signed assertion about the user.
• The SP validates the signature, audience, validity window, and conditions.
• Weaknesses: XML signature wrapping, unsigned or poorly validated assertions, long-lived assertions, and misconfigured trust. Validate signatures, restrict audiences, and use short lifetimes.

4.3 OAuth 2.0

OAuth 2.0 is an authorization framework: it lets a client application obtain limited access to a resource on behalf of a resource owner, without sharing the owner's password. Key roles are the resource owner, client, authorization server, and resource server. The client receives an access token (and sometimes a refresh token) with defined scopes.

• Use the authorization code flow with PKCE for web, mobile, and single-page applications.
• Use client credentials for service-to-service access.
• Follow RFC 9700: do not use the resource owner password credentials grant. Prefer code flow with PKCE over implicit token delivery, including when modernizing existing clients.
• Risks: token theft, overly broad scopes, open redirect or redirect URI mismatches, consent phishing (a malicious application tricks users into granting access). Mitigate with strict redirect URI matching, short token lifetimes, scope minimization, and application consent governance.

4.4 OpenID Connect (OIDC)

OpenID Connect is an identity layer built on top of OAuth 2.0. It adds an ID token (a signed JSON Web Token) that identifies the subject and issuer and describes the authentication event; authentication-time and method claims depend on the requested flow and profile. Validate issuer, audience, signature, expiry, and applicable nonce checks. An ID token is intended for the client, not as a substitute for an API access token. OIDC is the usual choice for modern web and mobile single sign-on and for consumer identity.

Exam memory aid: OAuth is about authorization (what an app may access), OIDC adds authentication (who the user is), and SAML is the enterprise XML standard for the same type of federation.

4.5 RADIUS, TACACS+, and Diameter

These are AAA protocols used to centralize authentication, authorization, and accounting for network access.

802.1X with EAP (Extensible Authentication Protocol) is the framework for port-based network access control. A supplicant (client) authenticates through an authenticator (switch or access point) to an authentication server (usually RADIUS). Stronger EAP methods (EAP-TLS with client certificates) are preferred over password-based methods because they avoid reusable user passwords. Validate the authentication server certificate and trust configuration; a device certificate demonstrates possession of a credential, not continuous device compliance.

4.6 LDAP

The Lightweight Directory Access Protocol (LDAP) reads directory data and performs authentication binds. Use LDAPS or require successful StartTLS with certificate validation before sending simple-bind credentials; do not fall back to plaintext. Restrict anonymous binds where unnecessary and escape untrusted LDAP filter or distinguished-name values with appropriate libraries to prevent injection.

4.7 Worked example: choosing authentication systems for a hybrid environment

Scenario. Alder Bank has an on-premises Active Directory, a cloud HR SaaS application, a customer mobile app calling internal APIs, a corporate Wi-Fi network, and a team that administers 400 network devices. Requirements: employees sign in once for internal and SaaS applications; the mobile app must call APIs on behalf of customers without storing their password; Wi-Fi must be limited to managed devices; and network administrators must be restricted to specific commands, with every command logged.

Reasoning.

1. Internal Windows resources already use Kerberos with Active Directory.
2. For the SaaS HR application, employees need federated SSO. A SAML (or OIDC) federation between the corporate IdP and the SaaS provider avoids new passwords.
3. The mobile app needs delegated authorization to APIs: OAuth 2.0 (authorization code with PKCE) with OIDC for sign-in.
4. Wi-Fi limited to managed devices: 802.1X with EAP-TLS and RADIUS, using device certificates.
5. Per-command control and logging for network devices: TACACS+ with protected transport, because separate authorization and accounting support per-command decisions and records. Prefer RFC 9887 TLS 1.3 where supported; legacy obfuscation is insufficient.

Why other choices are less suitable. RADIUS is less naturally suited to this per-command administration requirement; confidentiality depends on its transport profile rather than the protocol name alone. SAML in a mobile API scenario is clumsy; OAuth is designed for it. Plain LDAP binds would send credentials without protection unless wrapped in TLS.

5. Mini case study

Scenario. Corvid Retail has 4,000 employees. An internal review shows: (a) the sales operations team has 60 distinct roles, most with one or two users; (b) when staff move to another department, access is added but rarely removed; (c) former temporary seasonal workers keep active accounts for months; (d) the e-commerce platform uses a single service account with administrator rights for all integrations, its password in a configuration file; (e) a partner application requests OAuth scopes for "full mailbox access" and several employees approved it; (f) store managers can approve their own refund requests in the point-of-sale system.

Task. Identify the issues and propose corrective actions in priority order.

Commented solution.

1. Refund self-approval (f) is a direct SoD failure with fraud potential. Remove the conflict, require dual approval, and review past refunds. This is first because it enables immediate financial loss.
2. Overprivileged service account with a plaintext password (d) exposes the whole platform. Move credentials to a vault, split the account into one identity per integration with least privilege, and rotate the secret.
3. Malicious or risky OAuth consent (e): revoke the partner application's tokens, investigate what data it accessed, and restrict user consent so that high-risk scopes require administrator approval.
4. Seasonal worker accounts (c): set automatic expiry based on contract end dates, reconcile accounts against HR records, and disable the existing orphaned ones.
5. Privilege creep (b): trigger mover workflows from HR data, remove old entitlements at transfer, and run quarterly recertification for sensitive systems.
6. Role explosion (a): perform role mining, consolidate to a manageable set of roles, and use attributes (region, store) for variations instead of new roles.

The order follows risk: active fraud and credential exposure, then data exposure from third parties, then lifecycle process fixes, then structural improvements.

6. Common pitfalls and exam tips

• Exam tip: when a question stresses "owners decide", think DAC. When it stresses labels and "owners cannot change", think MAC. When it stresses job functions, think RBAC. When it stresses context (time, device, location), think ABAC or risk-based.
• Pitfall: confusing rule-based access control with role-based access control. Rules express explicit conditions; role assignments organize permissions by job function. Rules may include identity-related conditions.
• Exam tip: the best answer to privilege creep is a combination of mover process, periodic access review, and removal of old entitlements, not just a one-time cleanup.
• Exam tip: at termination, disable first, delete later according to retention requirements.
• Pitfall: treating service accounts as an afterthought. Exams reward answers that assign ownership, vault secrets, and minimize permissions.
• Exam tip: Kerberos needs synchronized clocks and a protected KDC; password hashes are not sent across the network.
• Exam tip: OAuth = authorization; OIDC = authentication on top of OAuth; SAML = XML federation.
• Exam tip: TACACS+ fits device administration and per-command authorization; RADIUS fits network access. Verify transport security: legacy TACACS+ obfuscation is not modern encryption.
• Pitfall: assuming SSO removes the need for authorization. SSO answers who, not what they may do.
• Exam tip: when two answers both seem correct, choose the one that addresses root cause with a preventive and sustainable control, and that involves the data owner or business for access decisions.

For operational evidence of account changes and privileged sessions, continue with protected logging and investigations.

Key terms

• Reference monitor: conceptual component that mediates every access.
• DAC / MAC / RBAC / ABAC: owner-based, label-based, role-based, and attribute-based access control.
• Role explosion: too many fine-grained roles to manage.
• SoD: separation of duties; dual control: two people must act together.
• Privilege creep: accumulation of permissions over time.
• JML: joiner, mover, leaver lifecycle.
• IGA: identity governance and administration.
• PAM / JIT: privileged access management and just-in-time elevation.
• KDC / TGT: Kerberos key distribution center and ticket granting ticket.
• IdP / SP: identity provider and service provider (relying party).
• OAuth scope: limit of the access granted to a client.
• ID token: signed OIDC token describing the authentication event.
• 802.1X / EAP: port-based network access control and its authentication framework.

Summary checklist

• I can choose between DAC, MAC, RBAC, rule-based, ABAC, and risk-based models for a scenario.
• I can apply least privilege, need to know, and separation of duties through concrete controls.
• I can describe the joiner, mover, and leaver steps and the order of disable and delete.
• I can explain access recertification and how it stops privilege creep.
• I can manage privileged and service accounts with vaults, JIT, and ownership.
• I can explain how Kerberos works and name its main attacks.
• I can distinguish SAML, OAuth 2.0, and OpenID Connect.
• I can pick RADIUS, TACACS+, LDAP, or 802.1X for network and directory scenarios.

Official sources

• ISC2 CISSP exam outline: https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline (opens in a new tab)
• NIST SP 800-63-4, Digital Identity Guidelines (final, July 2025): https://pages.nist.gov/800-63-4/ (opens in a new tab)
• NIST SP 800-162, Guide to Attribute Based Access Control: https://csrc.nist.gov/pubs/sp/800/162/upd2/final (opens in a new tab)
• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final (opens in a new tab)
• IETF RFC 4120 (Kerberos V5): https://www.rfc-editor.org/rfc/rfc4120 (opens in a new tab)
• IETF RFC 9700, OAuth 2.0 Security Best Current Practice: https://www.rfc-editor.org/rfc/rfc9700.html (opens in a new tab)
• OpenID Connect Core 1.0: https://openid.net/specs/openid-connect-core-1_0.html (opens in a new tab)
• IETF RFC 8907, legacy TACACS+ and obfuscation limits: https://www.rfc-editor.org/rfc/rfc8907.html (opens in a new tab)
• IETF RFC 9887, TACACS+ over TLS 1.3: https://www.rfc-editor.org/rfc/rfc9887.html (opens in a new tab)
• IETF RFC 9765, RADIUS/1.1: https://www.rfc-editor.org/rfc/rfc9765.html (opens in a new tab)
• Microsoft AD forest recovery, resetting krbtgt: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password (opens in a new tab)