On Mon, 2016-05-02 at 11:49 -0400, John Dennis wrote:
On 05/02/2016 09:17 AM, Simo Sorce wrote:
> On Thu, 2016-04-28 at 17:48 +0000, Patrick Uiterwijk wrote:
>> Hi,
>>
>> I have been thinking about this for a while now, and a question on our
>> IRC channel earlier today
>> got me thinking about it again.
>>
>> Our current implementation for attribute mapping in provider plugins
>> works for basic cases, but has
>> a set of limitations.
>> For example, it is not possible to map when the attribute is more than
>> 2 levels deep, and the only
>> mapping we support is a literal mapping of one attribute to another.
>>
>> In the past, we discussed adding a more extensive mapping and
>> filtering system system, but that was
>> deemed as being too complicated to set up for admins.
>> I was thinking that we might be able to make the attribute mapping
>> quite a bit more powerful by adding
>> some indicators after which we would parse the values differently.
>>
>> Two that I would like to propose are " and !, for respectively literal
>> text and executed python code.
>> So, for example, to always provide the text "mycompany" via the
>> attribute companyname, one would
>> configure the "companyname" attribute to be mapped to:
"mycompany".
>> If they would want an even more powerful system, they could do
>> something like !return username.lower()
>> to get it processed by Python.
>> If none of those characters are detected in the first place, it would
>> do a standard recursive lookup, like
>> we do now. To make it possible to map more than two levels, we could
>> allow strings like _extras/ldap/uid.
>>
>> With this setup, admins who need it simple can continue to use their
>> current configuration, but admins that
>> need more power would be able to get it.
>>
>> This is just a thought, but does anyone have feedback on it?
>
> It would be nice to have a pluggable system, so you can tweak your
> mapping at will in python by just dropping a module in place.
I agree with Simo, mapping is best done by executable code.
I've used and written a variety of mapping systems. Many try to offer a
simple set of rules to evaluate, they are never sufficient for real
world use cases. I truly believe to do mapping correctly you need the
power of a full language. But why implement a new language to do mapping
when you've got perfectly valid languages already? The only downside to
allowing loadable Python code to execute is trusting the loaded code is
not malicious because it will be difficult to restrict what it can
perform. I don't mean to down play this concern but trusting admins is
already presumed.
No loading/eval of python code from the admin API.
You develop your mapping module, and you install it on the server, then
you just enable/disable it.
My suggestion for the API interface would be to pass a JSON struct in
and have it return a JSON struct which is the mapped result. You may
also need to pass in some type of context information to help the mapper.
I think the current python dictionary is ok to represent the mapping,
why introduce JSON at this point ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York