Open Stack

On Thu, Jun 6, 2013 at 5:48 AM, David Chadwick <d.w.chadwick at kent.ac.uk>wrote:

> Hi Henry
>
> My take on this is that whether a role is automatically inheritable or not
> should be an attribute of the role itself, and should be independent of who
> the role is assigned to. Therefore when the role is initially defined, it
> should be stated by the Keystone admin whether it is an inherited role or
> not.
>
> Role assignment is a separate issue and should not be confused with the
> basic definition of the role. Role assignment should simply be a matter of
> naming the subject (domain, project or user) and the role. If you dont want
> the role to be inherited then use a non-inheritable role.
>
> The problem with all the APIs below is that they conflate role definition
> and role assignment together in the same API call. There should be no need
> to have user_ids in the definition of a role. Similarly there should be no
> mention of inherited in the assignment of a role to a user.
>
> regards
>
> David
>
>
+1; I really like the simplicity of this approach, and it sounds like
something we can migrate to easily (e.g. default inheritable=False for
existing roles). Then global role assignments would follow an API like:

  GET /users/{user_id}/roles  # list global roles
  HEAD /users/{user_id}/roles/{inheritable_role_id}  # check if a global
role is assigned
  PUT /users/{user_id}/roles/{inheritable_role_id}  # assign a global role
  DELETE /users/{user_id}/roles/{inheritable_role_id}  # revoke a global
role

where a non-inheritable role assigned a user without a domain or project
for context wouldn't make any sense. In fact, assigning an inheritable role
to a user on a project wouldn't be very useful (as it wouldn't inherit to
anything in the core API), but I don't see a reason to deny it.


> On 05/06/2013 15:31, Henry Nash wrote:
>
>> Hi
>>
>> 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:
>> https://review.openstack.org/#**/c/29781/10<https://review.openstack.org/#/c/29781/10>),
>> which are:
>>
>> 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
>> 2) The use of a single api to list the various grants, filtered by a
>> query string if necessary.
>>
>> My proposal for handling these two objections is as follows:
>>
>> 1) API extensions.
>>
>> There are several aspects of inherited roles that we are trying to
>> cement, which are:
>>
>> 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
>> 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.
>> 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)
>>
>> 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.
>>
>> PUT /domains/{domain_id}/users/{**user_id}/roles/{role_id}
>> PUT /domains/{domain_id}/users/{**user_id}/roles/{role_id}/**inherited
>> GET /domains/{domain_id}/users/{**user_id}/roles/{role_id}
>> GET /domains/{domain_id}/users/{**user_id}/roles/{role_id}/**inherited
>> DELETE /domains/{domain_id}/users/{**user_id}/roles/{role_id}
>> DELETE /domains/{domain_id}/users/{**user_id}/roles/{role_id}/**inherited
>> etc.
>>
>> A counter proposal has been made to expand this, along this lines of:
>>
>> Role applicable to all projects within a domain
>> PUT /domains/{domain_id}/users/{**user_id}/roles/{role_id}/**projects
>>
>> Roles inherited by all projects in all domains
>> PUT /usrs/{user_id}/roles/{role_**id}/projects
>>
>> Roles inherited by all domains, at the domain level
>> PUT /usrs/{user_id}/roles/{role_**id}/domains
>>
>> 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:
>>
>> Role applicable inherited by all projects within a domain (this is the
>> same as the current proposal)
>> PUT  /domains/{domain_id}/users/{**user_id}/roles/{role_id}/**inherited
>>
>> Roles inherited by all projects in all domains - if we were to ever
>> support this (not part of the current proposal)
>> PUT  /domains/users/{user_id}/**roles/{role_id}/inherited
>>
>> Roles inherited by all domains, at the domain level - if we were to ever
>> support this (not part of the current proposal)
>> PUT  /domains/users/{user_id}/**roles/{role_id}/inherited
>>
>> To go along with the above, you would have the respective GET, CHECK &
>> DELETE versions of those apis.
>>
>> 2) Single vs multiple apis
>> 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:
>>
>> List user's roles on project: `GET /projects/{project_id}/users/{**
>> user_id}/roles
>> List group's roles on project: `GET /projects/{project_id}/groups/**
>> {group_id}/roles
>> Check user's role on project: `GET /projects/{project_id}/users/{**
>> user_id}/role/{role_id}
>> Check group's roles on project: `GET /projects/{project_id}/groups/**
>> {group_id}/role/{role_id}
>>
>> e.g. GET /projects/{project_id}/users/{**user_id}/roles?effective
>> ...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.
>>
>> Dolph and I had already been discussing that the existing v3 api of:
>>
>> GET /users/{user_id}/roles
>>
>> ...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:
>>
>> #### List a user's effective role assignments: `GET /users/{user_id}/role-
>> **assignments`
>>
>> query_string: page (optional)
>> query_string: per_page (optional, default 30)
>> query_string: id, project_id, domain_id
>>
>> Response:
>>
>>      Status: 200 OK
>>
>>      [
>>          {
>>              "id": "--role-id--",
>>              "name": "--role-name--",
>>              "project_id": "--project-id--",
>>              "source":
>>              {
>>                  "direct": true,  (optional)
>>                  "domain_inherited: "--domain-id--", (optional)
>>                  "group_membership: "--group-id--" (optional)
>>              }
>>          },
>>          {
>>              "domain_id": "--domain-id--",
>>              "id": "--role-id--",
>>              "name": "--role-name--",
>>              "source":
>>              {
>>                  "direct": true, (optional)
>>                  "group_membership: "--group-id--" (optional)
>>              }
>>          }
>>      ]
>>
>> 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.
>>
>> Does this sounds like a reasonable plan overall?
>>
>> Henry
>>
>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130607/5f1f93e8/attachment.html>