Open Stack

Hi, 

To my opinion these are two complementary solutions which can coexist. 
Even though federation may be used to group the internal users as well, it 
is useful to have a simple definition of users and groups as it is done in 
most common file systems. These definitions may allow using alternative 
pluggable authorization methodologies without any dependency on the RBAC 
of Keystone or any external IAM. Thus, I would like to vote in favor of 
starting with the simple group model proposed by Henry. The federation 
model may be later enhanced as well providing a comprehensive solution for 
the integration with external IAMs. 

Best Regards,
Alex. 

----------------------------------------------------------
Alexandra Shulman-Peleg, PhD
Storage Research, Cloud Platforms Dept.
IBM Haifa Research Lab
Tel: +972-3-7689530 | Fax: +972-3-7689545



From:   Henry Nash <henryn at linux.vnet.ibm.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   20/11/2012 02:27 PM
Subject:        Re: [openstack-dev] [Keystone] Adding support for groups 
of users



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
> 
> 
> 
> 
> 


_______________________________________________
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/20121120/0510c283/attachment.html>