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?
regards David 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
