Open Stack

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