Keystone Federation

Registered by Adam Young

This blueprint has been superseded. See the newer blueprint "External Identity Providers" for updated plans.

Each cloud service keeps it existing tenants/projects and roles for authz, and passes the bulk of the work off to the OpenStack Gateway (a federated version of Keystone) to do the heavy lifting (i.e. interacting with the Identity Providers, validating the various credentials, mapping the attributes into the ones understood by the service etc.)
    There can be thousands of Identity Providers/Attribute Authoritys with millions of different attributes. It would be too complex for Cloud Service Providers to have to create authz policies based on these. Consequently each Cloud Service Provider has its own limited set of authz attributes (currently roles, projects and domains) and only trusts the Openstack Gateway to issue them. It trusts the Openstack Gateway to map between the externally provided attributes and the internally understood ones. The Openstack Gateway is the only known (and trusted) Identity Provider to the Cloud Service Providers.
    Consequently, all Identity Provider/Attribute Authority issued attributes/roles must be globally identifiable throughout the federation, either via their unique name/type (e.g. a URN) or via the name of their issuer (DNS name) and their local name (see Appendix 2).
    The Openstack Gateway has a set of trust relationships with a set of external Identity Providers, Authentication Services and Attribute Authorities. The Openstack Gateway knows how attributes from these external entities map into the local authz attributes known by the Cloud Service Providers. This information must be configurable in Openstack Gateway.
    Most existing authentication systems rely on usernames and passwords. We have to live with that. Consequently all existing federated authn systems which use un/pws are open to phishing attacks, whereby an evil SP redirects the user to a fake Identity Provider which then captures the user’s un/pw. In the current design the simple client is open to such attacks, whereas the intelligent client (Attribute Aggregator) is not. With the intelligent client, after the user decides which attributes and issuers to use, the Attribute Aggregator performs a directory lookup on the issuer in order to obtain its metadata and make a direct request to it. In this case the user cannot be re-directed to a fake issuer by an evil SP and have his password stolen.

Blueprint information

Joseph Heck
David Chadwick
David Chadwick
Series goal:
Accepted for icehouse
Beta Available
Milestone target:
Started by
David Chadwick
Completed by
Dolph Mathews

Related branches



Superseded by a series of more granular blueprints starting with:
(apologies for fussing with the status / priority on this one, I'm trying to keep this link active -Dolph)

This code is implemented and can be demonstrated here
Choose demo 8

Gerrit topic:,n,z

Discussion here:

summit etherpad:

Gerrit topic:,topic:federation,n,z

Addressed by:
    Fix some nits in `configure_federation.rst`

Addressed by:
    Switch to use CA certificate for SAML signing

Addressed by:
    Correct the filename


Work Items