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?
Regards, Patrick Uiterwijk
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.
Simo.
On Mon, May 2, 2016 at 1:17 PM, Simo Sorce simo@redhat.com wrote:
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.
Would you suggest making it possible to entirely replace the mapping code, or to add a new "postmapping" plugin hook, which happens after the current mapping process? (or premapping?)
Simo.
Patrick
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.
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.
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.
On 05/02/2016 12:04 PM, Simo Sorce wrote:
On Mon, 2016-05-02 at 11:49 -0400, John Dennis wrote:
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.
I don't see the practical difference. You're allowing unknown code to execute execute in a security sensitive context (necessitates admin or root privilege in some form). That for good reason should give a lot of people pause and is what I believe drives the unrelenting invention of mapping rules (because evaluating a constrained set of rules greatly limits unintended access and dangerous side effects).
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 ?
You're right, it's not really needed. I was thinking of other scenarios that do not apply to Ipsilon.
On 05/02/2016 11:49 AM, John Dennis wrote:
I've used and written a variety of mapping systems.
FWIW, I wrote a general purpose mapping processor, there is an implementation in both Python and Java. It is documented here:
https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf
See the section "Mapping Rule Processor"
ipsilon@lists.stg.fedorahosted.org
-
John Dennis -
Patrick Uiterwijk -
Simo Sorce