Dropped off the thread for a while... sorry.<div><br></div><div>Ziad, I think this sounds very reasonable. I think the only hiccup might be with the use of the term "role" which might connote some "bigger" meaning to folks with AAAA backgrounds.</div>
<div><br></div><div>If I understand your proposal, then a service can decide what is the granularity of ""thingies""  it registers with keystone(sorry.. no better term comes to mind - it's what you refer to in #2). These thingies can be "roles" or "actions" or whatever makes sense to the authorizing middleware.</div>
<div><br></div><div>In Jason's model, these thingies can be in the form of: <service-namespace>:<object-type>:<action>. In this case, it could be convenient to have a keystone api to check if a given thingy is bestowed on a user, rather than returning the full list of thingies the user possess. The rational here is that if services do end up defining very granular thingies (please do come up with a better name...) then the list might get somewhat lengthy. On some systems I've worked on we had 100's of action-tokens (more or less the name we used) - returning the full list, even filtered by the service's name-space, might be a bit much.</div>
<div> </div><div><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha <span dir="ltr"><<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">




<div style="word-wrap:break-word;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>Here's a possible use case we can implement to address this:</div>
<ol>
<li>A service 'registers' itself with Keystone and reserves a name (Ex. Swift, or nova). Keystone will guarantee uniqueness.</li><li>Registered services can then create roles for the service (Ex. swift:admin or nova:netadmin) or tuples as suggested below (nova:delete:volume)</li>
<li>On token validation, Keystone returns these roles and a service can apply it's own policies based on them.</li></ol>
<div>This is super-simplified and we can expand on it.</div>
<div><br>
</div>
<div>Other benefits:</div>
<ul>
<li>Registration would also be handy to allow services to add and manage endpoints as well.</li><li>We can also tie this with the concept of a ClientID so services can identify themselves as well with a long-lived token (see <a href="https://github.com/rackspace/keystone/issues/84" target="_blank">https://github.com/rackspace/keystone/issues/84</a>)</li>
<li>Common names for services could be implemented as shareable among different implementations (Ex: compute:admin)</li></ul>
<div>Thoughts?</div>
<div><br>
</div>
<div>And comments inline <font color="#00970A">ZNS>></font></div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;border-bottom:medium none;border-left:medium none;padding-bottom:0in;padding-left:0in;padding-right:0in;border-top:#b5c4df 1pt solid;border-right:medium none;padding-top:3pt">

<span style="font-weight:bold">From: </span>"Rouault, Jason (Cloud Services)" <<a href="mailto:jason.rouault@hp.com" target="_blank">jason.rouault@hp.com</a>><br>
<span style="font-weight:bold">Date: </span>Thu, 16 Jun 2011 19:54:22 +0000<br>
<span style="font-weight:bold">To: </span>andi abes <<a href="mailto:andi.abes@gmail.com" target="_blank">andi.abes@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>Ziad Sawalha <<a href="mailto:ziad.sawalha@rackspace.com" target="_blank">ziad.sawalha@rackspace.com</a>>, "<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>><br>

<span style="font-weight:bold">Subject: </span>RE: [Openstack] OpenStack Identity: Keystone API Proposal<br>
</div>
<div><br>
</div>
<div>

<div lang="EN-US" link="blue" vlink="purple">
<div><div class="im">
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif">See inline…<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif">Jason<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma, sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma, sans-serif"> andi abes [<a href="mailto:andi.abes@gmail.com" target="_blank">mailto:andi.abes@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, June 15, 2011 5:04 PM<br>
<b>To:</b> Rouault, Jason (Cloud Services)<br>
<b>Cc:</b> Ziad Sawalha; <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
<b>Subject:</b> Re: [Openstack] OpenStack Identity: Keystone API Proposal<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Jason,  <u></u><u></u></p>
<div>
<p class="MsoNormal">  Sounds like the model you're proposing could be achieved by  something like this:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">On Keystone:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- Roles are identified by name and contain tuples in the form of:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> -- the service to which this permission applies (e.g. service nova, swift). Including the service is meant to side track attempts to normalize actions across very different types of services<u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"> --  the type of target this action applies to - e.g.  volume, network port etc.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> -- action this permission allows - e.g. start vm, create volume.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- An authorize API call which accepts: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - the service requesting the authorization<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> -  user token (from a previous authentication) <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - tenant ID (to resolve the realm of the user token)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - a target type<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> -  the attempted action.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> This API would lookup the token, and if its present combine a set of the relevant permissions from all the roles the token is referencing. If the requested tuple exists in this combine set, the request is authorized.<u></u><u></u></p>

</div>
</div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<div>
<div>
<div><div class="im">
<div>
<p class="MsoNormal">A few caveats remain:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">a) the above description doesn't include Resource Groups... as Ziad mentioned, that is currently differed. When those are introduced, the service should probably pass the instance-id of the target, and Keystone would have to take that into
 account.<span style="color:#1F497D"><br>
JLR>>  I think there are a number of ways to account for this if we leveraged a hierarchical (URI) structure and allowed for wild carding.
</span><u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><font color="#00970A">ZNS>> We start to get in the world of policies here (lookup XACML)</font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<span>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><div class="im">
<div>
<p class="MsoNormal">b) the current API's in keystone allows a service to perform actions on multiple instances across tenants (containers) efficiently - a service could obtain a list of accessible tenants and cache it. If only the 'authorize' API is available,
 the service would need to perform a check with keystone for every instance <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif">JLR>> Please explain the model for Tenant, Accounts, Projects, Groups, Roles…. I have not been able to discern how tenant will map to accounts and
 projects.  In any case, there are things that can be done to improve the potential overhead of authorization calls… however, you will not eliminate it completely.  That is the price you pay for increased security.  If authorization is pluggable, operators
 can determine if and how they want to use it.<u></u><u></u></span></p>
</div>
</div><div>
<p class="MsoNormal"><font color="#00970A">ZNS>>tenants are the same as account in swift and project in Nova. The term tenant is not as overloaded as account, so we chose it.</font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<span>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><div class="im">
<div>
<p class="MsoNormal">c) In this model it is required to populate role definitions into keystone, for all services. Since keystone should be independent of other services,  the set of actions/targets should probably be considered as ""data"" for it - requiring
 a deployment step of sorts to make keystone aware of these roles.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This could be avoided if the authorization decision is looked at as 2 separate steps:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> 1. figure out what roles a user posses. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> 2. expand the set of roles to set of actions allowed<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> 3. determine if the action attempted is allowed<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif">JLR>> Each service would need to document its target structure and actions (this would be very similar to their published API’s).  I think there
 would be a default set of roles and permissions pre-populated to satisfy the base set of use cases.     <u></u><u></u></span></p>
