A Multilateral Federation is one in which the participating institutions declare conformance with federation-wide standards to foster implicit bilateral trust between each Identity Provider and Service Provider. These declarations are represented in the federation's Metadata (or Trust Registry).The standards may address institutions' technology deployment, policies, IAM practices, organizational maturity, etc.

Multilateral federation employs a trusted 3rd party to gather, curate, and distribute metadata from participating parties. The registration and distribution mechanism is built to be secure and reliable. Each participant only has to register its metadata once with the federation regardless of the number integrations it has. Conversely, it can look up all participating services metadata from a single, trusted distribution point. There is no need to individually negotiate and coordinate metadata registration and updates. 

When combined with the common set of standards, multilateral federation enables large scale, trusted interoperation between Identity Providers and Service Providers.

Federation

Federation, or federated sign-on, means a service relies on an external, typical user-preferred, identity system to perform user authentication and optionally, authorization management.  In the federated model, an identity provider (IdP) and the service provider (SP) need to establish a trusted channel to exchange contact, configuration and authentication event information. Exchanging metadata, which contains a service's (whether IdP or SP) unique identifier, signing keys, service endpoints, and various contact information, accomplishes that goal. 

Bilateral Federation

Outside of higher education, the most common form of federation is bilateral, that is, an IdP and an SP share metadata via some ad hoc method such as email or a protected web app (i.e., an HTML form). Combined with a contract, bilateral federation enables trusted interoperation between one IdP and one SP.

See Also

  1. The "Putting It All Together" section of Trusted Relationships for Access Management: The InCommon Model



  • No labels