Difference between revisions of "Keystone"
| Line 2: | Line 2: | ||
'''What is 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 | + | 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''' | '''Meetings''' | ||
| − | http://wiki.openstack.org/Meetings/KeystoneMeeting | + | * http://wiki.openstack.org/Meetings/KeystoneMeeting |
'''Doc''' | '''Doc''' | ||
| − | http:// | + | * http://keystone.openstack.org |
'''Code''' | '''Code''' | ||
| Line 22: | Line 22: | ||
#* Non-admin users | #* Non-admin users | ||
#* Create your own roles | #* Create your own roles | ||
| − | #* RBAC discussions: http://etherpad.openstack.org/ | + | #* RBAC discussions: http://etherpad.openstack.org/canhaz |
| + | # Reset baseline of code | ||
| + | #* expandability, future development | ||
# Stability | # Stability | ||
#* Performance | #* Performance | ||
#* Deployability | #* Deployability | ||
#* Documentation | #* Documentation | ||
| − | + | ||
| − | + | Topics for Folsom: [[KeystoneFolsomSummitTopics]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
'''Releases''' | '''Releases''' | ||
| Line 50: | Line 39: | ||
* Essex (Keystone is part of [[OpenStack]] core for Essex) | * 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: [[EssexReleaseSchedule|http://wiki.openstack.org/EssexReleaseSchedule]]) | ** Call for blueprints (feature freeze by '''start '''of e-2; code freeze by start of e-4: [[EssexReleaseSchedule|http://wiki.openstack.org/EssexReleaseSchedule]]) | ||
| − | + | ||
| − | + | Originally Scheduled for Essex: | |
| − | + | ||
| − | + | * [[Keystone-Essex-BP-UserStructure|User structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-user-structure blueprint]) | |
| − | + | * [[Keystone-Essex-BP-AuthZ|Full AuthZ structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-authz-structure blueprint]) | |
| − | + | * [[AuthZ - Explicit Capability Mapping]] | |
| − | + | * [[AuthZ - Empty Roles]] | |
| − | + | * [[AuthZ - Restricted Roles]] | |
| − | + | * [[Keystone-Essex-Scopes|Scopes]] | |
| − | + | * [http://www.simplecloud.info/ 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|(Keystone-Essex-Federated-Token]]) | ||
| + | * SQL schema migrations (ie - sqlalchemy-migrate migrations). | ||
* Folsom | * Folsom | ||
** [[KeystoneFolsomSummitTopics|Summit Topics]] | ** [[KeystoneFolsomSummitTopics|Summit Topics]] | ||
| − | |||
| − | |||
Revision as of 18:24, 17 February 2012
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
Doc
Code
Essex 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/canhaz
- Reset baseline of code
- expandability, future development
- 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)
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).
- Folsom
