D5 — Access Control Models & Federation
DAC/MAC/RBAC/ABAC as the practical mechanisms behind D1's theoretical models, plus SAML and OAuth/OIDC federation vocabulary — the domain where Keycloak-style IAM experience converts fastest into CISSP terminology.
Learning Objectives
- → Distinguish DAC, MAC, RBAC, and ABAC by who assigns access and on what basis
- → Explain the SAML federation flow: which entity asserts identity and which consumes the assertion
- → Name the core OAuth 2.0 / OIDC roles and explain how that vocabulary differs from SAML's IdP/SP pair
- → Apply least-privilege reasoning to choose the right access-control model for a scenario, not just recall definitions
Lesson 3 covered Bell-LaPadula, Biba, and Clark-Wilson — theoretical models describing what a secure information flow looks like. This lesson covers the practical mechanisms real systems use to actually make and enforce access decisions day to day: the four access control models, and the two dominant federation protocol families. If you've configured roles, groups, or SSO in a system like Keycloak, you've already been implementing several of these — this lesson maps that experience onto CISSP's exact vocabulary.
The four access control models
| Model | Who decides access | Basis for the decision | Typical example |
|---|---|---|---|
| DAC (Discretionary) | The resource owner | Owner's own judgment, case by case | A file owner clicking "share" with a specific person |
| MAC (Mandatory) | The system/policy, centrally | Classification level, no owner override | Bell-LaPadula-style classified systems |
| RBAC (Role-Based) | Whoever assigns roles | Role membership, not individual identity | "Billing-Admin" role grants access to billing tools |
| ABAC (Attribute-Based) | A policy engine | Attributes of user, resource, and context (department, device posture, time of day) | "Allow if user.department == Finance AND device.managed == true" |
DAC is the most flexible and the least centrally controllable — because each owner decides independently, there's no single point to audit or enforce consistent policy, which is exactly why it doesn't scale to security-sensitive environments on its own. MAC is the opposite extreme: no discretion at all, which is why it maps directly onto Bell-LaPadula/Biba-style classified systems from Lesson 3. RBAC is the most common enterprise default — it also directly enforces Clark-Wilson's separation-of-duties principle, since a role definition can guarantee that "Transaction-Initiator" and "Transaction-Approver" are never the same person. ABAC is the finest-grained and most context-aware, which is why it underpins modern zero-trust architectures where "is this user in this role" isn't specific enough — you also need to know from what device, at what time, accessing what sensitivity of resource.
Federation: SAML
SAML (Security Assertion Markup Language) is the older, XML-based federation standard still common in enterprise SSO:
- The Identity Provider (IdP) authenticates the user directly — this is the only party that ever sees the user's actual credentials — and issues a signed assertion stating who the user is.
- The Service Provider (SP) trusts and consumes that assertion to make its own access decision, without ever handling the user's password itself.
A Keycloak realm acting as SSO for several downstream applications is functioning as the IdP; each downstream application is an SP.
Federation: OAuth 2.0 and OIDC — a different vocabulary entirely
OAuth 2.0 is fundamentally about authorization — granting a client delegated access to a resource via tokens — not identity by itself. Its roles:
- Resource Owner — the user who owns the data
- Client — the application requesting access
- Authorization Server — issues access tokens
- Resource Server — hosts the protected data and accepts the token
OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0, introducing an ID Token (a signed JWT carrying identity claims) alongside the access token. In OIDC terms, the Authorization Server doubles as the OpenID Provider, and the Client is also called the Relying Party — the closest OIDC analogues to SAML's IdP and SP, respectively.
This is a specific, frequently tested confusion point: SAML vocabulary (IdP / SP) and OAuth/OIDC vocabulary (Authorization Server / Resource Server / OpenID Provider / Relying Party) are not interchangeable, even though they solve overlapping problems. A scenario question that mixes them — "the Relying Party asserts identity" — is testing whether you notice the vocabulary doesn't belong to the protocol described.
The CISSP mindset: manager vs technician
A new internal integration needs to call an existing API on behalf of users. The fastest working configuration is an OAuth client with a broad
adminscope.
The technician answer: grant the admin scope — it unblocks the integration immediately, and scope refinement can happen "later" if it becomes a problem.
The manager (CISSP) answer: match the grant to the actual need — request only the specific scopes the integration uses (an ABAC/least-privilege-style attribute-scoped grant), and if the integration only needs a subset of what a given role would provide, that's a signal the access control model itself deserves scrutiny, not just the scope string. "It works" is not the same question as "does this grant match what least privilege requires" — and CISSP scenario questions are built to separate the two, the same way Lesson 1's finding-a-bug scenario separated "it's patched" from "the governance gap is addressed."
A hospital's EHR system grants access to a patient's chart based on a real-time evaluation of: the requester's department, whether the requester is currently assigned to that patient's care team, and whether the request originates from a hospital-managed device. Which access control model is this, and why wouldn't RBAC alone achieve the same result?
Which model is this, and why wouldn't RBAC alone achieve the same result?
A user logs into a Keycloak-backed SSO portal, then clicks a link to a separate internal reporting application. They are not prompted to log in again, and the reporting application shows their correct name and department without ever asking for their password. Identify the IdP and SP in this scenario, and explain what specifically allows the reporting application to trust who the user is without seeing their credentials.
What are the IdP and SP here, and what allows the SP to trust the user's identity without seeing credentials?
A colleague describes an OIDC login flow like this: \"the Relying Party authenticates the user and asserts their identity to the OpenID Provider, which then grants access.\" Identify what's backwards in this description and restate it correctly.
What's backwards in this description, and what's the correct version?