The Identity Stack, Episode 11
EP10: SAML/OIDC → EP11 → EP12: Entra ID + Linux → …
Focus Keyphrase: what is an identity provider
Search Intent: Informational
Meta Description: Identity providers explained: on-prem (AD FS, Keycloak), cloud (Okta, Entra ID), SCIM provisioning, and how federation stitches them together. (151 chars)
TL;DR
- An Identity Provider (IdP) is the system that authenticates users and issues identity assertions (SAML assertions, OIDC tokens) to applications
- On-prem IdPs: AD FS (Microsoft), Shibboleth (universities), Keycloak (open source), Ping Identity — they sit in front of AD and speak SAML/OIDC to cloud apps
- Cloud IdPs: Okta, Entra ID (Azure AD), Google Workspace, Ping Identity Cloud — they are the directory and the authentication layer in one
- Federation: IdPs can trust each other — a corporate IdP can delegate to a cloud IdP, or federate with a partner org’s IdP
- SCIM (System for Cross-domain Identity Management) is provisioning, not authentication — it creates/updates/deactivates user accounts in target systems when the source directory changes
- The key distinction: federation (authentication flow) vs directory sync (data copy) — they solve different problems and are often deployed together
The Big Picture: Where IdPs Sit
On-prem Directory
(Active Directory / OpenLDAP / FreeIPA)
│
│ LDAP / Kerberos
▼
Identity Provider
┌──────────────────────────────────┐
│ AD FS / Keycloak / Okta / │
│ Entra ID Connect / Shibboleth │
│ │
│ Speaks: SAML 2.0 + OIDC + OAuth2│
└────────────────┬─────────────────┘
│ assertions / tokens
┌───────────────────┼───────────────────┐
▼ ▼ ▼
Salesforce GitHub Enterprise AWS IAM
(SAML SP) (OIDC RP) (OIDC)
EP10 covered the protocols. This episode covers the systems — what an IdP actually does, how the major ones differ, and how they connect to each other through federation and SCIM.
On-Premises Identity Providers
AD FS (Active Directory Federation Services)
AD FS is Microsoft’s on-prem federation server — a Windows Server role that sits in front of Active Directory and speaks SAML 2.0 and OIDC to external applications.
What it does:
– Authenticates users against AD (Kerberos/LDAP behind the scenes)
– Issues SAML assertions and OIDC tokens to external SPs
– Handles claims transformation: maps AD attributes to what the SP expects
What it doesn’t do well:
– It’s Windows Server only
– Configuration is complex (XML, certificates, claim rule language)
– No built-in MFA (requires Azure MFA or a third-party provider)
– Being deprecated in favor of Entra ID for most use cases
AD FS made sense when everything was on-prem. As workloads move to cloud, Entra ID Connect (a lighter sync agent) combined with Entra ID as the IdP replaces AD FS for most enterprises.
Keycloak
Keycloak is the open-source IdP from Red Hat. It’s what FreeIPA uses for web-based OIDC/SAML SSO, and it’s widely deployed independently for organizations that want full control over their identity infrastructure.
# Run Keycloak in development mode (Docker)
docker run -p 8080:8080 \
-e KEYCLOAK_ADMIN=admin \
-e KEYCLOAK_ADMIN_PASSWORD=admin \
quay.io/keycloak/keycloak:latest \
start-dev
# Keycloak concepts:
# Realm — an isolated namespace (like a tenant)
# Client — an application that uses Keycloak for auth (SP/RP)
# User federation — connect Keycloak to an existing LDAP/AD directory
# Identity brokering — federate with external IdPs (Google, GitHub, another SAML IdP)
Keycloak reads users from AD/LDAP via its User Federation feature — it doesn’t replace the directory, it federates it. Users still live in AD; Keycloak issues SAML/OIDC tokens based on those users.
Shibboleth
Shibboleth is the dominant IdP in academia. Most universities run it. It’s SAML-native, designed for federation between institutions — a student can authenticate at their home university’s IdP and access resources at a partner institution.
Cloud Identity Providers
Okta
Okta is a cloud IdP + directory. It can:
– Act as the primary user directory (storing users, credentials)
– Connect to on-prem AD via the Okta Active Directory Agent (a lightweight sync service)
– Federate with other IdPs (act as IdP or SP in a SAML/OIDC chain)
– Enforce MFA, Adaptive Authentication, Device Trust
Okta’s Lifecycle Management handles provisioning: when a user is created/disabled in Okta (or synced from AD), Okta can automatically create/deactivate accounts in downstream SaaS apps — via SCIM or app-specific APIs.
Entra ID (Azure Active Directory)
Entra ID is Microsoft’s cloud IdP. It’s both a directory (stores users, groups) and an IdP (issues tokens). For organizations running on-prem AD, Entra ID Connect syncs users from AD to Entra ID.
Entra ID is OIDC and OAuth2 native — it speaks SAML for legacy apps but JWT/OIDC for everything modern. Its OIDC implementation follows the standard closely; its token validation happens via /.well-known/openid-configuration and the JWKS endpoint.
On-prem AD → Entra ID Connect (sync agent) → Entra ID (cloud)
│
SAML / OIDC
│
SaaS apps, Azure resources
Google Workspace
Google Workspace is Google’s combined directory + IdP. Google accounts are the users. Apps integrate via SAML or OIDC. Google’s OIDC implementation is one of the most widely used reference implementations — most OIDC libraries are tested against it.
Federation: IdPs Trusting Each Other
Federation is the mechanism that lets IdPs delegate to each other. Two patterns:
SAML Federation (IdP-to-IdP)
Common in academia and partner integrations:
User at University A → requests resource at University B
│
│ doesn't know user
▼
University B SP redirects to...
Discovery Service: "which IdP are you from?"
│
▼
University A IdP authenticates user
│
Sends SAML assertion to University B SP
University B’s SP trusts University A’s IdP because both are members of a SAML federation (e.g., InCommon in the US, eduGAIN globally). The federation metadata aggregates all members’ SAML metadata — certificates, endpoints — so members don’t have to manually configure each bilateral trust.
OIDC Identity Brokering
Keycloak, Okta, and Entra ID can all act as identity brokers — they sit between the application and the actual authenticating IdP:
App (OIDC RP) → Keycloak (broker IdP) → Google / GitHub / SAML IdP
│ authenticate
▼
Keycloak receives assertion
Maps external claims to local claims
Issues OIDC token to app
The app only knows Keycloak. Keycloak handles the upstream IdP complexity.
SCIM: Provisioning ≠ Authentication
SCIM (RFC 7644) is a REST API standard for user lifecycle management — creating, updating, and deactivating user accounts in a target system when changes happen in the source directory.
Source (Okta / Entra ID) Target (Slack / GitHub / Jira)
│ │
│ SCIM 2.0 (REST + JSON) │
├─ POST /Users ─────────────────────► create user
├─ PATCH /Users/id ──────────────────► update attributes
└─ DELETE /Users/id ─────────────────► deactivate account
SCIM is not SSO. A SCIM-provisioned user in Slack can log in to Slack — but the authentication still goes through the IdP (SAML/OIDC). SCIM ensures the account exists. The IdP proves the user’s identity.
Why both? Because SSO alone doesn’t create accounts in target systems — it just authenticates to them. If a user tries to log in to Slack for the first time via SSO, Slack needs an account to map them to. SCIM creates that account before the first login (Just-in-Time provisioning handles it at first login, but SCIM handles it in bulk and handles deprovisioning reliably).
Deprovisioning is where SCIM matters most. When an employee leaves, you disable them in Okta — SCIM deactivates their account in every connected app within minutes. Without SCIM, IT runs a manual checklist. Someone misses Jira. The ex-employee has access for three weeks.
Directory Sync vs Federation
These are commonly confused:
Directory sync — copy user data from source to target. Entra ID Connect copies users from on-prem AD to Entra ID. This is not authentication; it’s data replication. After sync, Entra ID has its own copy of the user record.
Federation — delegate authentication to an external IdP. The target system doesn’t store credentials; it redirects to the IdP for authentication and trusts the assertion that comes back.
You often need both:
– Sync: so the target system has the user record and can enforce policies (group membership, license assignment)
– Federation: so the user authenticates against the source of truth (your IdP) rather than maintaining a separate password in every system
⚠ Common Misconceptions
“SCIM is an authentication protocol.” SCIM is a provisioning protocol. It creates and manages accounts. Authentication is SAML/OIDC. Both solve different parts of the identity lifecycle problem.
“SSO means you only have one password.” SSO means you only authenticate once per session. The password still exists (at the IdP). SSO reduces the number of authentication events, not the number of credentials.
“On-prem IdP + cloud sync is the same as a cloud IdP.” With on-prem IdP + cloud sync (e.g., AD + Entra ID Connect), authentication happens via the on-prem IdP — if it goes down, cloud SSO breaks. A pure cloud IdP (Okta standalone, Entra ID without on-prem AD) authenticates entirely in the cloud.
Framework Alignment
| Domain | Relevance |
|---|---|
| CISSP Domain 5: Identity and Access Management | IdPs are the central control plane for federated identity — their architecture, trust relationships, and provisioning workflows define the enterprise IAM posture |
| CISSP Domain 1: Security and Risk Management | SCIM-based deprovisioning is an access control risk management practice — without it, terminated employee access persists across connected systems |
| CISSP Domain 3: Security Architecture and Engineering | The choice of on-prem vs cloud IdP, federation vs sync, and SCIM vs JIT provisioning are architectural decisions with long-term operational and security implications |
Key Takeaways
- An IdP authenticates users and issues assertions (SAML) or tokens (OIDC/OAuth2) — applications trust the IdP, not the user directly
- On-prem: AD FS (Windows/legacy), Keycloak (open source, flexible), Shibboleth (academia)
- Cloud: Okta (cloud-native, strong lifecycle management), Entra ID (Microsoft-integrated), Google Workspace
- Federation = authentication delegation between IdPs; Directory sync = data replication; SCIM = account lifecycle (provisioning/deprovisioning)
- SCIM deprovisioning is the critical control — it ensures ex-employees lose access automatically across all connected systems
What’s Next
EP11 covered the IdP landscape. EP12 gets specific: Entra ID and Linux — how you configure a Linux VM to accept SSH logins authenticated against Azure AD credentials, and how the aad-auth / pam_aad stack works end to end.
Next: Entra ID Linux Login: SSH Authentication with Azure AD Credentials
Get EP12 in your inbox when it publishes → linuxcent.com/subscribe