</div>
</div><div>
<p class="MsoNormal"><u></u><font color="#00970A">ZNS>>Maybe there are some built-in or reserved ones for Keystone and/or OpenStack (Ex keystone:admin and compute:admin). I'd suggest they were configurable if we did do that… but would
 help simplify a fast install and canonical deployment of OpenStack.</font><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
<div><br>
</div>
<span>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><div class="im">
<div>
<p class="MsoNormal">it is obviously debatable where keystone ends and the services begin. In the model above, keystone is responsible for all 3 steps via the authorize API. I *think* the current API provides a very similar model, with the line drawn at 1 -
 i.e. keystone provides to roles, and there is a separate middleware piece to perform 2 & 3, executing in the request pipleline of the service. Where this middleware executes (i.e. what is the API boundary to keystone) doesn't necessarily change the overall
 model. <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;color:rgb(31, 73, 125);font-family:Calibri, sans-serif"><br>
JLR>>  Without a pluggable authorization system, operators will never be able to provide fine-grained access control without mucking with hardcoding in the API layer.  That is not a good path<u></u><u></u></span></p>

</div>
</div><div>
<p class="MsoNormal"><font color="#00970A">>>ZNS: Indeed. A slippery slope. We want to provide core functionality out of the box, but we don't want to end up writing a complete IDM solution…</font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span><div><div></div><div class="h5">
<div><br>
</div>
<span>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">I *think*.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services) <<a href="mailto:jason.rouault@hp.com" target="_blank">jason.rouault@hp.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">In my opinion the services (and their developers) should not need to interpret roles thus resulting in varying semantics.  Roles should
 be defined by a set of configurable privileges to perform certain <u>actions</u> on specific
