Open Stack

Hi Henry

on the definition of inherited roles, I dont think this should be part 
of the role name, but rather, each role should have meta information 
attached to it, in its role table definition, that indicates the 
properties of the role definition. In this way, you can make the role 
definition extensible by adding new columns to the table as and when 
needed e.g. if in future you want to have global roles inherited by 
domains, you add a new column, say GlobalToDomain, which could be a 
boolean with a default value of false, and with a value true indicating 
that it is inherited from global to domain. All pre-existing roles would 
not be of this type, and therefore all pre-existing code would work 
without this new inheritance.

I would not alter the role-user assignment API as this should simply 
specify the role and user and project. The code may need enhancing in 
the future, if new types of inheritance are added, in order to cater for 
cases where the role is wrongly specified by the administrator i.e. it 
does not apply to the project in question through lack of inheritance.

regards

David

On 08/06/2013 11:38, Henry Nash wrote:
> So on the idea of using the role def for inheritance definition, there
> were a couple of things that concerned me about it:
>
> 1) While it definitely can simply the api changes required for the
> current requirements, I worry that we are passing the complexity on to
> the creation of the policy file.  Since the role names of an inherited
> and non-inherited role will obviously have to be different, is there a
> danger that policy files end up with lots of rules that have "role: xxxx
> and role: xxxx_inherited"?  I guess we can make the argument that since
> (with today's requirements at least) the only objects that will end of
> inheriting an assignment will be projects, the likelihood is that the
> api lines in the policy file that contains inherited and non-inherited
> will be different, hence avoiding the problem.  However, if, in the
> future, we were to expand inheritance to support all domains, or all
> projects in all domains, then this problem would arise for
> domain-relevant apis lines in the policy file.
>
> 2) If, again, in the future we support inheritance across all
> domains/projects - would we need to more fine grained control of the
> inheritance?  For instance, we want a role that was inherited by all
> domains, but not the projects in each domain?  Perhaps, one could
> imagine expanding the role-def to somehow indicate this (maybe rather
> than just having a simple "inherited" boolean, we specify
> "project_inherited", to which we could, in the future, add
> "domain_inherited"?).  We also have the problem of how you assign such a
> role?  I guess you would still need some kind of modification to the
> assignment APIs to indicate "all domains" (perhaps the "domains/*" that
> was suggested)?
>
> I'd be interested in views on the above - I'm Ok fi we decide that
> role-def is the right way to go, but want to make sure we clearly
> understand how we would expand this in the future.
>
> Henry
> On 7 Jun 2013, at 18:12, Dolph Mathews wrote:
>
>>
>>
>> On Thu, Jun 6, 2013 at 5:48 AM, David Chadwick
>> <d.w.chadwick at kent.ac.uk <mailto: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
>>         <mailto: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
>>     <mailto: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
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>