Open Stack

On 25 July 2015 at 04:02, Adam Young <ayoung at redhat.com> wrote:
> This has come up numerous times, as I am sure you are now aware by reading
> the rest of the thread.

Yes indeed :)  I was thinking as I wrote it that I can't be the first
person with this question.

However I think Daviey has shown me that I was misunderstanding how
assignment worked, and I suspect that I can do what I need to do
already
(Thanks Dave!).

Having said that, I still think there's value in doing more with
groups, more below.

> A couple points;  I've been aware of the hybrid driver for several years.  I
> feel it is a security mistake to copy the users from the system of record
> (LDAP) into a cache (Keystone) and then tro only trust the values in the
> cache;  if I delete or disable a user in LDAP, that should be the state
> used, not the cached value.
>
> Groups are tricky things.  While I've often toyed with what you suggest
> here, I always come back to the `group` being an identity attribute that
> exists outside of Keystone, and everything that we do inside of Keystone can
> be done with existing mechanisms in Keystone itself, especially now that we
> have Hierarchical Multitenantcy.

I've honestly never thought of "group" being an identity attribute;
for me it relates to authorization management — being part of a group
grants access to something.  Anyway, that's slightly tangential to
this discussion.

> The most common reason for a group is to be able to share access to multiple
> tenants.  This is broken up into a handful of use cases:

Right, this is part of the problem, although you could consider it an
optimization. A very useful one though.

> 1.  All in one organization, multiple projects
> 2.  Users from a remote organization get mapped in to a local set of
> projects (but not all...)
> 3.  A virtual organization
>
>
>  I'd like to see the problems you are dealing with to evaluate if splitting
> groups from users makes sense.

My situation has several *completely independent* Openstack
deployments that wish to share a common identity service (also
preferably without having to log in to each, but that will be solved
later with federation).

Each user may or may not have the same access rights across each
deployment, hence the need to fine-tune roles/assignments. In the case
where multiple projects exist, are we going to have to specify an
assignment for each user to each project? It would be nicer to do this
through groups. I'm not sure which of the 3 cases of yours above this
maps to, but possibly all of them.

We could of course do this through a federated identity service, but
this then requires each user to be separately configured in the
federation group mapping which is very quickly going to get completely
untenable for large numbers of groups and users.  The mapping could
also map to local users, and that brings me back to the original
problem I raised at the start of the thread.

TL;DR
1. User assignments to projects will probably work for me.
2. Doing it with groups will be a lot nicer and easier to administer

Cheers
J