[openstack-dev] [Keystone] Alternative federation mapping

David Chadwick d.w.chadwick at kent.ac.uk
Tue Nov 4 07:46:23 UTC 2014

Hi John

Its seems like your objective is somewhat different to what was intended
with the current mapping rules. You seem to want a general purpose
mapping engine that can map from any set of attribute values into any
other set of values, whereas the primary objective of the current
mapping rules is to map from any set of attribute values into a Keystone
group, so that we can use the existing Keystone functions to assign
roles (and hence permissions) to the group members. So the current
mapping rules provide a means of identifying and then authorising a
potentially random set of external users, who logically form a coherent
group of users for authorisation purposes. Am I right in assuming that
you will also want this functionality after your general purpose mapping
has taken place?



On 03/11/2014 20:58, John Dennis wrote:
> On 11/03/2014 08:50 AM, John Dennis wrote:
>> I had a bunch of notes but I can't find them at the moment
>> so I'm going from memory here (always a bit risky).
> I found my notes, attached is an reStructured text document that
> summarizes the issues I found with the current Keystone mapping, the
> basic requirements for mapping based on my prior experience and reasons
> for selecting the approach I did. I hope this explains the motivations
> and rationale to put things into context.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list