Difference between revisions of "Keystone"

Revision as of 09:46, 20 October 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

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

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/KeystoneEssexRBAC
2. Stability
   • Performance
   • Deployability
   • Documentation
3. Enhancements
   • Multiple-stack/Global use case (more than one nova deploy)
   • Region/location
   • Domains (https://blueprints.launchpad.net/keystone/+spec/keystone-domains)
4. Federation
   • First: integration with LDAP/AD
   • Stretch: OpenID, SAML
5. Also:
   • Discovery/Registry(DNS and 35357)
   • Metadata/tags
   • Impersonation
   • Groups
   • Cert-auth for services
   • Q+A
   • Signed requests

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)
    • 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).