Open Stack

Hi Adam


On 19/06/2013 15:36, Adam Young wrote:
> The more I think about it, the more I think that tying the inheritance
> to the domain assignment is the wrong solution.

I tend to agree with you. Unless I have misunderstood Henry's API 
changes, it means that when a new project is created, existing users 
with existing inherited roles in existing projects, automatically get 
the same roles in the new project. I would have thought that usually 
different projects would have had different users working on them, and 
so you would not want this automatic role assignment to take place.

regards

David

>
> David/Kristy originally had the Mapping blueprint and patch.  It
> contained the ability to provide arbitrary rules for mapping from the
> identity attributes to the roles.  I think that it is time to implement
> that.
>
> It would be more correct to say that all users in a specific group
> (fetched out of Identity/LDAP) would get a specific role in a project
> than to say that a user with a domain role should therefore inherit a
> role in all projects.
>
> When creating a scoped token, we need to query a subset of the users
> identity information.  I think that the right direction for this query
> to flow would be:
>
> project->roles->role-mappings->groups
>
> as opposed to what we do now, which is to do a global query: give me all
> groups for this user and select which ones apply.  For LDAP/SQL Identity
> backends we want to trigger the miniaml query which is "let me know if
> the user is in groups G1, G2, G3..."  as those are the groups that
> potentially apply to role assignments for this project.
>
>
> So I'd like to redefine the problem definition here:
>
> "Provide a mechanism by which role assignments can be specified for more
> than one project."  One such rule would obviously be "all projects in
> domain D1"
>
> But it should be based on groups, not on domain role assignments.
>
>
>
>
> On 06/10/2013 11:41 AM, David Chadwick wrote:
>>
>>
>> On 10/06/2013 16:02, Henry Nash wrote:
>>> Hi David,
>>>
>>> I wasn't suggesting that we encode "inhertitness" in the name, just
>>> that if you want to have a role that is non-inherited and one that is
>>> inherited that relate to the same type of permission, then since role
>>> name must be globally unique, then the two roles must have different
>>> names....hence potentially leading to the complication in the policy
>>> file.
>>
>> I dont see why different role names would lead to complications in the
>> policy file, since policies are there to assign different permissions
>> to different roles.
>>
>> What can happen is that policy files can get very large and complex,
>> but that can happen regardless of whether roles are inherited or not,
>> and mistakes can be made by assigning the wrong roles to users or the
>> wrong permissions to roles, but again this is independent of the role
>> definition.
>>
>> regards
>>
>> David
>>>
>>> Henry On 10 Jun 2013, at 15:57, David Chadwick wrote:
>>>
>>>> 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
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> 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