On 11/03/2014 05:52 AM, David Chadwick wrote: > I agree with Morgan. We designed the current mapping functionality to > cover all the use cases we were aware of, but if there are more, then we > would love to hear about them and make the fixes that are necessary. > Attribute mapping is a critical component of federation, and it should > be fit for purpose > > regards > > David > > > On 03/11/2014 09:08, Morgan Fainberg wrote: >> >> On Nov 2, 2014, at 22:21, Dolph Mathews <dolph.math...@gmail.com >> <mailto:dolph.math...@gmail.com>> wrote: >> >>> On Sunday, November 2, 2014, John Dennis <jden...@redhat.com >>> <mailto:jden...@redhat.com>> wrote: >>> >>> It was hoped we could simply borrow the Keystone mapping >>> implementation but it was found to be too limiting and not >>> sufficiently >>> expressive. We could not find another alternative so we designed a new >>> mapper which is described in this PDF. >>> >>> >>> In what way was it too limited? Did you consider extending the >>> existing grammar and extending the existing mapping engine? >> >> I am very interested in knowing the limitations you ran into. I am >> fairly certain we are willing to update the engine to meet the needs of >> the deployers, but knowing what those limitations are and what this new >> proposed engine provides that we don't (for this use case) is important.
Of course, my apologies, I should have included that information originally. 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). A lot of what motivated me was years of experience with RADIUS which in many respect is often deployed as in a federated manner. Where the values that show up from foreign sources are often diverse. Admins have to write policy to recognize these foreign inputs and transform then into a local canonical format and operate on them. One of the most common and pernicious problems was the presence or absence of realm (i.e. domain) information included with the username. One has to be able to recognize the various formats (prepended, appended, diverse separator characters, etc.) and be able to extract the username from the domain and carry that information forward independently. Another problem that confronted us in OpenDaylight was the requirement to assign roles based on information in the assertion. That meant being able to form a set of roles and assign roles based on arbitrary data in the assertion (examples include specific usernames, presence or absence of attributes, presence or absence of a string value in an attribute, recognizing the *exact* value in the assertion that contains group membership, what the group separator is and treating the values as a set with the ability to determine if a value is a member of that set, etc.) * Hardcoded assumptions concerning values, e.g. any string value containing a colon is split on the colon. * Hardcoded assumption values are strings when in fact you may be presented with a list or a map of key/value pairs, or a value that needs to be treated as a number, boolean, or empty value (null). * Seemed if the structure forced a lot of redundancy. * Inability to store partial operations and reference them later. In other words no variables. * Inability to perform regular expression matching * Inability to perform regular expression replacement * Inability to split a string into components and reference those components * Inability to perform comparison operations. * Inability to determine the length of a string, list, or number of keys in a map, but more importantly inability to test if a value is empty or has exactly n members. * Inability split a string on an arbitrary separator and save the result in an ordered list. * Inability to perform case conversions * Inability to test for membership in a list or dict * Inability to join components using an arbitrary separator. * Inability to load site specific tables of information. HTH, -- John _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev