Jump to: navigation, search

Difference between revisions of "Keystone"

(Fixed link to V2 spec)
 
(44 intermediate revisions by 17 users not shown)
Line 1: Line 1:
−
__NOTOC__
+
= OpenStack Identity ("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 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.
+
{| border="1" cellpadding="2" cellspacing="0"
 +
|  Source code 
 +
|-
 +
|  Bug tracker 
 +
|-
 +
|  Blueprints   
 +
|-
 +
|  Developer doc
 +
|}
  
−
'''Doc'''
+
== Related projects ==
 +
* Python Keystone client
 +
* Identity API documentation
  
−
http://launchpad.net/keystone
+
== Documentation ==
 +
* [http://specs.openstack.org/openstack/keystone-specs/#identity-v3-api API (v3) specification]
 +
* [http://specs.openstack.org/openstack/keystone-specs/#v2-0-api Identity API (v2) specification]
  
−
'''Code'''
+
== What is Keystone? ==
  
−
* [http://github.com/rackspace/keystone http://github.com/openstack/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.
  
−
'''Releases'''
+
'''Meetings'''
  
−
* Diablo
+
* http://wiki.openstack.org/Meetings/KeystoneMeeting
−
** [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
 
−
*** [[Keystone-Essex-BP-UserStructure|User structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-user-structure blueprint])
 
−
*** [[Keystone-Essex-BP-AuthZ|AuthZ structure]] ([https://blueprints.launchpad.net/keystone/+spec/essex-keystone-authz-structure blueprint])
 
−
*** [http://www.simplecloud.info/ SCIM protocol] (blueprint)
 
−
*** 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 X-Auth-Token (ie [https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a937 https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a937] to allow federation).
 
−
  This has the advantage of allowing federated tokens, and allowing APIs  and even resources to use the auth server in access decisions. A given  service would maintain a whitelists of keystone servers. The service  would take the request, get the token, and verify that the host of the  token URI matches one from the appropriate whitelist, and then do a GET  on the token per the
 
  
−
  keystone API.
+
'''Doc'''
−
  For example, consider rackspace. We might have 3 keystone servers:
 
  
−
      region1.customer.keystone
+
* http://keystone.openstack.org
  
−
      region2.customer.keystone
+
'''Code'''
−
 
 
−
      employee.keystone
 
−
 
 
−
  The management API might set it's whitelist to {employee.keystone}, while the public APIs could whitelist all three, or maybe just the first two.
 
  
−
  This creates three ways to do remote federation.
+
* Source
 +
** https://github.com/openstack/keystone
 +
* Pending Code Reviews:
 +
** Keystone Service: https://review.openstack.org/#q,status:open+keystone,n,z
 +
** Keystone Client: https://review.openstack.org/#/q/status:open+python-keystoneclient,n,z
 +
** Keystone Middleware: https://review.openstack.org/#q,status:open+keystonemiddleware,n,z
  
−
    1) Each service could simply add remote keystone APIs to its whitelists.
+
* Keystone Spec Repository:
 +
** https://review.openstack.org/#q,status:open+keystone-specs,n,z
  
−
    2) A whitelisted keystone server return REDIRECT, which services implicitly trust
+
'''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/python-keystoneclient/+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  keystone blueprints]
 +
* [https://blueprints.launchpad.net/python-keystoneclient  keystone client 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)
  
−
    3) A whitelisted keystone server could forward the request directly
+
'''Liberty Priorities'''
  
−
  Items 2 and 3 might be facilitated by adding an "@host" string to the end of the token to allow the keystone implementation to map the token to its source. Eg: if the service receives a token that is not from a whitelisted client, such as
+
* [[DynamicPolicies]]
  
−
      https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
+
'''Use Cases'''
  
−
  then it mutate the token to hit a trusted keystone implementation:
+
* [[KeystoneUseCases]]
  
−
      https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@keystone.utexas.edu
+
'''Performance'''
  
−
  The keystone.server implementation could verify the trust relationship with keystone.utexas.edu and redirect or forward back to the original. This would allow remote federations to be controlled by the trusted keystone servers in a way that a client can leverage with no special knowledge – they just auth against their normal keystone servers and proceed.
+
* [[KeystonePerformance]]

Latest revision as of 14:52, 8 January 2016

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

Bugs and Blueprints

  • keystone bugs
  • keystone client bugs
  • keystone blueprints
  • keystone client 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)

Liberty Priorities

Use Cases

Performance

Retrieved from "https://wiki.openstack.org/w/index.php?title=Keystone&oldid=100717"