In presentations on federation at scale that I did (e.g. at the Cloud Identity Summit), I’m arguing that there are basically two different methods of scaling up: using a metadata service or using a proxy. I’ll go in to more detail on the former in a followup post, but right now I’d like to point out where, how and why a proxy can be used to scale up federation.
As discussed in an earlier post, federation today is mostly based on a one-to-one process: the Identity Providers (IDPs) and the Service Providers (SPs) exchange protocol settings to create federated connections in a peer to peer fashion. It is obvious that this does not scale very well since the IDPs and SPs have no defined way of knowing that they are dealing with the right party. Typically this process relies on out-of-band, unreliable and insecure mechanisms such as plain (unsigned) e-mail. But most imporantly, updates in protocol settings have to be exchanged across the same set of fully meshed federated connections without a defined way to do that.
Enter the world of the federation proxy a.k.a federation hub, federation gateway, IDP proxy, etc. etc. The proxy is a single point of connectivity for both SPs and IDPs and both parties communicate with each other only through the proxy. This narrows down the NxM (where N is the number of IDPs, M the number of SPs) mesh trust and management problem of traditional federation to a N+M problem. Of course the proxy will have to be a fully trusted element and it will have to take care of keeping connection information up-to-date but that is easier for a specialized party on far less connections overall compared to the fully meshed model.
It may be obvious that the proxy model does not scale worldwide, but it may be an applicable solution for intra-enterprise use cases (companies that have grown through acquisitions and mergers) and for “community” use cases where one can find a natural party to operate the proxy. It has some additional benefits too, such as the option to perform federation protocol translation. We’ll dive in to that another time.