OIDC Federation on a Grand Scale
Content Warning: Identity Nerd, snapshot 2023.
The OIDC Federation Specification (draft) has been stuck in my brain for about a year now because it changes how I think about my job. On its surface, the concept is relatively simple: Provided that there is a federation of actors, it provides a method by which these actors can establish a common trusted root actor. A simple example might be that I claim that I’m Michael, but you have no reason to trust me. Still, we can both agree to trust the IRS (for better or worse) about that claim.
In true specification style, that’s where it ends. It doesn’t talk about what you do with that common trust, nor does it talk about how a federation is established. A conversation with Mike Jones at IIW Nov ’22 revealed that the intended use case was Academia; that the legal contracts established between universities to share research resources can be converted into a federation, and that this federation can then grant one professor access to, say, a time on a device halfway around the world.
Federation in a Data Center
At VMware, this problem becomes really, really interesting. Any piece of metal can host multiple different leaf nodes, and different authorization paths. An actor such as myself needs to access the metal itself, the datacenter’s management plane, a running VM, or even a workload running on that VM. Each of these leaf nodes will have its own authorization requirements, ranging from 2FA to demonstrable physical presence, and having to sign into multiple different systems to complete your work can be cumbersome.
As you can see, this can very rapidly expand into thousands or hundreds of thousands of different nodes in this federation. The Federation specification provides a way by which each of those nodes can easily join that federation.
Gotcha’s
A magical world where every piece of metal that is slotted into a rack can automatically configure itself and join a federation is likely still the province of private implementations. Even so, this and related specifications provide a zero-configuration path forward, as it leans heavily on other automatic configuration RFCs that allow each node in the federation to register itself. Using Dynamic Client Registration a new node can attach itself to the federation, presuming that its authorization server trusts it.
Perhaps more importantly, there is too much vagueness in other specs like the Token Exchange RFC, so we can’t yet answer the question: “If I’m already authorized with one leaf node, how do I convert that to authorization to another leaf node?”. It’s unlikely that a leaf node knows the exact nuances of the OIDC implementations (or versions) active in the federation.
However, the critical core of the Federation specification is there: Any given node does not have to know about all the other nodes in the federation; it just has to know about its peers, and it can discover everything else from there.