Jump to: navigation, search

Difference between revisions of "Keystone"

Line 22: Line 22:
 
*** [[Keystone-Essex-BP-AuthZ|AuthZ structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-authz-structure blueprint])
 
*** [[Keystone-Essex-BP-AuthZ|AuthZ structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-authz-structure blueprint])
 
*** [http://www.simplecloud.info/ SCIM protocol] (blueprint)
 
*** [http://www.simplecloud.info/ SCIM protocol] (blueprint)
* Federated Auth-Z requirements for Zones - [[FederatedAuthZwithZones]]
+
*** 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.
+
**** 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.

Revision as of 20:05, 7 September 2011

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

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.