Chapter 5. Federated Identity

As Keystone progressed with new features and functionality, one of the most sought-after features was support for federated identity: giving administrators the ability to leverage their existing federated identity solution, allowing users to use their own credentials and to leverage existing single sign-on capabilities. One of the key benefits of this approach is that users can exist in an identity store that is not owned or accessible by Keystone, reducing the logic of maintaining user credentials, or supporting a single type of corporate backend (LDAP and not AD). It also allows Keystone to concentrate on authorization and how to better serve OpenStack services.

A brief overview of the terminology used in this chapter:

Identity Provider (IdP)
A trusted provider of identity information. This may be backed by LDAP, SQL, AD, or Mongo. The identity provider is able to construct user attributes into Assertions or Claims.
Service Provider (SP)
A service that consumes identity information. In our case, Keystone will be the service provider. Many web applications that utilize single sign-on are examples of service providers.
An XML-based standard approach to federated identity. The resultant document that contains user attributes is called an Assertion.
OpenID Connect
A newer standard approach to federated identity. Leverages OAuth 2.0, and ditches XML in favor of JSON. The resultant information about the user is called a Claim.
Assertions ...

Get Identity, Authentication, and Access Management in OpenStack now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.