Revision as of 13:58, 24 September 2012

OpenStack Identity ("Keystone")

Related projects

• Python Keystone client
• Identity API documentation

Documentation

• Identity API (v2) specification

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 has recently been rearchitected to allow for expansion to support proxying external services and AuthN/AuthZ mechanisms such as oAuth, SAML and openID in future versions.

Meetings

• http://wiki.openstack.org/Meetings/KeystoneMeeting

Doc

• http://keystone.openstack.org

Code

• Source
  • https://github.com/openstack/keystone
• Pending Code Reviews:
  • https://review.openstack.org/#q,status:open+keystone,n,z

Bugs and Blueprints

• keystone bugs
• keystone client bugs
• blueprints
• bugs tags
  • blueprint (implies bug indicates a needed feature or function, can be migrated to a blueprint)
  • python-keystoneclient (related to the client end of keystone)
  • legacy (existing prior to the feb14, 2012 rebaseline of the code)
  • gsoc (appropriate for a google summer of code project effort)
  • low-hanging-fruit (easy piece for someone to get started with, minimal design needed to solve)
• importance meanings
  • critical (bug renders the system non-functional)
  • high (bug we want resolved before the next release)
  • medium/low (general issue bug or annoyance, perhaps requiring significant design change to implement or new features needed to resolve)
  • wishlist (nice to have)

Use Cases

• KeystoneUseCases

Essex Roadmap (as per current discussions in OpenStack Design Summit in Boston - October 2011):

1. RBAC (with Dashboard and core project integration) <
   >
   • Fine-grained access control
   • Non-admin users
   • Create your own roles
   • RBAC discussions: http://etherpad.openstack.org/canhaz
2. Reset baseline of code
   • expandability, future development
3. Stability
   • Performance
   • Deployability
   • Documentation

Topics for Folsom: KeystoneFolsomSummitTopics

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 (feature freeze by start of e-2; code freeze by start of e-4: http://wiki.openstack.org/EssexReleaseSchedule)
• Folsom
  • Summit Topics

Originally Scheduled for Essex:

• User structure (blueprint)
• Full AuthZ structure (blueprint)
• AuthZ - Explicit Capability Mapping
• AuthZ - Empty Roles
• AuthZ - Restricted Roles
• Scopes
• SCIM protocol (blueprint)
• Service endpoint location (https://blueprints.launchpad.net/keystone/+spec/service-endpoint-location)
• 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 Keystone-Token (Keystone-Essex-Federated-Token)
• SQL schema migrations (ie - sqlalchemy-migrate migrations).