Open Stack

So to try and take the discussion further, I think, we are really down to 2 options - either implement the current "user groups" proposal more-or-less as is or re-structure this to look more like what role mapping will be in any federation implementation.  Here's a brief comparison/analysis

- In general, a cloud service will define the various roles that it supports in its own native terminology.  In openstack today this is done within the policy.json files of each service.  Note that it is the service that defines the roles and how granular they are (e.g. you COULD define a role for calling each api, or you could cluster this together into some smaller subset of roles, as most services tend to - it's up to the service/endpoint).
- This gives us clear problems in two user scenarios
a) A cloud provider runs an openstack installation to host a cloud that has many large enterprises as customers.  For large customers with many users & projects it will often become impractical to assign each user specific roles on projects.  Rather they will want a away of "grouping" users together and assigning the role to that group of users to a project.  Note that grouping will be customer specific and cannot be defined by the cloud provider (since they don't know what groups make sense for any given customer, nor do they want to). For a more detailed example, see the blueprint: https://blueprints.launchpad.net/keystone/+spec/user-groups.  
b) For a user that visits many different clouds, how is it that the cloud providers can co-operate so that they agree on some standards for roles and authentication so that the user does not have to create all these separately with each cloud provider?  This is the core of the federation proposal - how the to enable cloud providers, customers, users and 3rd parties to agree on who will confirm identity and map roles that make sense to the customer and/or external standards into specific roles that the various service providers have defined.

The two proposal have grown up in an attempt to find solutions to a) and b).  The question is whether it is more appropriate to:

1) Extend the federation model to (effectively) include mapping between the customers-specifc roles created in a domain and the roles various cloud services within a non-federated openstack, or
2) Implemented a more specific, and more common, solution ("groups of users") for intra-openstack mapping and keep the federation mapping for its original design to engage across 3rd parties and multiple clouds (inter-openstack)

The added complication, is that we ideally want something we can do within Grizzly, i.e. that does not involve significant changes to the already implemented v3 Keystone APIs.  The full federation implementation is a Medium term goal, so if we took that option, we would need to implement the intra-openstack bit first, ahead of the full work.  

My personal preference, putting my cards on the table, is to go for the simpler, groups-of-users approach - since it is a common solution to this issue (in use by other products today), is a relatively simple extension to the current v3 API - and allows federation to concentrate on what it is designed to do.  Of course, as we know, you can adapt s/w to do (almost) anything, but this, to me, seems the best course.

Again, interested in other people's views.

Henry
On 17 Nov 2012, at 21:28, Henry Nash wrote:

> Hi
> 
> Expanding a discussion regarding: https://blueprints.launchpad.net/keystone/+spec/user-groups
> 
> Thanks to Guang Yee and David Chadwick for their 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:
> 
> "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.
> 
> David's comments to the above:
> 
> 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
> 
> 
> 
> 
>