<u>targets</u> for particular <u>services</u>.   The API should only need to know to check with an authorization subsystem whether the incoming request is allowed based on the who is making the request and the 3-tuple mentioned previously. 
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Jason</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> andi abes [mailto:<a href="mailto:andi.abes@gmail.com" target="_blank">andi.abes@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, June 15, 2011 9:18 AM<br>
<b>To:</b> Rouault, Jason (Cloud Services)<br>
<b>Cc:</b> Ziad Sawalha; <a href="mailto:openstack@lists.launchpad.net" target="_blank">
openstack@lists.launchpad.net</a><br>
<b>Subject:</b> Re: [Openstack] OpenStack Identity: Keystone API Proposal</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I would expect that the API of each service would have to interpret the role assigned to a user in the context of that service - roles for swift nova glance quantum etc would probably
 carry very different semantics.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">So, to my understanding, key stone provides authentication and user information - what tenants the user has access to, and what roles the user is assigned. The mapping of these
 to what the user can do on what instances in each service are left for the service to determine.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Wed, Jun 15, 2011 at 10:32 AM, Rouault, Jason (Cloud Services) <<a href="mailto:jason.rouault@hp.com" target="_blank">jason.rouault@hp.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Is there a plan to also have Keystone be the centralizing framework around authorization?   Right now it looks like policy enforcement
 is left to the API layer.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Thanks,<br>
<br>
Jason</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> openstack-bounces+jason.rouault=<a href="http://hp.com" target="_blank">hp.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>
 [mailto:<a href="mailto:openstack-bounces%2Bjason.rouault" target="_blank">openstack-bounces+jason.rouault</a>=<a href="http://hp.com" target="_blank">hp.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>]
<b>On Behalf Of </b>Ziad Sawalha<br>
<b>Sent:</b> Friday, June 10, 2011 5:24 PM<br>
<b>To:</b> <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
<b>Subject:</b> [Openstack] OpenStack Identity: Keystone API Proposal</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so
 we can finalize implementation by Diablo-D2 (June 30th).</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here:
<a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">
https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf</a></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">For any and all interested, the original source and code is on Github (<a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">https://github.com/rackspace/keystone</a>),
 along with the current implementation of Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at
<a href="http://launchpad.net/keystone" target="_blank">http://launchpad.net/keystone</a>.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community
 input, feedback, and participation.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">Have a great weekend and regards to all,</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black">Ziad</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;color:black"> </span><u></u><u></u></p>
</div>
<pre><span style="color:black"> </span><u></u><u></u></pre>
<pre><span style="color:black">Confidentiality Notice: This e-mail message (including any attached or</span><u></u><u></u></pre>
<pre><span style="color:black">embedded documents) is intended for the exclusive and confidential use of the</span><u></u><u></u></pre>
<pre><span style="color:black">individual or entity to which this message is addressed, and unless otherwise</span><u></u><u></u></pre>
<pre><span style="color:black">expressly indicated, is confidential and privileged information of Rackspace.</span><u></u><u></u></pre>
<pre><span style="color:black">Any dissemination, distribution or copying of the enclosed material is prohibited.</span><u></u><u></u></pre>
<pre><span style="color:black">If you receive this transmission in error, please notify us immediately by e-mail</span><u></u><u></u></pre>
<pre><span style="color:black">at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.</span><u></u><u></u></pre>
<pre><span style="color:black">Your cooperation is appreciated.</span><u></u><u></u></pre>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</div></div><font face="monospace">This email may include confidential information. If you received it in error, please delete it.</font></div>

</blockquote></div><br></div>