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)

1 thought on “Cross Domain Identity Patterns: Chained Federation & Service Broker”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s