Design Enterprise SSO

Where an interviewer pokes next

Getting the boxes right is the easy half. These are the questions that separate a candidate who drew the diagram from one who has run the thing. Answer each one out loud before you open it.

Show all answers

1. 01

   Why is SCIM deactivation the question that decides enterprise deals?

   Show the answer

   Because single sign-on answers who a user is and says nothing about whether they should still have an account. A person removed from the customer’s directory can no longer authenticate — but their user record, their issued API tokens, their scheduled exports and their integrations all continue to exist and, in many designs, continue to work. A security reviewer with a compliance obligation asks exactly one question about this, "what happens to access when someone leaves, and within how long?", and they test the answer. The specific trap is that most identity providers deactivate rather than delete, sending PATCH with active set to false so that history and audit trails survive the offboarding. An implementation that only handles DELETE returns success on every request, keeps a green dashboard, and offboards nobody — a control that fails silently, which is the worst possible failure mode for something whose entire value is being verifiable.

2. 02

   Why key users on an immutable subject identifier rather than email?

   Show the answer

   Because email addresses change and identities do not. People marry, companies rebrand, and an acquisition can rewrite every address in a directory over one weekend. If your user records are keyed on email, that event turns every existing user into a stranger: their permissions, their history and their audit trail are orphaned, and duplicate accounts appear as people sign in again. The fix afterwards is a data-repair migration that nobody budgeted for, run under time pressure, against a customer who is already unhappy. Keying on the provider’s immutable subject identifier — oid in Entra, a persistent-format NameID in SAML — costs nothing on day one and makes the whole class of problem disappear. Email is still worth storing, as a display attribute that is explicitly allowed to change.

3. 03

   Why put a mapping table between their groups and your permissions?

   Show the answer

   Because their group taxonomy is theirs to change and they will change it without telling you. Mapping directory groups straight to permissions works until a reorg renames FIN-AP-ANALYSTS to FIN-OPS-AP-TIER1, at which point forty people lose access on a Monday morning and you are paged for a directory edit you had no visibility into. An indirection layer — their groups map to your small fixed role set, which maps to permissions — turns that into a config change their own admin makes in a screen, with the change logged and attributed. Three roles is usually enough at go-live, and three roles the customer understands beats twelve only you can explain. Two rules make it safe: data-level scoping such as "approver for EMEA only" belongs on a separate axis or the role list explodes combinatorially, and a user who authenticates but matches no mapping must be denied loudly rather than granted a silent default.

4. 04

   What does it actually take to revoke access within four hours?

   Show the answer

   More than blocking new sign-ins, which is all that deactivation gives you by default. A user with a live session keeps working, an issued API token keeps working until it expires, and a scheduled export configured under their identity keeps running indefinitely — so a system that only checks status at authentication has revoked nothing measurable. Meeting a stated window means deactivation actively propagates: sessions invalidated, tokens revoked through a revocation check, and long-running jobs re-checking the identity they run as rather than trusting a credential captured at creation. Short token lifetimes bound the worst case so the check does not have to be perfectly synchronous. The clock in any contractual commitment starts at the directory event, not at the user’s next login attempt, which may never come — and that is the distinction most implementations miss until a reviewer asks them to demonstrate it.

5. 05

   What evidence should you have ready before the security review starts?

   Show the answer

   Five artefacts, and preparing them takes an afternoon while discovering you need them takes three weeks. A one-page identity architecture diagram showing the provider, the protocol, which claims flow, where the session lives and what talks to what with which identity — reviewers approve things they can picture. A joiner-mover-leaver walkthrough in three short paragraphs, where the leaver paragraph must contain a time bound. Ten real, redacted audit log lines showing authentication events, permission changes and data access, with the retention period stated, because "we log everything" is not evidence and ten lines are. A break-glass procedure describing what happens when their identity provider is down, which every reviewer asks about because the honest answer is often an undocumented local admin account. And a named gap list with dates — volunteering what you do not support yet is counter-intuitive and it is the strongest credibility signal available, because finding what you did not mention is the reviewer’s entire job.