Difference between revisions of "Keystone"
(Corrected url to github) |
|||
Line 11: | Line 11: | ||
* [https://github.com/openstack/keystone https://github.com/openstack/keystone] | * [https://github.com/openstack/keystone https://github.com/openstack/keystone] | ||
+ | |||
+ | '''Roadmap''' | ||
+ | (as per current discussions in [[OpenStack]] Design Summit in Boston - October 2011): | ||
+ | # 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 | ||
+ | # Stability | ||
+ | #* Performance | ||
+ | #* Deployability | ||
+ | #* Documentation | ||
+ | # Enhancements | ||
+ | #* Multiple-stack/Global use case (more than one nova deploy) | ||
+ | #* Region/location | ||
+ | #* Domains (https://blueprints.launchpad.net/keystone/+spec/keystone-domains) | ||
+ | # Federation | ||
+ | #* First: integration with LDAP/AD | ||
+ | #* Stretch: OpenID, SAML | ||
+ | # Also: | ||
+ | #* Discovery/Registry(DNS and 35357) | ||
+ | #* Metadata/tags | ||
+ | #* Impersonation | ||
+ | #* Groups | ||
+ | #* Cert-auth for services | ||
+ | #* Q+A | ||
+ | #* Signed requests | ||
'''Releases''' | '''Releases''' |
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
Code
Roadmap (as per current discussions in OpenStack Design Summit in Boston - October 2011):
- 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
- Stability
- Performance
- Deployability
- Documentation
- Enhancements
- Multiple-stack/Global use case (more than one nova deploy)
- Region/location
- Domains (https://blueprints.launchpad.net/keystone/+spec/keystone-domains)
- Federation
- First: integration with LDAP/AD
- Stretch: OpenID, SAML
- 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)
- 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).