<div dir="ltr"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 9:31 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
As per the discussion during the keystone IRC meeting yesterday, I have been reviewing the proposals for this functionality. There have been two objections to the current proposal (which can be found here: <a href="https://review.openstack.org/#/c/29781/10" target="_blank">https://review.openstack.org/#/c/29781/10</a>), which are:<br>
<br>
1) The api changes should allow for a logical, generic future extension for support of inherited roles across all domains etc., should we chose to go that route<br>
2) The use of a single api to list the various grants, filtered by a query string if necessary.<br>
<br>
My proposal for handling these two objections is as follows:<br>
<br>
1) API extensions.<br>
<br>
There are several aspects of inherited roles that we are trying to cement, which are:<br>
<br>
a) The are dynamic - i.e. this isn't a case of a short hand for saying add this role to all the current projects in the domain - rather it is a role assignment that is attached to the domain but is added to the effective roles of any project (now and in the future) that exists in this domain<br>
b) The are separate from a role that is on the domain itself - i.e. we need to ensure that we keep separate inherited and non-inherited roles.<br>
c) Maintain the philosophy that If you can create a role assignment with a given API, there should be an equivalent to read it back and delete it (i.e. you mustn't have the case where, for instance you can list a grant, but can't delete it at the conceptual level)<br>
<br>
The current proposal had been to do this by adding an "inherited" component of the url for create, check and delete grants to a domain, e.g.<br>
<br>
PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}<br>
PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited<br>
GET /domains/{domain_id}/users/{user_id}/roles/{role_id}<br>
GET /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited<br>
DELETE /domains/{domain_id}/users/{user_id}/roles/{role_id}<br>
DELETE /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited<br>
etc.<br>
<br>
A counter proposal has been made to expand this, along this lines of:<br>
<br>
Role applicable to all projects within a domain<br>
PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/projects<br>
<br>
Roles inherited by all projects in all domains<br>
PUT /usrs/{user_id}/roles/{role_id}/projects<br>
<br>
Roles inherited by all domains, at the domain level<br>
PUT /usrs/{user_id}/roles/{role_id}/domains<br>
<br>
While I understand the desire to have extensibility if we wish to provide more "global-ness" of roles, I think the above proposal is less clear about whether these assignments are dynamic (see item a) above). How about this as a counter proposal:<br>
<br>
Role applicable inherited by all projects within a domain (this is the same as the current proposal)<br>
PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited<br>
<br>
Roles inherited by all projects in all domains - if we were to ever support this (not part of the current proposal)<br>
PUT /domains/users/{user_id}/roles/{role_id}/inherited<br></blockquote><div><br></div><div>This just looks broken to me, and ugly at best. I'd suggest special-purposing an unreserved character:</div><div><br></div>
<div> PUT /domains/*/users/{user_id}/roles/{role_id}/inherited<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Roles inherited by all domains, at the domain level - if we were to ever support this (not part of the current proposal)<br>
PUT /domains/users/{user_id}/roles/{role_id}/inherited<br>
<br>
To go along with the above, you would have the respective GET, CHECK & DELETE versions of those apis.<br></blockquote><div><br></div><div>s/CHECK/HEAD/</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2) Single vs multiple apis<br>
I think this comment is actually misplaced in the gerrit review, and is intended to directed at the api extensions I proposed to allow the list of a users "effective" roles on a project (i.e. directly assigned, those by virtue of group membership and inheritance from the parent domain). For this, I proposed adding an optional "effective" query parameter to each of:<br>
<br>
List user's roles on project: `GET /projects/{project_id}/users/{user_id}/roles<br>
List group's roles on project: `GET /projects/{project_id}/groups/{group_id}/roles<br>
Check user's role on project: `GET /projects/{project_id}/users/{user_id}/role/{role_id}<br>
Check group's roles on project: `GET /projects/{project_id}/groups/{group_id}/role/{role_id}<br>
<br>
e.g. GET /projects/{project_id}/users/{user_id}/roles?effective<br>
...would get you the effective roles the user has on that project, as opposed to only the directly assigned ones if you issue the call without the "effective" query parameter.<br>
<br>
Dolph and I had already been discussing that the existing v3 api of:<br>
<br>
GET /users/{user_id}/roles<br>
<br>
...which is meant to return all the role assignments for a user, but is in fact broken in the current Grizzly code (it always returns an error). So I agree with the proposal that we should scrap the "effective" query parameter for the specific list/check calls for the project - and instead properly implement the "get all assignments for a user" call. I propose the amended spec for this call is:<br>
</blockquote><div><br></div><div>(keep this in a separate review, as I think it represents scope creep beyond the above discussion)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
#### List a user's effective role assignments: `GET /users/{user_id}/role-assignments`<br>
<br>
query_string: page (optional)<br>
query_string: per_page (optional, default 30)<br>
query_string: id, project_id, domain_id<br>
<br>
Response:<br>
<br>
Status: 200 OK<br>
<br>
[<br>
{<br>
"id": "--role-id--",<br>
"name": "--role-name--",<br>
"project_id": "--project-id--",<br>
"source":<br>
{<br>
"direct": true, (optional)<br>
"domain_inherited: "--domain-id--", (optional)<br>
"group_membership: "--group-id--" (optional)<br>
}<br>
},<br>
{<br>
"domain_id": "--domain-id--",<br>
"id": "--role-id--",<br>
"name": "--role-name--",<br>
"source":<br>
{<br>
"direct": true, (optional)<br>
"group_membership: "--group-id--" (optional)<br>
}<br>
}<br>
]<br>
<br></blockquote><div><br></div><div>This is going to be a heavy call with heavy usage... I'm not sure if the following would result in a lighter/heavier response on average. A role could be assigned via multiple groups, on multiple projects and on multiple domains. That means multiple "conflicting" sources (each without links to manage them in the current proposal) and that means the same role would appear in the list over and over, given the current structure. I'd suggest enumerating "projects" and "domains" explicitly and replacing "source" with something based on links to the actual assignment(s). Given the potential for role assignments without any context ("global roles"), I think the role must be the base entity here (?).</div>
<div><br></div><div>I'm really not sold on the "source" element, because I think that the true source of a role is much more complicated than proposed structure can possibly describe, especially without utilizing links. There are *currently* 4 possible "sources" of a role assignment, a few of which would take multiple links to describe properly.</div>
<div><br></div><div><div><div>- domain-user-role assignment</div><div>- domain-group-role assignment + user-group membership</div><div>- project-user-role assignment</div><div>- project-group-role assignment + user-group membership</div>
</div><div><br></div><div style>Including domain role assignments inherited to owned projects adds:<br></div><div><br></div><div><div>- domain-user-inherited role assignment + domain-project ownership</div><div>- domain-group-inherited role assignment + user-group membership + domain-project ownership</div>
</div></div><div><br></div><div style>And global role assignment adds at least four more sources that would look a lot like the current four.</div><div style><br></div><div style>Bottom line is that I don't see the value in publishing this information if the user can't do anything with it (like DELETE a provided link to destroy a relationship and remove the role).</div>
<div style><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The "source" structure must have at least one of the values given above (and could have more than one, e.g. both domain_inherited and global_membership for a project where the role is due to a group role that is inherited from the domain). If were even to support global roles across all domains, then we would extend the "source structure" accordingly. I'm open to other options for the above format. however, so comments welcome.<br>
<br>
Does this sounds like a reasonable plan overall?<br>
<br>
Henry<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>