Provisioning identity, single sign-on and federation

Objective 4.6 in this course covers identity and access management — CompTIA's scope note for it implements provisioning, SSO, MFA and privileged access tools. This lesson takes provisioning, single sign-on, federation and the access control models; MFA, passwords and privileged access are the next lesson.

Why this matters

Identity is the control plane of a modern estate. When the network perimeter stopped being the boundary, identity became it — which is why zero trust in Domain 1 is built on identity signals and why an attacker's first objective is almost always a credential.

The exam tests this objective heavily and specifically. The access control model acronyms (RBAC, ABAC, MAC, DAC) are near-certain to appear, and the federation protocols are asked about by what each one is for, which is a distinction worth getting exactly right.

The lesson

Provisioning and de-provisioning, and the account nobody closed

Provisioning creates an identity and grants it access; de-provisioning removes both. The lifecycle in between — joiners, movers, leavers — is where the failures live.

• Joiners. Access is granted from a defined role rather than by copying an existing user's permissions. "Make them like Sarah" is how permission creep propagates, because Sarah has rights from three previous jobs.
• Movers. The commonest failure in the whole objective: someone changes role and gains the new access without losing the old. Over a career this produces accounts with extraordinary combined privilege, and it defeats separation of duties without anyone deciding to. The control is that a role change triggers a full re-grant, not an addition.
• Leavers. Access is revoked at the moment of notification, not at the end of the notice period — which is the revenge-motivation timing from Domain
• De-provisioning must cover more than the directory account: SaaS applications outside single sign-on, shared credentials the person knew, VPN certificates, API keys they created, and their access to third-party systems.

Orphaned accounts — accounts with no current owner — are what this produces when it fails, and they are a standing target because nobody notices unusual activity on an account nobody uses. Detecting them is a reconciliation between the directory and the HR system, and it is a routine audit finding.

Service accounts deserve separate mention: non-human identities running applications and integrations. They typically have high privilege, passwords that never change because something would break, no owner after the person who created them leaves, and no multifactor. They should be inventoried, owned, scoped to least privilege, and — where the platform supports it — replaced with managed identities that have no static credential at all.

Identity proofing, interoperability and attestation

Identity proofing is establishing that a person is who they claim before an account exists. Authentication proves you hold a credential; proofing proves the credential was issued to the right human in the first place. It is done at onboarding by checking documents, and it is done again — badly, usually — at password reset, which is why the help desk is a vishing target from Domain 2. A defined verification procedure for resets that does not rely on facts an attacker can look up is the control.

Interoperability is the ability of identity systems to work together — standard protocols rather than bespoke integrations, so that one identity works across on-premises, cloud and third-party applications. Its security value is consolidation: every application that authenticates independently is another credential store to breach and another account to forget at offboarding.

Attestation is confirmation that something is true and current. Two senses appear:

• Access attestation / recertification — a periodic review in which a manager or system owner confirms each person still needs each right. This is the control for the mover problem above, and it is the answer to "how do we prevent accumulated access?".
• Device attestation — a device cryptographically proving its own state, which is what MDM and conditional access rely on and what rooting defeats.

Federation, SAML, OAuth and OpenID Connect at exam depth

Single sign-on (SSO) lets a user authenticate once and reach many applications without re-authenticating. Federation extends that across organisational boundaries: an identity from one organisation is accepted by another.

The roles: the identity provider (IdP) authenticates the user and issues an assertion or token; the service provider (SP) or relying party consumes it and grants access.

The protocols, and what each is actually for:

• SAML — XML-based, mature, the enterprise default for browser-based SSO into business applications. Think workforce SSO to internal and SaaS applications.
• OAuth 2.0 — an authorisation framework, not authentication. It lets an application obtain limited, scoped, revocable access to a resource on the user's behalf without receiving their password. The key ideas: scopes (what the token may do), tokens with expiry, and consent.
• OpenID Connect (OIDC) — an authentication layer built on top of OAuth 2.0, adding an ID token that says who the user is. It is what makes "sign in with…" an authentication rather than only a delegation.

The distinction the exam most wants: OAuth authorises, OIDC authenticates, SAML does enterprise browser SSO. If a question describes granting an application access to your data without giving it your password, the answer is OAuth.

The security consequences of SSO, both directions. It improves security: one strong credential with MFA instead of a dozen weak ones, one place to revoke access, and one place to apply conditional policy. And it concentrates risk: compromise of the identity provider is compromise of everything, and a stolen session token can bypass the authentication entirely — which is why token lifetimes, binding and continuous re-evaluation matter, and why the IdP is the system to protect hardest.

LDAP, directory services, and where the source of truth lives

A directory service stores identities, credentials, groups and attributes. LDAP is the protocol for querying it; Active Directory is the common implementation, and Kerberos is its authentication protocol, using time-stamped tickets — which is why clock skew breaks authentication and why timestamps are what defeat replay.

Two operational points the exam expects:

• LDAPS or LDAP with StartTLS, never plain LDAP, because simple binds send credentials in clear text.
• The directory is the source of truth for identity, so its integrity is paramount. Domain controllers belong in the most restricted zone from Domain 3, with their own administrative accounts, and compromise of one is compromise of the estate.

In hybrid estates the source of truth is usually on-premises and synchronised to a cloud identity provider. The synchronisation account is then one of the highest-privilege objects in the organisation, and the seam between the two directories is the identity part of the hybrid problem from Domain 3.

Permission assignment: RBAC, ABAC, MAC, DAC, rule-based and time-of-day

The access control models, which are near-certain exam content:

• DAC (discretionary access control) — the owner of the resource decides who may access it. Flexible, and it is how ordinary file permissions work. Its weakness is that access decisions are distributed to whoever owns each file, so nothing is consistent and a user can share what they should not.
• MAC (mandatory access control) — the system enforces access based on labels and clearances, and the owner cannot override it. Rigid, used in government, military and high-assurance systems, and implemented on Linux by SELinux from the previous lesson.
• RBAC (role-based access control) — permissions attach to roles, and users get roles. This is how most organisations work: manageable, auditable, and it makes the joiner/mover/leaver process tractable. Its failure mode is role explosion, where exceptions create so many roles that the model stops simplifying anything.
• ABAC (attribute-based access control) — decisions are made from attributes of the user, the resource, the action and the context: department, clearance, data classification, device health, location, time. The most expressive, and it is what zero trust's policy engine evaluates.
• Rule-based — access governed by rules the administrator sets, applied uniformly. Firewall ACLs are the everyday example.
• Time-of-day restrictions — access permitted only during defined hours, which is a simple and effective control for privileged accounts and for systems with no legitimate out-of-hours use.

A memory aid the exam rewards: DAC = the data owner decides. MAC = mandated by the system. RBAC = your role. ABAC = your attributes, plus context.

And a distinction worth holding: least privilege is how much access an identity gets; separation of duties is splitting an action so no single identity can complete it alone. They are different controls addressing different risks, and an exam option offering one where the scenario needs the other is a common distractor.

What to take into the exam

• The mover case — new access granted, old access kept — is the commonest provisioning failure, and access recertification is its control.
• Revoke at notification, not at the end of notice, and include SaaS, keys and third-party access.
• OAuth authorises, OIDC authenticates, SAML is enterprise browser SSO.
• SSO concentrates risk in the IdP, and a stolen session token can bypass authentication entirely.
• DAC = owner decides, MAC = system enforces labels, RBAC = role, ABAC = attributes and context.
• Least privilege limits how much; separation of duties splits the action.