Single Sign On, Single Blast Radius

The case for single sign on has never needed much help from anybody. Every application an organization buys arrives with its own account store, its own password rules, its own opinion about how long a session lasts, and its own offboarding step that somebody has to remember to perform. Consolidate all of it behind one identity provider and that last item becomes a single action, taken once, by a person whose job it is. In the decentralized version access does not end when employment ends. It just stops being used.

That is a real gain, it is larger than the arguments against it, and I would not hand it back. But there is a second thing consolidation does, and it is less discussed mainly because it is the same property described from the other side. Every application behind the provider now trusts an assertion instead of a credential. It does not know your users. It knows that something it trusts vouched for one, and it has no independent way to check.

Which means the interesting question was never whether the identity provider is well built. It is what counts as the identity provider. The signing key is obviously in scope. So is the console, and the admin roles inside it, and the provisioning connector that writes group membership into forty downstream applications. And so, though nobody puts it on the diagram, is whatever process exists for helping an administrator who has lost their phone at an airport.

Here is the sentence the rest of this is about. You do not get to concentrate the convenience without concentrating the consequence, because they are one property viewed from whichever side you happen to be standing on. What you do get to decide is how much of the blast radius you are willing to look at before you sign, and the honest answer at most organizations, mine included at various points, is not very much of it.

The access was in January and the notice was in March. Okta's chief security officer published a statement yesterday describing a five-day window between 16 and 21 January 2022 in which an attacker had remote desktop access to the laptop of a customer support engineer working for a third-party provider. It arrived after screenshots of an internal console turned up over the weekend on a Telegram channel run by the group calling itself LAPSUS$, which means the first notice most security teams got about their own identity provider came from the people who had broken into it. Two months is not a rounding error in an incident plan. It is longer than many organizations keep the logs they would need to look back through.

The engineer worked for somebody else. Okta's statement describes a support engineer at a third-party provider rather than an employee. Reporting through the weekend named that provider as Sitel, and I will leave it there, since Okta's own statement does not, and a name repeated confidently enough stops being attributed. What matters structurally is not the name. It is that the compromised laptop belonged to a company that most Okta customers had never evaluated and could not have listed from memory.

Here is what the account could and could not do. This is the most useful paragraph in the whole statement and it is the one being skipped. Support engineers could not create or delete users, and could not download customer databases. They could view limited data, Okta names Jira tickets and lists of users, and they could facilitate the resetting of passwords and multi-factor authentication factors without being able to obtain those passwords. Read that last clause slowly. Not knowing the password stops mattering once you can arrange for a new one.

The number needs reading for what it actually is. Okta says approximately 2.5 percent of customers were potentially impacted, with data that may have been viewed or acted upon. Coverage since has converted that into a customer count, and the counts disagree with each other, because they are percentages multiplied by a customer total the statement does not contain. I would use the percentage and say plainly that it is an upper bound published while the investigation is open, which is a different kind of number from a finding.

Nothing about this required a weakness in SAML, or in assertion signing, or in the multi-factor implementation, or in any of the things a security review of an identity provider actually looks at. Those are the parts with specifications, threat models and conference talks. The compromise ran through a support console reached from a laptop over remote desktop, which has none of those and is not what anybody thinks they are buying.

An account recovery flow is an authentication mechanism. It has to be, because its entire purpose is to establish that the person on the other end is who they say they are without the evidence they normally use. When that flow ends in a human being clicking a button that resets a factor, you have an authentication mechanism whose strength is a support agent's judgment on a bad afternoon, against somebody who has read your help center and rehearsed the story. Nobody threat-models it because it does not look like authentication. It looks like a ticket queue.

And ticket queues get outsourced, for reasons that have nothing to do with security and are not stupid. Support is a cost center with unpredictable volume and a follow-the-sun requirement, and specialist firms run one better than a software company does. The trade is that tooling with real privilege moves to a company named on your vendor's subprocessor list, which is the page in a security review that gets checked for existence rather than read.

So the false binary is the one the vendor questionnaire encodes: is this provider secure, yes or no. The real axis is how far the trust you granted extends past the thing you evaluated. You assessed a login service. You took delivery of its help desk, its support tooling, the endpoint policy on a contractor's laptop in a country you did not ask about, and every subprocessor on a list you confirmed the existence of.

