Typical Identity Federations can be categorized in the following three architecture categories:
All architecture types have certain advantages and disadvantages over each other. These and their characteristics are discussed below.
Full mesh federations are the most common and straight forward to implement federations because everything is distributed and there is no need for a central component that has to be protected specifically against failover (that duty is distributed as well). Every organisation in that federation operates their own Identity Provider (IdP) connected to a local user database and an arbitrary number of Service Providers (SP). All these entities typically are listed in a centrally distributed SAML metadata file, which is consumed by all entities. Therefore, the metadata file basically describes who is in the federation. One of the main challenge in full mesh federations therefore is the efficient management of the metadata file and the handling of the attribute release at the Identity Providers. Some federations use a web based service to register all entities, others rely on a set of scripts to compose the SAML2 metadata for the federation. Most federations also operate a central Identity Provider Discovery Service/WAYF. This however is not needed in this architecture because each Service Provider can individually operate a (local) Discovery Service.
Hub & Spoke federations with distributed login rely on a central hub or proxy via which all SAML assertions are sent. The hub serves as a Service Provider versus the Identity Providers and as an Identity Provider versus the Service Providers in the federation. Each organisation still operates their own Identity Provider connected to a local user database but the Identity Provider typically only needs metadata of the hub. Vice versa the Service Providers only need metadata for the hub. On the hub there typically also is a central Discovery Service for all users. Because the hub is a single-point of failure, it has to be carefully secured and protected. But because users enter their passwords not at the hub but on the login page of their Home Organisation, the hub never learns about the user's credential. Only the hub knows which entities are in the federation. The hub can be used to "connect" individual Service Providers and Identity Providers using for example a web interface. The hub also can control which attributes are passed on from the Identity Provider to the Service Provider and it also can extend or transform attributes. Depending on the implementation of the hub, interfederation scenarios are non trivial to handle. eduGAIN uses the full mesh architecture which technically works (thanks to SAML2) with the hub architecture but causes some usability issues, especially in the Identity Provider Discovery Service area.
Hub & Spoke federations with central login are a special case in the sense as there is only one single Identity Provider in the federation. Instead of operating individual Identity Providers at each organisation, in this architecture all user databases are connected to a central Identity Provider. Users enter their organisation credentials on the central Identity Provider. Therefore, the organisation operating this Identity Provider needs to be especially trusted by all organisations. Also the central Identity Provider is a single point of failure and it must be highly available. Depending on the number of logins, scalability issues may arise. On the other side, it is very easy to support new authentication protocols on the hub thanks to the central login. In an interfederation context, there are however similar usability problems like with the distributed login.