Access control models and mechanisms define how organisations decide who can access what, and how they enforce those decisions. When a business integrates identity as a third-party service—such as letting employees log in with their Google or LinkedIn accounts—it must choose a model that balances security, usability, and governance. For CISSP candidates, understanding these models is critical because the exam tests your ability to select the right access control approach for a given scenario and to recognise the risks of misconfiguring identity federation.
Jump to a section
A simple way to picture Access Control Models and Mechanisms
A corporate headquarters visitor badge acts as a temporary access credential, authorising entry based on verified external identity. When you arrive at the lobby, you present a government-issued driving licence or passport—an identity token issued by a trusted external authority. The receptionist validates the licence against an internal list of expected visitors, then prints a photo badge. That badge specifies your name, the floor or zone you may visit, and an expiration time after which it becomes invalid.
This process mirrors third-party identity integration and access control models precisely. The driving licence is the external identity provider (IdP) token. The receptionist is the security assertion that maps the external identity to an internal subject. The badge is the local access credential provisioned with attributes from the IdP. The zones—general office, executive floor, server room—represent resources with different sensitivity labels. A regular employee badge might grant Role-Based Access Control (RBAC): 'Marketing Staff' can enter only floors 2 and 3. A visitor badge is inherently Discretionary Access Control (DAC) with an owner controlling access. Meanwhile, the server room enforces Mandatory Access Control (MAC): only individuals with a 'Top Secret' clearance label and a valid need-to-know can enter, regardless of their role. Context-aware rules—like badge expiry after hours or requiring a chaperone—demonstrate Attribute-Based Access Control (ABAC). The entire visit is logged, achieving accountability.
Access control is the heart of information security. It ensures that only authorised individuals or systems can reach resources—files, applications, buildings—and that every access attempt is logged. The process rests on three pillars, often called AAA: identification (claiming an identity), authentication (proving it), and authorisation (determining what you are allowed to do). A fourth, accountability, ties actions back to a user through audit trails.
Access control models are the blueprints that define how authorisation decisions are made. The four classic models are:
Discretionary Access Control (DAC): Every resource has an owner, and the owner decides who gets access. Think of a shared folder where the creator sets permissions for others. It is flexible but risky because the owner might accidentally grant too much access.
Mandatory Access Control (MAC): The system, not the owner, enforces access based on security labels. Every subject (user, process) gets a clearance label and every object (file, directory) gets a classification label. Access is only granted if the clearance dominates the classification. MAC is used in military and government environments where data sensitivity is absolute.
Role-Based Access Control (RBAC): Permissions are assigned to roles, not to individual users. A user acquires permissions by being assigned a role, such as 'Accounts Payable Clerk' or 'Radiologist'. This simplifies administration in large organisations and reduces the risk of orphaned permissions when people change jobs.
Attribute-Based Access Control (ABAC): Decisions use policies that evaluate attributes of the user, the resource, the action, and the environment. For example, 'allow read access only if user.department = “Finance” and resource.classification = “Confidential” and time.hour < 18:00'. ABAC is the most flexible model and is often implemented with XACML (eXtensible Access Control Markup Language).
Beyond these models, access control mechanisms enforce the rules. An Access Control List (ACL) is a table attached to a resource that lists which subjects can access it and with what permissions. A capability table is the opposite: each subject holds a token (capability) that lists the resources it may access. Cloud platforms like Amazon Web Services use IAM policies (JSON documents) that function as both ACLs and capability-like permission sets.
Now, integrate identity as a third-party service. In the past, every system managed its own directory of user accounts and passwords. That meant employees had to remember dozens of separate credentials, and IT struggled with provisioning and deprovisioning. Federated identity management solves this by letting one organisation (the identity provider, IdP) vouch for a user’s identity to another organisation (the service provider, SP). The user authenticates once to the IdP and then gains access to multiple SPs without re-entering credentials. This is the foundation of Single Sign-On (SSO).
When a business decides to use a third-party identity—like allowing customers to log into its website with Facebook or employees signing into a SaaS HR tool with Microsoft Entra ID—it is integrating identity as a service. The protocols that make this possible:
SAML (Security Assertion Markup Language): An XML-based standard for exchanging authentication and authorisation data between an IdP and an SP. The IdP sends a SAML assertion (a signed XML token) containing user attributes and authentication information. SAML provides both authentication and attribute sharing.
OAuth 2.0: A delegation protocol that lets a service act on a user’s behalf without ever seeing the user’s password. For example, a photo-printing app can access your Google Photos library with your consent, using an access token rather than your Google password. OAuth is about authorisation, not authentication.
OpenID Connect (OIDC): A simple identity layer on top of OAuth 2.0 that adds authentication. An OIDC IdP provides an ID token (a JSON Web Token) that contains user claims and proves that the user has authenticated. It is often preferred for modern web and mobile apps.
The trust relationship between an IdP and an SP must be established in advance. The two parties exchange cryptographic keys or public metadata endpoints so the SP can verify that an incoming assertion really came from the trusted IdP. Once trust is set, identity mapping rules decide how external attributes become local permissions. A claim like 'group: managers' from Microsoft Entra ID might be mapped to the role 'Approver' inside the SaaS app, effectively creating an RBAC enforcement point based on third-party identity data.
This approach replaces the messy, insecure practice of creating duplicate local accounts for every application. It reduces password fatigue, lowers the risk of credential theft, and enables centralised access governance. It also allows for just-in-time provisioning, where an account is created in the SP automatically the first time a user logs in, based on assertions from the IdP.
Establish an identity provider (IdP) that will serve as the central source of truth
Select a service like Microsoft Entra ID, Okta, or Google Identity to manage user accounts, groups, and credentials. This IdP becomes the authoritative directory for all users who will access integrated applications. Without this single control point, access drifts out of sync and policy enforcement becomes fragmented.
Configure the service provider application to trust the IdP
In the application’s settings, provide the IdP’s metadata URL or upload its public certificate. This exchange allows the app to cryptographically verify that incoming authentication assertions genuinely come from the trusted IdP. The trust relationship is foundational; if it is misconfigured, the service will reject valid users or, worse, accept forged tokens.
Define attribute mapping and claim rules
Decide which user attributes (email, department, group membership, clearance level) the IdP will pass in its assertions. Map those claims to local roles or permissions inside the service provider. For example, an IdP group 'Managers' could be mapped to the local 'Approver' role. This step translates external identity into authorisations that the application’s access control model—often RBAC or ABAC—can enforce.
Enforce the chosen access control model at the application layer
Within the service provider, ensure the received claims are used to make access decisions consistent with the model. If using MAC, the application must evaluate label dominance; if RBAC, it must check role-permission assignments. The model determines whether a user can only view data, edit it, or perform admin functions. This step prevents privilege escalation by enforcing granular permissions.
Test the full authentication and authorisation flow
Simulate logins from user personas with different attributes. Verify that a ‘read-only’ user cannot edit records, that an expired session forces re-authentication, and that an unprivileged user receives a proper denial rather than a cryptic error. End-to-end testing confirms that the IdP, attribute mapping, and application enforcement work together correctly under the chosen access control model.
Implement continuous monitoring and access reviews
Enable logging for both the IdP and the service provider, then aggregate logs into a security information and event management (SIEM) system. Schedule periodic access reviews to recertify that users still need their assigned roles. This maintains accountability and ensures that the integrated identity solution does not suffer from stale permissions as people change jobs or projects end.
A mid-sized consultancy adopts a software-as-a-service (SaaS) expense management application to streamline travel reimbursements. The firm already uses Microsoft Entra ID to manage employee identities, enforce multi-factor authentication, and control access to corporate resources. Rather than creating separate logins for every employee inside the expense tool, the IT administrator integrates the SaaS as a service provider that trusts Entra ID as the identity provider.
The administrator begins by registering the expense application inside the Entra ID console, where it becomes a managed enterprise application. She selects SAML 2.0 as the single sign-on protocol because the SaaS vendor supports it and because SAML allows granular attribute passing. Next, she configures the SAML endpoint URL provided by the vendor and uploads the vendor’s public certificate to establish trust in both directions.
Then comes attribute mapping. Entra ID can send user attributes like email address, display name, and group membership inside the SAML assertion. The administrator maps the Entra ID group 'Expense-Approvers' to the role 'Approver' in the expense tool, and the group 'All-Employees' to the role 'Submitter'. This is RBAC enforced through identity federation: no need to manually manage roles inside the SaaS.
When a user first tries to open the expense app, the browser is redirected to Entra ID’s login page. The user authenticates, optionally completes an MFA challenge, and Entra ID generates a digitally signed SAML assertion. The assertion is posted back to the expense application. The app validates the signature, extracts the role attribute, and creates or updates the user’s profile with the correct permissions. From the user’s perspective, they simply clicked an icon and were in—no extra credentials.
The benefits cascade: onboarding a new starter merely requires adding them to the relevant Entra ID groups; the next time they access the expense tool, they are automatically provisioned with the right access. Decommissioning a leaver works in reverse—removing them from the internal groups instantly cuts their third-party application access. The security team gains centralised audit logs showing who accessed what, even across federated boundaries, because authentication events are captured at the IdP and fed to the SIEM. The expense tool vendor never sees a password; all they receive is an assertion confirming the user’s identity and attributes.
This scenario is repeated for every SaaS tool the business adopts: HR, CRM, collaboration suites. The architecture scales effortlessly because the identity management stays at the centre, and each new application becomes just another downstream service provider. The access control model—RBAC, in this case—remains consistent, enforced by the same identity provider and the same group-claim mappings.
CISSP exam questions on access control models and mechanisms are notorious for testing subtle distinctions. You will not be asked to recite definitions; instead, you will be given a business scenario and asked to select the best model or mechanism. The most common trap: mixing up the four models.
Questions often present an environment with classified documents and mandatory rules. The correct answer is always MAC, because MAC is the only model where the system enforces a policy that individual users cannot override. If a scenario says 'the data owner decides who has access,' the answer is DAC. If the scenario describes permissions based on job functions, with phrases like 'accountant,' 'engineer,' or 'manager,' think RBAC. If the question mentions time-of-day, location, clearance level, and department all at once, ABAC is the model because it evaluates multiple attributes.
A second family of questions revolves around identity federation and third-party services. The exam will test your ability to distinguish between protocols:
SAML: used for enterprise SSO, carries authentication and attribute information in XML assertions, works well with browser-based web apps.
OAuth 2.0: used for delegated authorisation, grants limited access to a resource without sharing passwords. The exam often tricks candidates by calling OAuth an authentication protocol; it is not—it is an authorisation framework. OIDC adds authentication on top of it.
OpenID Connect (OIDC): adds user identity verification on top of OAuth 2.0, provides an ID token in JWT format, preferred for modern mobile and single-page apps.
Expect questions that require you to match protocol to use case. For example: 'A mobile app needs to let users sign in with their Google account and retrieve profile data. Which protocol is best?' The answer is OIDC, because it provides authentication (proving identity) and authorisation (access to profile) via OAuth 2.0 with an ID token.
Another trap: candidates confuse federation with simple SSO. SSO is a user experience—one login, many apps—while federation is the underlying trust structure that makes cross-domain SSO possible. A question might say, 'Company A wants to let partners from Company B log into Company A’s portal using their own credentials.' That is federation through an IdP-Trust relationship.
You will also see questions about identity mapping and provisioning. Look for words like 'claims,' 'assertions,' and 'just-in-time provisioning.' The exam expects you to know that claims are attributes (email, role, department) carried inside a security token, and that an SP may use those claims to make local authorisation decisions.
Finally, do not overlook the accountability side. The AAA framework—identification, authentication, authorisation, and accountability—is a favourite. A scenario might describe logging all access attempts and ask which security service component it illustrates. That is accountability.
Key exam patterns to memorise:
MAC = system-enforced labels, no user discretion. Used in military/intelligence.
DAC = owner sets permissions. Used in shared folders, Unix file permissions.
RBAC = permissions bundled into roles. Used in large enterprises for manageability.
ABAC = attributes of subject, object, and environment evaluated at runtime. Most flexible.
SAML = XML, enterprise SSO, browser profile.
OAuth = delegated authorisation, access tokens, no authentication on its own.
OIDC = authentication + authorisation, JWT ID tokens.
Federation = trust between IdP and SP, enabling identity portability.
MAC enforces access based on immutable security labels assigned by the system; no user, not even the data owner, can override these labels.
DAC grants the data owner complete control over who accesses their resources, making it flexible but prone to permission creep and error.
RBAC assigns permissions to roles, not individuals, which drastically simplifies administration and ensures access changes happen automatically when a user's role changes.
ABAC evaluates multiple attributes—user, resource, action, environment—at the time of request, enabling dynamic, context-aware access decisions.
Federated identity allows an organisation to trust an external identity provider to authenticate users, replacing locally managed credentials per application with a single trusted source of identity.
An access control list (ACL) is an object-resident permission table, while a capability is a subject-resident token that lists accessible resources; both are enforcement mechanisms, not models.
SAML provides XML-based authentication and attribute assertions for enterprise SSO, OAuth 2.0 provides delegated authorisation, and OpenID Connect adds authentication on top of OAuth, producing JWT ID tokens.
Accountability, the fourth pillar of AAA, is achieved through comprehensive logging and auditing of every access attempt, ensuring that all actions can be traced back to an authenticated user.
These come up on the exam all the time. Here's how to tell them apart.
MAC (Mandatory Access Control)
Access decisions are system-enforced based on security labels and clearances
Users cannot change permissions on any object, even objects they created
Suited for environments requiring absolute separation of sensitivity levels
DAC (Discretionary Access Control)
Access decisions are made by the object owner, who can grant or revoke access at will
Owners have full discretion to share resources, which may lead to overly permissive access
Common in personal file sharing and collaborative platforms where flexibility is prioritised
RBAC (Role-Based Access Control)
Permissions are bundled into roles and assigned to users based on job function
Simplifies administration for large enterprises with well-defined job titles
Cannot easily handle complex, dynamic rules like time-of-day or location restrictions
ABAC (Attribute-Based Access Control)
Permissions are determined by evaluating attributes of the user, resource, and environment
Handles complex, context-aware policies but requires more initial configuration and testing
Can incorporate roles as one type of attribute, making it a superset of RBAC in practice
SAML (Security Assertion Markup Language)
An XML-based open standard for exchanging authentication and authorisation data
Provides both authentication and attribute sharing through signed assertions
Optimised for enterprise browser-based SSO scenarios
OAuth 2.0 (Open Authorization)
An authorisation delegation framework, not an authentication protocol
Uses access tokens (often JWT) to grant limited access to resources without sharing credentials
Widely used for API and mobile app authorisation, often combined with OpenID Connect for authentication
Access Control List (ACL)
A list attached to an object that specifies which subjects can access it and with what rights
Object-centric view of permissions; you check the list to see who can read a file
Common in file systems and network devices (router ACLs)
Capability Table
A list held by a subject that enumerates all objects the subject can access
Subject-centric view of permissions; the user carries their own access tokens
Less common than ACLs but conceptually similar to a key ring or a list of cloud resource ARNs in IAM policies
Mistake
RBAC and DAC are essentially the same because a role is just a type of discretionary permission.
Correct
DAC relies on the resource owner to set permissions, while RBAC centralises permission assignment through predefined roles that are managed by administrators, not individual data owners.
Beginners often see role-membership as ownership-like, especially in Windows file shares where you can grant access to a group. The difference is that in DAC, the owner retains full discretion to change permissions, whereas in RBAC, users cannot alter role permissions—only administrators can.
Mistake
MAC can only be used in military or classified government systems.
Correct
MAC can be implemented by any organisation that needs strict, system-enforced access controls based on labels, such as a bank protecting sensitive financial research or a healthcare system guarding patient data with mandatory policies.
The textbook examples always mention military classifications, so people assume MAC is exclusive to that sector. In reality, the label-based, system-enforced nature of MAC is suitable for any high-security environment where data sensitivity must be absolute and users must not be able to lower permissions.
Mistake
Federated identity means the third-party service receives your password to verify you.
Correct
In a properly designed federation, the service provider never sees your password. The identity provider authenticates you and issues a signed assertion or token that the service provider trusts. Your password stays with the identity provider.
Many people think 'logging in with Google' means Google sends your password to the site. The whole point of federation protocols is to avoid that dangerous sharing, but the inner workings of tokens and assertions are invisible, so the misconception feels intuitive.
Mistake
SAML and OAuth are interchangeable; you can just pick whichever your developer prefers.
Correct
SAML is designed for enterprise single sign-on, carrying authentication and attributes in XML, while OAuth 2.0 is strictly an authorisation delegation framework. They serve different purposes, though OIDC (built on OAuth) can provide authentication similar to SAML.
Both are used to gain access without new credentials, so they appear equivalent on the surface. Real-world projects often misuse OAuth for authentication, reinforcing the confusion. The CISSP exam drills down on these protocol distinctions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In MAC, the system sets the rules and nobody can change them, just like a top-secret document cannot be declassified by its author. In DAC, the owner of a file or folder decides who else can access it, similar to you choosing who to invite into your own home.
No, OAuth 2.0 is a delegated authorisation framework. It lets a service act on your behalf without sharing your password, but it does not tell the service who you are. Authentication is added by OpenID Connect, which sits on top of OAuth.
A SAML assertion is an XML message issued by an identity provider that tells a service provider: this user was authenticated at this time, and here are their attributes (like email or group). The assertion is digitally signed so the service provider can trust it.
RBAC assigns permissions based solely on a user’s role (e.g., Manager, Teller), while ABAC looks at multiple attributes—user role, resource classification, time, location—and applies a rule to decide access. ABAC is more flexible and can handle complex policies that RBAC alone cannot.
It means an organisation relies on an external identity provider (like Microsoft Entra ID or Google) to authenticate users, rather than building its own credential store. The CISSP exam tests your understanding of the trust models, protocols (SAML, OIDC, OAuth), and the risks of this approach, such as IdP outage or misconfigured claims.
Yes, many applications support multi-IdP federation, where you can accept assertions from several trusted providers. This is common in mergers or business-to-business scenarios, but it requires careful management of attribute consistency and trust relationships to avoid identity conflicts.
You've finished Access Control Models and Mechanisms. Continue through the CISSP study guide to build a complete picture of the exam.
Done with this chapter?