Cross Domain Identity Patterns: Chained Federation & Service Broker

Chained Federation allows access to multiple Service Providers to be granted to multiple trusted Identity Providers. The identity provider request access to the service provider via the Service Broker which authorises the request and forwards to the appropriate service provider based on the TargetURL. This is useful where an enterprise is providing multiple services to multiple customers (identity providers) and does not want to manage many to many relationships.

fed2

Advantages:
Externalise trust to external identity providers who bear cost of on-boarding users. User can choose their identity provider.

Requirements:
Agreed contract with identity provider.

Challenges:
In an enterprise implementation further data may be required to decorate the user and assign role or permission (see Mapped Federation)
The Service Broker needs to maintain the service provider targetURL and the service broker URL. In an enterprise implementation this is often best provided as a service.

Examples:
UK Government Gateway
3 Legged OAuth implementation (e.g. Twitter)