openstack
/
keystone
Code Issues Proposed changes

Policy doc updates; RST syntax consistency 

Change-Id: I087ba16c4c629291fbec9c59fcff873fef8b0213
This commit is contained in:
Dolph Mathews 2012-05-03 12:07:50 -05:00
parent 43d792ff14
commit 352839b9c9
1 changed files with 13 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/source/architecture.rst
View File

@ -20,6 +20,7 @@ Keystone Architecture
Much of the design is precipitated from the expectation that the auth backends Much of the design is precipitated from the expectation that the auth backends
for most deployments will actually be shims in front of existing user systems. for most deployments will actually be shims in front of existing user systems.
------------ ------------
The Services The Services
------------ ------------
@ -64,6 +65,7 @@ Policy
The Policy service provides a rule-based authorization engine and the The Policy service provides a rule-based authorization engine and the
associated rule management interface. associated rule management interface.
------------------------ ------------------------
Application Construction Application Construction
------------------------ ------------------------
@ -101,9 +103,9 @@ on the keystone configuration.
At this time, the policy service and associated manager is not exposed as a URL At this time, the policy service and associated manager is not exposed as a URL
frontend, and has no associated Controller class. frontend, and has no associated Controller class.
.. _Paste: http://pythonpaste.org/ .. _Paste: http://pythonpaste.org/
---------------- ----------------
Service Backends Service Backends
---------------- ----------------
@ -124,6 +126,7 @@ If you implement a backend driver for one of the keystone services, you're
expected to subclass from these classes. The default response for the defined expected to subclass from these classes. The default response for the defined
apis in these Drivers is to raise a :mod:`keystone.service.TokenController`. apis in these Drivers is to raise a :mod:`keystone.service.TokenController`.
KVS Backend KVS Backend
----------- -----------
@ -169,10 +172,12 @@ interpolation)::
LDAP Backend LDAP Backend
----------------- ------------
The LDAP backend stored Users and Tenents in separate Subtrees. Roles are recorded The LDAP backend stored Users and Tenents in separate Subtrees. Roles are recorded
as entries under the Tenants. as entries under the Tenants.
---------- ----------
Data Model Data Model
---------- ----------
@ -228,14 +233,8 @@ of checks and will possibly write completely custom backends. Backends included
in Keystone are: in Keystone are:
Trivial True Rules
------------ -----
Allows all actions.
Simple Match
------------
Given a list of matches to check for, simply verify that the credentials Given a list of matches to check for, simply verify that the credentials
contain the matches. For example:: contain the matches. For example::
@ -243,16 +242,13 @@ contain the matches. For example::
credentials = {'user_id': 'foo', 'is_admin': 1, 'roles': ['nova:netadmin']} credentials = {'user_id': 'foo', 'is_admin': 1, 'roles': ['nova:netadmin']}
# An admin only call: # An admin only call:
policy_api.can_haz(('is_admin:1',), credentials) policy_api.enforce(('is_admin:1',), credentials)
# An admin or owner call: # An admin or owner call:
policy_api.can_haz(('is_admin:1', 'user_id:foo'), policy_api.enforce(('is_admin:1', 'user_id:foo'), credentials)
credentials)
# A netadmin call: # A netadmin call:
policy_api.can_haz(('roles:nova:netadmin',), policy_api.enforce(('roles:nova:netadmin',), credentials)
credentials)
Credentials are generally built from the user metadata in the 'extras' part Credentials are generally built from the user metadata in the 'extras' part
of the Identity API. So, adding a 'role' to the user just means adding the role of the Identity API. So, adding a 'role' to the user just means adding the role
@ -272,8 +268,7 @@ to which capabilities are allowed for that role. For example::
# add a policy # add a policy
policy_api.add_policy('action:nova:add_network', ('roles:nova:netadmin',)) policy_api.add_policy('action:nova:add_network', ('roles:nova:netadmin',))
policy_api.can_haz(('action:nova:add_network',), credentials) policy_api.enforce(('action:nova:add_network',), credentials)
In the backend this would look up the policy for 'action:nova:add_network' and In the backend this would look up the policy for 'action:nova:add_network' and
then do what is effectively a 'Simple Match' style match against the creds. then do what is effectively a 'Simple Match' style match against the creds.