skip to content

A laboratory-booking tool switches to mandatory identity-provider sign-in — what happens to each account's stored password, and who is locked out?

level: principalimportance: should knowfreq 30%

answer

  1. kept, disabled, or deleted
  2. a live password bypasses the leaver process
  3. close the reset path too
  4. run the unlinked-accounts report first
  5. no local credential means a hard dependency

basics

~20 s

The local credential is kept, disabled or deleted, and only the last two actually move the authentication boundary. Locked out are the people with no identity at that provider and those whose identity never linked — a list you produce before the flip, not after.

solid answer

~50 s

Three fates, with different consequences. **Kept** means enforcement is advisory: the password is a route around the institute's own leaver process, which is the failure the institute bought federated sign-in to fix. **Disabled** keeps the row and refuses the login path, so it is reversible in a flag — provided you close every write path that can set a password, or a self-service reset quietly re-opens the door you just shut. **Deleted** is the only state you can honestly describe as holding no password for their staff, and it is not reversible. Whichever you choose, the flip is scoped to a set of accounts, not to everyone, and the report you must run first is *accounts in this tenant with no linked identity for that connection*: external collaborators, visiting researchers, a vendor engineer who books maintenance slots, and anyone whose address in the tool differs from what the provider asserts. Work it to zero, or exempt rows explicitly, before flip day.

code

pseudocode · 19 lines
pseudocode
# 1. before flip day: the report that must reach zero
unready = accounts where tenant = institute
                       and status = ACTIVE
                       and not exists(identity for connection = institute_connection)
# every row is a person or job that cannot sign in on flip day:
#   link it, exempt it explicitly, or close the account

# 2. at the flip, for each account in scope
for account in scope:
    account.password_login_enabled = false     # the login path
    account.password_reset_enabled = false     # or a reset re-opens the path just closed
    if policy == DELETE_CREDENTIAL:
        delete account.password_hash           # not reversible

# 3. the invariant that now has teeth
on unlink(user_id, identity_id):
    routes_left = identities.count(user_id) - 1
    if routes_left == 0 and not has_usable_password(user_id):
        reject "this would leave the account with no way in"

go deeper

for a junior

Recall that switching a customer to provider-only sign-in raises a question about the passwords already stored, and that some accounts belong to people the provider does not know at all.

for a middle

Explain the three fates of the local credential and why disabling has to apply to the login path and every path that can set a password, not just to the stored value.

for a senior

Produce the pre-flip report of accounts with no linked identity, work it to zero with links, exemptions or closures, and be able to say what happens when the provider is unreachable.

for a principal

Treat it as the product's identity contract: what you are promising about availability once no local path exists, how an exempt set is bounded and reviewed, and what exiting the arrangement would cost the customer years later.

## The decision is about the credential, not the button Turning on mandatory federated sign-in is usually described as a setting. It is really a decision about what happens to a credential you have been holding for two years, and the three answers have genuinely different properties. | | Kept usable | Disabled | Deleted | |---|---|---|---| | Has the authentication boundary moved? | no | yes | yes | | Reversible | trivially | one flag | no | | What you can tell the customer | "we prefer the provider" | "password sign-in is closed" | "we hold no password for your staff" | | Bypass risk | the whole point of the flip | only if a write path can set one | none | | Cost of reversing later | none | small | a credential-issuance event for everyone | ## Kept: enforcement that enforces nothing If the password still works, the institute's leaver process still does not reach your tool. Someone's directory account is disabled on their last day, and their booking-tool password opens the instrument schedule the following week. That is precisely the gap the institute was buying federated sign-in to close, so "we made the provider the default and left the password there" is not a smaller version of the flip; it is the absence of it. ## Disabled: the path, not the value Disabling is the pragmatic choice, and it has exactly one trap: it is a property of the **login path**, not of the stored value. Every write path that can set a password is now a bypass — a self-service reset that puts a new value in place and re-enables local sign-in has silently undone the flip for anyone who asks for one. Close the reset alongside the login, and be able to say which paths you closed. What disabling buys is a door you can re-open. When a connection breaks on a Monday morning and nobody at the institute can sign in, a flag that restores local sign-in for a named, time-boxed set is worth having thought about in advance rather than improvised during an outage. ## Deleted: the strongest claim, and a hard dependency Deleting the hash is the only state you can describe truthfully as holding no password for that customer's staff, and for some procurement conversations that sentence is the point. It is also the moment your tool acquires a hard dependency it did not have before: with no local authentication path at all, an outage at the institute's provider is a total outage for you, and there is no fallback to reason about because you removed it deliberately. That is a legitimate choice — it just has to be a choice, made with the availability consequence on the table, and not a side effect of a cleanup script. ## Who is locked out, and when you find out The flip is scoped to a set of accounts and never to everyone in the tenant, because a booking tool's user list is wider than the institute's payroll: - **People with no identity at that provider at all** — a partner laboratory's technician, a visiting researcher on a three-month attachment, an external collaborator on one project, a vendor's field engineer who books the instrument for maintenance. - **People whose identity never linked** — the address in the tool is personal, or predates a name change, or belongs to a contractor, so the provider asserts something that matches nothing. - **Non-human accounts** — the integration account the sample-tracking system uses to create bookings has no human and no identity to link. So the pre-flip work is a report: *accounts in this tenant with no linked identity for this connection*. Every row is a person or a job that will not be able to sign in on flip day. Work it to zero by linking, by explicitly exempting, or by closing the account — before the switch. Run it afterwards and you are reading your own support queue. ## The judgment a lead owns 1. **What the product's identity contract now is.** Once local credentials are gone, you have told this customer their availability is tied to their provider and your uptime claim is a joint one. Say that in the contract rather than discovering it in an incident. 2. **Whether an exempt set exists at all, and how it is bounded.** A permanent exemption for external collaborators is defensible; a permanent exemption that nobody reviews is how the flip decays back to "kept". 3. **The cost of reversing years later.** If the institute ever leaves the arrangement, the people involved have no password and no memory of one, so exiting is a credential-issuance exercise across the whole population — a support event, not a configuration change. 4. **The last-route invariant, now sharper.** With the password gone, an account's identity rows are its only way in, so the unlink path must refuse the last one. The rule that was theoretical while everyone had a password becomes the thing standing between a researcher and their bookings.

  • A researcher's exempt account keeps its password indefinitely. What is the standing cost?
    It is a permanent route around the institute's leaver process for whoever holds it, so the exemption needs an owner, an expiry and a review, not just a flag. An exempt set that nobody revisits is how the flip decays back to keeping passwords, with the added problem that nobody now believes it did.
  • The institute's provider is unreachable on a Monday morning and nobody can sign in. What did the credential decision cost you?
    If you disabled the local path, you have a flag and a decision to make about re-opening it for a bounded set; if you deleted the hashes, there is nothing to re-open and the answer is to wait. Neither is wrong, but the second is only acceptable if it was chosen with this morning in mind.
  • Why does the unlink rule matter more after the flip than before it?
    Before the flip almost every account still had a password to fall back on, so removing an identity row was recoverable. Afterwards the identity rows are the only way in, so an unlink that empties them strands an account with its data and permissions and nobody able to reach it.

saying these in an interview costs you the question

  • Turns enforcement on and finds the locked-out accounts afterwards.
  • Leaves the password usable and calls the boundary moved.
  • Disables the login path while the self-service reset stays open.
  • Applies enforcement to the whole tenant including external collaborators.
  • Deletes local credentials without weighing the provider outage case.
  • Forgets non-human accounts that hold no linkable identity.