Ask how long a session is, and whose session it is. There are at least two clocks and they are not connected. The identity provider has a session, and every application behind it issues its own once the assertion is accepted. Killing the first does not touch the second. An application holding an eight hour session cookie will keep working for eight hours after you disable the account, and nothing in the console will tell you that, because from the console the account is disabled and the job looks done.

Find out what actually happens when you press revoke. SAML has had a Single Logout profile since 2005 and support for it ranges from thorough to absent, with a long middle where it is present and quietly fails on one participant. OpenID Connect defines a back-channel logout that a relying party has to implement and many do not. Refresh tokens outlive everything. The only way to know which of your integrations honors a revocation is to revoke one and go look, which is a drill, not a document.

Check who is allowed to reset a factor. The privilege that mattered in January was not the ability to read data. It was the ability to reset an authentication factor, and in most tenants that sits bundled inside a help desk role handed out generously because resetting factors is what a help desk does all day. Separating the right to reset a factor from the right to read a directory costs an afternoon and removes the exact capability that turns a support account into an account takeover.

Then there is the break-glass account you have not tested. Every tenant needs at least two local accounts that do not federate, held on hardware security keys, with credentials split and stored somewhere physical, and excluded from the conditional access rules that would otherwise lock them out along with everything else. Most organizations have created these. Rather fewer have signed in with one this year, which is how you learn that the key was reissued, the account expired, or the rule you added in June covers it after all.

Every organization I have worked with can quote a recovery time objective for its systems, because someone was made to write one down. Ask instead how long it takes, starting now, to end every live session for every user across every federated application, and the room goes quiet. That figure is the one this incident is actually about. It is your exposure window for any credential or session that turns out to have been compromised, and it is the only thing standing between a disclosure and a decision about whether to tell anyone.

The measurement is a drill and it takes a morning. Pick a test user with realistic access, sign in everywhere, leave every tab open, revoke centrally, then have somebody walk the list clicking around in each application and write down the minute each one stops working. The output is a table with one embarrassing row on it. That row is the answer to the question, and until you have run this the answer you would give an auditor is the marketing number from the console.

I should be careful about how much that drill buys. It measures revocation, not detection, and revocation is worthless until somebody knows to press the button. In January nobody outside a forensic firm knew there was a button to press, and no session drill anywhere would have changed that. Time to revoke is a floor under your response rather than a description of it, which is a reason to know the figure and not a reason to be comforted by it.

Concentration is not a mistake somebody made while buying an identity provider. It is the shape of every piece of infrastructure worth having. The domain registrar can take every service you run off the internet in a single action. The code signing key ends everything downstream of it. The build system writes to production by design, because that is what it is for. The cloud account root can delete the estate on a Tuesday. An argument that condemns all of that has stopped being an argument and become a mood.

The alternative is not safety either. It is diffusion, and diffusion has the worse record, which nobody writes up because nobody notices. Without a central provider every application keeps its own credentials, and the same attacker calls a support desk at a smaller company with thinner tooling, no session concept worth the name, and log retention measured in days. The compromise still happens. It just produces no statement, no forensic report and no essay, because there is nowhere it would have shown up, and a vendor big enough to be examined and written about is offering me a kind of scrutiny I cannot buy from a login form maintained by two people who also do support.

So what I object to is not the concentration. It is the two months. I will consolidate trust, I do it, and I would sign for it again next quarter. What I will not defend is consolidating it into a party whose duty to tell me something has gone wrong is written in the contract as prompt, and whose subprocessor's duty to tell them is written nowhere I am allowed to read. The single point of trust is fine. The single point of trust with an unspecified clock attached to it is the defect, and it is the one nobody negotiates.

I want to be careful not to let this become a case against buying identity, because it is not one, and the detail that stops it being one is in Okta's own statement. Those support engineers could not create users and could not download a customer database. Somebody sat down and decided that, on purpose, before any of this happened, and it is the reason this week produced a percentage rather than a catastrophe. The controls held exactly where they had been designed. The gap was in the part that was never designed, because it was not a product feature and had no owner.

What stays with me is where the door was. Every diagram of a federated estate draws the identity provider as the front entrance, hardened, watched, with the good lock on it, and that drawing is accurate. It is also not where anybody came in. There is always a second door, cut into the side of the building by decent people so that colleagues locked out on a Sunday could still get to their desks, and it is not on the diagram, and it opens with a ticket.