Difference between revisions of "Keystone"
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | + | = [[OpenStack]] Identity ("Keystone") = | |
+ | |||
+ | {| border="1" cellpadding="2" cellspacing="0" | ||
+ | | Source code | ||
+ | |- | ||
+ | | Bug tracker | ||
+ | |- | ||
+ | | Blueprints | ||
+ | |- | ||
+ | | Developer doc | ||
+ | |} | ||
+ | |||
+ | == Related projects == | ||
+ | * Python Keystone client | ||
+ | * Identity API documentation | ||
+ | |||
+ | == Documentation == | ||
+ | * [http://docs.openstack.org/api/openstack-identity-service/2.0/content/ 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''' | ||
+ | * [https://bugs.launchpad.net/keystone/+bugs?orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.tag=-python-keystoneclient&field.tags_combinator=ANY&field.omit_dupes=on&field.has_branches=on&field.has_no_branches=on&field.has_blueprints=on&field.has_no_blueprints=on keystone bugs] | ||
+ | * [https://bugs.launchpad.net/keystone/+bugs?orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.tag=python-keystoneclient&field.tags_combinator=ANY&field.omit_dupes=on&field.has_branches=on&field.has_no_branches=on&field.has_blueprints=on&field.has_no_blueprints=on keystone client bugs] | ||
+ | * [https://blueprints.launchpad.net/keystone 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): | ||
+ | |||
+ | # RBAC (with Dashboard and core project integration) <<BR>> | ||
+ | #* 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 | ||
+ | ** [https://blueprints.launchpad.net/keystone/+spec/identity-api Core functionality] (calls shared by all implementations) | ||
+ | ** [https://github.com/openstack/keystone/blob/master/keystone/content/service/RAX-KSGRP-service-devguide.pdf 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: [[EssexReleaseSchedule|http://wiki.openstack.org/EssexReleaseSchedule]]) | ||
+ | * Folsom | ||
+ | ** [[KeystoneFolsomSummitTopics|Summit Topics]] | ||
+ | |||
+ | 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). |
Revision as of 13:58, 24 September 2012
OpenStack Identity ("Keystone")
Source code |
Bug tracker |
Blueprints |
Developer doc |
Related projects
- Python Keystone client
- Identity API documentation
Documentation
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
- Source
- Pending Code Reviews:
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
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)
- Folsom
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).