On 25 July 2015 at 04:02, Adam Young <ayo...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
