Open Stack

Sharing this with the community in general as folks interested in keystone discuss implementing a capability of adding "grouping" to the structures. The blueprint related is https://blueprints.launchpad.net/keystone/+spec/user-groups, and Henry sent a note a week or so ago to the general list inviting feedback.

google doc with proposed API: https://docs.google.com/document/d/1Ce6iVPl38_7fNHENNtfCXIrXVQIFqOZZgX0zNIzFLSo/edit
etherpad with general discussion/questions: https://etherpad.openstack.org/keystone-user-groups

- joe

Begin forwarded message:
> From: David Chadwick <d.w.chadwick at kent.ac.uk>
> Subject: Re: The way forward for supporting groups of users
> Date: November 17, 2012 9:28:06 AM PST
> To: Henry Nash <henry.nash at mac.com>
> Cc: Joe Heck <heckj at mac.com>, Adam Young <ayoung at redhat.com>, Dolph Mathews <dolph.mathews at gmail.com>, Guang Yee <guang.yee at hp.com>, Kristy Siu <kwss2 at kentforlife.net>
> 
> Hi Henry
> 
> Thanks for your summary, which is fine.
> 
> Given that federation will be implemented in the medium term, there is nothing to stop components of it being implemented now. For example, Kristy has just shown me how the directory function needed for federation can be implemented using an enhanced services catalog with the existing interface, and she will distribute the design for this on Monday for you guys to comment upon.
> 
> I would therefore support implementing the mapping function now to support current use cases (option 2 below) then it can subsequently be used by federation when the latter is integrated. I dont think the API for attribute/role mapping will be that difficult to define. The tricky thing is to get the access controls right, so that each organisational administrator is only allowed to map his organisational roles/attributes into the cloud service roles that the cloud administrator has granted him access to (we call this the administrative scope of the organisational administrator). For example, there may be an admin role defined for a cloud service, which has super-user privileges that the cloud administrator uses, but he does not want the organisational administrators to have access to this. So when they perform role mapping they would not be allowed to map their staff or programmer role, say, into the admin role.
> 
> The first step could be to have a design blueprint for mapping that we all contribute to. If you are happy to proceed on this basis, maybe Henry, or Kristy and myself, can start on this next week
> 
> regards
> 
> David
> 
> On 17/11/2012 13:56, Henry Nash wrote:
>> Hi
>> 
>> I think you have all seen the bp for groups of users, and thanks to
>> Guang and David for your detailed comments.  I think right now there
>> are no outstanding questions in terms of the actual proposal in of
>> itself - other than the interesting point of view from David that in
>> fact you could achieve the same affect by using the role mapping
>> concept from the federation proposal.  I'll try and summarize David's
>> point (David, feel free to interject if I have this wrong)
>> 
>> For federation, in order to be able to effectively use/chose from
>> many external Identity Providers and Attribute Authorities, there
>> must be mapping between the attributes/roles that the cloud service
>> itself understands and those defined by those external authorities.
>> [This is proposed to be a function of the Openstack Gateway in the
>> current federation proposal].  One could therefore imagine extending
>> this to where this could also be used to map the customer defined
>> roles (e.g. Teacher, Pupil) to roles that were exposed by the Gateway
>> for the cloud service required.
>> 
>> So I think we need to discuss how best to move forward.  In my mind
>> there are a few options:
>> 
>> 1) Just bundle this requirement up with federation.
>> 
>> 2) Implement a role mapping capability that is broadly api compatible
>> with what we will do with federation.  In this we would take the
>> first steps at re-deinfing the terminology (i.e. what's a cloud
>> service attribute and what's a locally-defined role), provide a
>> mapping capability, start to evolve the appropriate Ui etc.
>> 
>> 3) Just implement the groups concept as defined.  In the long run
>> maybe this is replaced (or made redundant) by role mapping, but only
>> if we chose to drive the federation mapping into non-federated
>> configurations of openstack.
>> 
>> My concerns are: a) Federation is a really important capability we
>> need and will get delivered in the future.  Given its scope, however,
>> pretty sure this is not a Grizzly item - and maybe even longer? b) We
>> will always have this balancing act of what features we put in a
>> "self-contained" (i.e. non-federated) openstack implementation - and
>> I feel the basic assignment (using today's keystone terms) of roles
>> to groups of users is imperative for large enterprise use (it is
>> certainly what we have found in other products)
>> 
>> However, I'd been keen to this group's view of these options.  I do
>> believe that grouping or mapping is an important capability we need
>> to add - and really want to find a way of getting this into Grizzly
>> in some shape or form.
>> 
>> Henry
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121117/f0ef2d57/attachment.html>