Rolling Out SAML and SCIM Without a Directory Mess

SAML federates authentication: it answers who this person is and lets them in. SCIM automates provisioning and deprovisioning: it creates the account the moment someone's added to the right group, and disables it the moment they're removed. Shipping SAML alone leaves deprovisioning as a manual step someone has to remember to do, which is a real, auditable security gap for any customer that takes offboarding seriously.

Building a SCIM endpoint yourself gives full control but means implementing and maintaining the spec's filtering, pagination, and schema quirks across every identity provider a customer might actually use, Okta, Entra ID, Google, each with its own small variations. An identity aggregator service normalizes those differences behind one API, trading a subscription cost for meaningfully less ongoing engineering maintenance, often the better tradeoff for a small team shipping its first enterprise SSO customer.

A common mistake is building the SCIM endpoint to satisfy one customer's identity provider and then assuming it works for the next. For example, a startup ships against Okta, and its first Entra ID customer sends group membership updates in a slightly different shape, leaving new hires without the right role. The fix is to write the endpoint against the spec and keep a small test suite that replays real payloads from each provider. A decision rule: if you expect several different enterprise identity providers soon, price the aggregator seriously before committing engineering time to a custom build.

A deprovisioned user who can still log in, because your app checks a SAML assertion but never separately checks whether SCIM has since disabled that account, is the most serious gap. Duplicate accounts appear when a user's identifier changes, an email address update, say, and SCIM treats it as a brand new user instead of updating the existing one. And group membership changes that don't propagate into role or permission changes inside your app leave access stale in either direction.

• Ship SAML login first, since it unblocks the sales conversation fastest and is the piece most customers ask about by name.
• Add SCIM provisioning and deprovisioning before promising it to any customer relying on it for a compliance requirement, not after the promise is already made.
• Test the deprovisioning path specifically and deliberately, since it's the one enterprise security teams actually audit closely, more than the login flow itself.

Not every identity provider sends the same claims or handles attribute changes identically, and a quirk that never once showed up against the identity provider you built and tested with can surface immediately with a new customer's. Test against the customer's actual identity provider during onboarding rather than assuming your original test environment covers every case you'll ever see in production. Keep a short list of the specific quirks you've already found per provider, so the second and third enterprise customer onboarding doesn't rediscover the same edge case from scratch.

When a customer's security team asks whether a specific person's access was actually revoked, and when, an audit log of every SCIM create, update, and deactivate event is the fastest possible answer. Without it, you're reconstructing the timeline from application logs never designed for that purpose, under time pressure, during exactly the kind of review where a slow answer looks worse than the underlying facts warrant.

Keep that log immutable and separate from your general application logs, with retention long enough to cover a typical annual audit window rather than the shorter retention window you might apply to ordinary debug logging. A customer's compliance team asking for six months of deprovisioning history is a completely reasonable request, and answering it should be a quick, routine export, not an improvised research project that pulls an engineer off other work for an afternoon.