Keystone

What is Keystone?

Keystone is the identity service used by OpenStack for authentication (authN) and high-level authorization (authZ). It currently supports token-based authN and user-service authorization. It is scalable to include oAuth, SAML and openID in future versions. Out of the box, Keystone uses a SQLite DB as an identity store with the option to connect to external LDAP.

Doc

http://launchpad.net/keystone

Code

• http://github.com/openstack/keystone

Releases

• Diablo
  • Core functionality (calls shared by all implementations)
  • Extensions(calls that are specific to the implementation; ie: enabling company "ACME" user, role, and group structure)
• Essex (Keystone is part of OpenStack core for Essex)
  • Call for blueprints
    • User structure (blueprint)
    • AuthZ structure (blueprint)
    • SCIM protocol (blueprint)
    • Federated Auth-Z requirements for Zones - FederatedAuthZwithZones
      • The Service (ie: nova) shouldn't really care about the Role of the user. But we should be able to go back to the Auth-Z service to say "Can <token> [execute verb] on <some resource>" and get back a True/False from keystone. Nova itself, for example, shouldn't have to remember what capabilities a role has. But this may be cached.
  • Identifying full-path URI for X-Auth-Token (ie https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a937 to allow federation).

  This has the advantage of allowing federated tokens, and allowing APIs  and even resources to use the auth server in access decisions. A given  service would maintain a whitelists of keystone servers. The service  would take the request, get the token, and verify that the host of the  token URI matches one from the appropriate whitelist, and then do a GET  on the token per the

  keystone API.
  For example, consider rackspace. We might have 3 keystone servers:

     region1.customer.keystone

     region2.customer.keystone

     employee.keystone

  The management API might set it's whitelist to {employee.keystone}, while the public APIs could whitelist all three, or maybe just the first two.

  This creates three ways to do remote federation.

   1) Each service could simply add remote keystone APIs to its whitelists.

   2) A whitelisted keystone server return REDIRECT, which services implicitly trust

   3) A whitelisted keystone server could forward the request directly

  Items 2 and 3 might be facilitated by adding an "@host" string to the end of the token to allow the keystone implementation to map the token to its source. Eg: if the service receives a token that is not from a whitelisted client, such as

     https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c

  then it mutate the token to hit a trusted keystone implementation:

     https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@keystone.utexas.edu

  The keystone.server implementation could verify the trust relationship with keystone.utexas.edu and redirect or forward back to the original. This would allow remote federations to be controlled by the trusted keystone servers in a way that a client can leverage with no special knowledge – they just auth against their normal keystone servers and proceed.