OpenStack Icehouse Design Summit outcomes for Keystone

This is a summary of the discussions, design decisions, goals, and direction that came out of the OpenStack Icehouse Design Summit in Hong Kong (fall 2013) with regard to Keystone.

The following design summit, Juno, is covered here.

Icehouse Street in Hong Kong

Identity Federation

  • allow federating to an external identity provider without dependency on a particular protocol, but producing a reference implementation based on SAML v2, POST profiles, sender vouches
  • manage remote identity providers including their required level of assurance, public keys, supported protocols, authorized attributes
  • manage attribute mapping configurations per protocol that can be shared across identity providers including "attribute type mappings", "attribute type and value mappings", and "object mappings"
  • natively federate to itself as a new identity-provider service type
  • existing SQL based identity provider can primarily target non-OpenStack service users

Token Revocation

  • produce ephemeral tokens (thereby eliminating the need for the token backend) and reduce network load caused by authentication validation
  • publish a list of token events applicable to both v2 and v3 tokens via HTTP API
  • token revocation events emitted as notifications
  • distributed auth middleware needs to listen for revocation notifications


  • improve isolation between the client's core responsibilities:
    • identity management functionality
    • identifying and authorizing the library user
    • authenticating requests to cloud services on behalf of the library user
    • validating request authorization for cloud services
  • rethink user experience by implementing a parallel execution path in the current source tree

Password Rotation

  • allow deployers to configure the grace period used by the SQL identity backend during which passwords remain valid after a new password has been set
  • on self-service password changes with a zero second (default) grace period, a token revocation event should be emitted (this maintains the current behavior)
  • on self-service password changes with a non-zero grace period, the old password remains in effect for the duration of the grace period and no token revocation event is ever emitted
  • on administrative password resets (for example, in the case of a lost or compromised password), a token revocation event should be immediately emitted, the new password should immediately take effect, and all old passwords should be immediately expired (this basically maintains the current behavior)


  • both the trusts and OAuth 1.0a implementations have discrete advantages and serve slightly different use cases; neither will be deprecated or replaced anytime soon
  • add OAuth 1.0a support to client library
  • limited trust chaining
  • allow trust to delegation to user groups
  • switch from python-oauth2 to oauthlib


  • leverage CADF auditing notifications from oslo for authentication decisions, authorization decisions, and policy enforcement to be consumed by Ceilometer


  • move client-service integration tests into tempest
  • move functional API tests into tempest
  • run client-service integration tests
  • build a dummy service with cookiecutter to test auth middleware against

HTTP API Architecture

  • provide more links between API resources to encourage HATEOAS usage patterns such as dynamic extension discovery
  • publish cacheable jsonschemas for each resource
  • publish cacheable description of available query strings for each collection


  • role assignment tables in SQL backend should be unified into a SQL table which lacks referential integrity
  • rename identity domains to "realms" to better distinguish between the use cases of external identity providers and OpenStack resource collections, however this has undesirable API impact and migration issues


  • log line numbers of deprecated method callers
  • produce a change log to document all deprecations
  • test static implementation of drivers according to supported interfaces in stable releases
  • items to be removed in two releases:
    • the entire v2.0 API
    • list_users or add hard limits
    • list_projects or add hard limits
    • contrib.stats
    • contrib.access
    • keystone.middleware.auth_token
    • keystone.middleware.ec2_token
    • keystone.middleware.s3_token
    • assignment / identity proxy calls
    • maybe ec2 extensions if we have something to supersede it

Header photo by Theekogauhl (Own work) [CC-BY-SA-3.0], via Wikimedia Commons.