Open Stack

Since I will be gone next week, and I know you want to move on with 
this, just wanted to confirm that I am OK with Henry's approach.

I would like to suggest that we contemplate doing to inheritance 
mechanism at assignment time as opposed to token creation time as an 
optimization.  What would this mean?

Say a domain role-assignement implies a project role assignment. When a 
new project is created, we generate the role-assignments for the users 
that have domain entries explicitly at this point.

The objection I assume would be along the lines of "how are you sure you 
are going to get it right" and "that is going to generate a lot more 
entries in the database" which are both valid concerns.  However, token 
creation is far, far more common than changes to role assigments, and we 
should focus on optimizing for this use case.  In addition, it will 
remove the need for "effective" role assignments.

One concern would be with "if we drop the inheritance relationship, what 
do we do with all those people that have that role already." We would 
have the choice of removing the role-assignments then, or of leaving 
them in place, and having to manually remove them.  We would have no 
means to distinguish between explicit and implicit role assignments.  I 
could entertain arguments on either approach, or even an additional 
parameter specifying what to do upon removal of the domain level assignment.


I don't see this as "make-or-break" but rather an implementation detail 
worth considering now.

This would be consistent with the token revocation approach, where we 
make the effort to revoke all tokens at the time of the event.



On 06/13/2013 09:49 AM, Henry Nash wrote:
> Thanks Guang  - I have added responses, as well as tried to articulate 
> the conceptual differences that actually underpin all these 
> approaches.  This is in the intro in the etherpad, but reproduced below:
>
> Before looking at the possible solutions, it is worth pointing out 
> that the differences in the various options boil down to how we 
> approach two conceptual issues:
>
> 1) How should we specify an assignment that applies to more than one 
> entity? There are two conceptual approaches:
> - Use Inheritance, based on some grouping, hopefully one that already 
> exists (e.g. use the fact that all projects are owned by a domain)
> - Use a logical expression (e.g. "apply to "*" )
> The differences in these two concepts gets amplified if we want to be 
> able, in the future, to further segregate role assignmnets based on 
> some other subset (e.g. either hierachy of domains, or 'apply to 
> domains matching the string "army*" )
>
> 2) Should you specify the "scope" of the assignment separately from 
> the assignment?
> - Keeping them separate is considered good practice by our experts in 
> this field, and this can be done by either storing the scope in 
> another entity (e.g. the role def) or separatly in the assignment call.
> - If you don't keep them separate, then obviously it is all lumped 
> into the assignment call.
>
> The  proposed solutions only differ  fundamentally in how the approach 
> these concepts (with consequences in the use cases below), the rest is 
> just semantics.
>
> Henry
> On 12 Jun 2013, at 22:46, Yee, Guang wrote:
>
>> Added my comments in the etherpad.
>>
>> ----
>>
>> I really think role assignment merits its own CRUD. Since there's a 
>> new API
>> to get the role assignments.
>>
>> GET /role_assignments
>>
>> why not just have the complete API set to facilitate role 
>> assignments? That
>> way, we have one unified API for role
>> assignment, as oppose to multiple APIs as exist today.
>>
>> To get a role assignment:
>>
>> GET /role-assignments/{role_assignment_id}
>>
>> To remove a role assignment:
>>
>> DELETE /role-assignments/{role_assignment_id}
>>
>> To create a role assignment:
>>
>> POST /role_assignments
>>
>> {"role_assignment": {
>>    "user" {
>>        "id": user_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>> }
>>
>> Note: "user" and "scope" is similar to the data structure in auth 
>> APIs. i.e.
>> can be either "id" or "name" + "domain".
>> If assignment is for a group, just have "group" in there instead of 
>> "user".
>> For example,
>>
>> {"role_assignment": {
>>    "group" {
>>        "id": group_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>> }
>>
>> Upon successful creation, a assignment_ref is returned.
>>
>> {"role-assignment": {
>>    "id": role_assignment_id
>>    "user": {
>>        "id": user_id
>>    },
>>    "role": {
>>        "id": role_id
>>    },
>>    "scope": {
>>        "domain": {
>>            "id": domain_id
>>        },
>>        "project": {
>>            "id": project_id
>>        }
>>    }
>>    "links": {
>>        "self":
>> "http://localhost:35357/v3/role-assignments/{role_assignment_id} 
>> <http://localhost:35357/v3/role-assignments/%7Brole_assignment_id%7D>"
>>    }
>> }
>>
>> "scope" is basically the combination and permutation of domains and
>> projects. "domain_id" or "project_id" can be "*" to denote all.
>>
>> Role assignment is really about assigning a given [role] to a given 
>> [user or
>> group]
>> for [a given project | a given domain | all projects within a given 
>> domain |
>> all projects in all domains | all domains].
>>
>> To assign a given role to a given user or group for [a given project]
>>
>> "scope": {
>>    "project": {
>>        "id": project_id
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all the projects 
>> in a
>> given domain]
>>
>> "scope": {
>>    "domain": {
>>        "id": domain_id
>>    },
>>    "project": {
>>        "id": "*"
>>    }
>> }
>>
>> To assign a given role to a given user or group for [a given domain]
>>
>> "scope": {
>>    "domain": {
>>        "id": domain_id
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all the projects 
>> in all
>> domains]
>>
>> "scope": {
>>    "domain": {
>>        "id": "*"
>>    },
>>    "project": {
>>        "id": "*"
>>    }
>> }
>>
>> To assign a given role to a given user or group for [all domains]
>>
>> "scope": {
>>    "domain": {
>>        "id": "*"
>>    }
>> }
>>
>>
>> The advantages of role_assignments CRUD are:
>>
>> 1) simplicity (one API for role assignment, instead of multiple)
>> 2) extensible (similiar to the auth API design). Say we need an 
>> assignment
>> at the federated level, we can simply add a new scope.
>> 3) consistency (with the auth APIs)
>> 4) RESTful (no need to worry about * in the path)
>>
>>
>>
>> Guang
>>
>> -----Original Message-----
>> From: Tiwari, Arvind
>> Sent: Wednesday, June 12, 2013 9:29 AM
>> To: Henry Nash
>> Cc: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi Henry,
>>
>> Thanks for looking in to my comments, I was trying to raise #3 from your
>> list.  Any ways lets discuss this topic on etherpad from here onwards.
>>
>> Thanks,
>> Arvind
>> ________________________________________
>> From: Henry Nash [henryn at linux.vnet.ibm.com 
>> <mailto:henryn at linux.vnet.ibm.com>]
>> Sent: Wednesday, June 12, 2013 10:58 AM
>> To: Tiwari, Arvind
>> Cc: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi
>>
>> So what you have described is correct, in terms of needing multiple 
>> roles IF
>> you want one role that only goes to projects and one that doesn't (e.g.
>> maybe goes to just domains). Role explosion was the issue raised against
>> using the role def to hold inheritance behaviour, when it was first
>> discussed.  However, I'd make the following comments:
>>
>> 1) Most services don't need to be concerned about domains, just 
>> projects -
>> in fact, today, only keystone understands domains.  Hence there 
>> really won't
>> be a role explosion  in terms "Number of Services" x "Multiple roles 
>> due to
>> inheritance to projects or domains"
>> 2) In addition, I can imagine than often a cloud provider will create 
>>  roles
>> that are project related separate from those that are domain related 
>> - they
>> tend to be different people doing those roles (e.g. user_group_admin vs
>> VM_admin etc.), so again, I think there won't be much of any 
>> additional role
>> explosion due to the inheritance rules between these roles
>> 3) What there might be, is some role explosions between roles that go 
>> to all
>> domains vs roles that go to individual domains - for that, you will need
>> multiple roles.
>> 4) For correctness (since we spend 40 mins on IRC on this :-) ), the
>> "inherited to:" field you use wasn't one of the discussed options - I 
>> agree
>> this is not the email to discuss that, but I don't want anyone 
>> thinking that
>> the structure below was one we looked at.
>>
>> For all:  The options being discussed are continuing on an etherpad, see:
>> https://etherpad.openstack.org/keystone-role-inheritance.  This 
>> contains all
>> the various options being considered, including links to the previous 
>> ones
>> we looked at (e.g. not using the role def)
>>
>> Henry
>> On 11 Jun 2013, at 21:18, Tiwari, Arvind wrote:
>>
>> Hi All,
>>
>> Role inheritance is very cool feature and we need this in product, but
>> letting RoleDef to drive the inheritance behavior seem wrong to me as it
>> will cause roleDef explosion and complex policy for services to support.
>>
>> Let's assume a requirement
>>
>> 1.       Cloud admin should have XYZ capability on all the projects, all
>> domains for Sev1. (Global inheritance)
>> 2.       Domain admin should have XYZ capability only on the projects in
>> specific domain for Sev1. (inheritance scoped to a domain)
>>
>> With the current approach (having inherited to in roleDef) we have to 
>> have
>> following two roleDefs to support the requirement and hence you have to
>> adjust the policy around these two roleDefs but end result is XYZ
>> capability.
>> {
>>    "role": {
>>        "id": "---id---",
>>        "inheritedTo": "domain=all and project=all", (This means, 
>> holder of
>> this role has XYZ capability in all projects in all domains) (Lets 
>> not worry
>> about the how we implement it enum / Boolean flag)
>>        "links": {
>>            "self": "http://identity:35357/v3/roles/76e72a"
>>        },
>>        "name": "XYZ-Role-4-cloud-admin"
>>    }
>> }
>>
>> {
>>    "role": {
>>        "id": "---id---",
>>        "inheritedTo": "project=all", (This means, holder of this role has
>> XYZ capability in all projects in specific domain)
>>        "links": {
>>            "self": "http://identity:35357/v3/roles/76e72a"
>>        },
>>        "name": " XYZ-Role-4-domain-admin "
>>    }
>> }
>>
>> Think about growing number of service and above mentioned requirement, we
>> will end up with so many  roleDefs which will have duplicate 
>> capability and
>> hence redundant info to maintain in policy. At the same time this 
>> solution
>> does not address separation of concerns, we are unnecessary 
>> overloading the
>> roleDefs to impose role inheritance behavior which is not its 
>> concern. The
>> above mentioned requirement can be easily achievable by single 
>> roleDef (may
>> be XYZ-role-Svc1) if we remove inheritedTo concern from roleDef and 
>> place it
>> some ware else, role assignment is the right place to address this 
>> concern,
>> how that we need to figure out.
>>
>> Let me know if the issue I mentioned looks legitimate.
>>
>>
>> Thanks,
>> Arvind
>>
>> From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
>> Sent: Monday, June 10, 2013 4:30 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [keystone] More on inherited domain roles
>>
>> Hi
>>
>> So I ave submitted two new api reviews around this:
>>
>> 1) Defining inherited roles - this is now done on the role def itself, as
>> suggested by David. See: https://review.openstack.org/#/c/29781/12
>> 2) The two un-implmented user/role apis have been replaces with a more
>> flexible way of listing role-assignments.
>> See:https://review.openstack.org/#/c/32394/2
>>
>> I'd like to push to get this nailed asap, so we can have a  shot at 
>> getting
>> the code in!
>>
>> Both of these extensions are designed to give us the option to to expand
>> this support for inheritance to all domains in the future if we chose.
>>
>> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130628/31621630/attachment.html>