Jump to: navigation, search

Difference between revisions of "Keystone"

Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
'''What is Keystone?'''
+
See http://wiki.openstack.org/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 00:18, 19 April 2012

See http://wiki.openstack.org/keystone