<font size=2 face="sans-serif">Hi, </font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">Best Regards,</font>
<br><font size=2 face="sans-serif">Alex. </font>
<br>
<br><font size=2 face="sans-serif">----------------------------------------------------------<br>
Alexandra Shulman-Peleg, PhD<br>
Storage Research, Cloud Platforms Dept.<br>
IBM Haifa Research Lab<br>
Tel: +972-3-7689530 | Fax: +972-3-7689545</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Henry Nash <henryn@linux.vnet.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">20/11/2012 02:27 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[Keystone] Adding support for groups of users</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>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<br>
<br>
- 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).<br>
- This gives us clear problems in two user scenarios<br>
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: </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/user-groups"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/user-groups</font></tt></a><tt><font size=2>.
 <br>
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.<br>
<br>
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:<br>
<br>
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<br>
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)<br>
<br>
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.  <br>
<br>
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.<br>
<br>
Again, interested in other people's views.<br>
<br>
Henry<br>
On 17 Nov 2012, at 21:28, Henry Nash wrote:<br>
<br>
> Hi<br>
> <br>
> Expanding a discussion regarding: </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/user-groups"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/user-groups</font></tt></a><tt><font size=2><br>
> <br>
> Thanks to Guang Yee and David Chadwick for their detailed comments.
 I think right now there<br>
> are no outstanding questions in terms of the actual proposal in of<br>
> itself - other than the interesting point of view from David that
in<br>
> fact you could achieve the same affect by using the role mapping<br>
> concept from the federation proposal.  I'll try and summarize
David's<br>
> point:<br>
> <br>
> "For federation, in order to be able to effectively use/chose
from<br>
> many external Identity Providers and Attribute Authorities, there<br>
> must be mapping between the attributes/roles that the cloud service<br>
> itself understands and those defined by those external authorities.<br>
> [This is proposed to be a function of the Openstack Gateway in the<br>
> current federation proposal].  One could therefore imagine extending<br>
> this to where this could also be used to map the customer defined<br>
> roles (e.g. Teacher, Pupil) to roles that were exposed by the Gateway<br>
> for the cloud service required."<br>
> <br>
> So I think we need to discuss how best to move forward.  In my
mind<br>
> there are a few options:<br>
> <br>
> 1) Just bundle this requirement up with federation.<br>
> <br>
> 2) Implement a role mapping capability that is broadly api compatible<br>
> with what we will do with federation.  In this we would take
the<br>
> first steps at re-deinfing the terminology (i.e. what's a cloud<br>
> service attribute and what's a locally-defined role), provide a<br>
> mapping capability, start to evolve the appropriate Ui etc.<br>
> <br>
> 3) Just implement the groups concept as defined.  In the long
run<br>
> maybe this is replaced (or made redundant) by role mapping, but only<br>
> if we chose to drive the federation mapping into non-federated<br>
> configurations of openstack.<br>
> <br>
> My concerns are: a) Federation is a really important capability we<br>
> need and will get delivered in the future.  Given its scope,
however,<br>
> pretty sure this is not a Grizzly item - and maybe even longer? b)
We<br>
> will always have this balancing act of what features we put in a<br>
> "self-contained" (i.e. non-federated) openstack implementation
- and<br>
> I feel the basic assignment (using today's keystone terms) of roles<br>
> to groups of users is imperative for large enterprise use (it is<br>
> certainly what we have found in other products)<br>
> <br>
> However, I'd been keen to this group's view of these options.  I
do<br>
> believe that grouping or mapping is an important capability we need<br>
> to add - and really want to find a way of getting this into Grizzly<br>
> in some shape or form.<br>
> <br>
> David's comments to the above:<br>
> <br>
> Hi Henry<br>
> <br>
> Thanks for your summary, which is fine.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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<br>
> <br>
> regards<br>
> <br>
> David<br>
> <br>
> <br>
> <br>
> <br>
> <br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>