Open Stack

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.mathews at gmail.com
>> <mailto:dolph.mathews at gmail.com>> wrote:
>>
>>> On Sunday, November 2, 2014, John Dennis <jdennis at redhat.com
>>> <mailto:jdennis at 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