Federated IdP attribute mapping proposal


John Dennis
 

I've been working on adding federated authentication. One of the
requirements is the ability to receive attributes from an external IdP
and map them into the roles and other attributes used internally by
OpenDaylight. An administrator will author a set of rules, one for each
external IdP which will defined how the foreign attributes are mapped.

We looked to other authentication/authorization systems for guidance, in
particular Openstack's federation support in Keystone and my experience
with RADIUS.

I would like you to review the proposed solution which is documented here:

http://jdennis.fedorapeople.org/federated_mapping/mapping.html

I have a working proof-of-concept implementation written in Python
(because Python is the language of OpenStack and this will also be
proposed for OpenStack and because I was able to do rapid prototyping in
Python allowing me to flesh out ideas quickly). Provided the proposal is
acceptable the idea is to implement it in Java. If the proposal is also
accepted in OpenStack I'll likely maintain 2 parallel implementations,
one in Python and one in Java.

You may find it instructional to initially read this introductory
document which explains the rationale for the approach taken and
possible alternatives.

http://jdennis.fedorapeople.org/federated_mapping/strategy.html

You will note I discuss 2 different possible solutions, scripts and
rules. The above proposal is rule based because several people I had
discussions with felt scripts were an advanced feature and I should
concentrate on something simpler. As you can see from the proposal I'm
not sure the rule based system is simpler to implement or use. In fact
I'm still of the opinion a script based system is easier to implement,
easier to use and will have fewer potential bugs.

--
John


Nguyen, Liem Manh <liem_m_nguyen@...>
 

Hi John,

 

Thanks for putting this together.  I like both approaches!  I think both have merits, strengths and weaknesses.

 

I like the template/rule-based approach for its simplicity; however, I think that we should limit its functionality to just sed/awk type transformation, because going beyond that (like embedding control/flow logics) makes it more complicated and diminishes the promised simplicity benefit of this approach...  Kinda reminds me of assembly language and microcode <shiver/> :)

 

However, I do recognize that for some "real-world" use-cases, we may have a need for control logics.  In these cases, my preference would be to use a scripting language that I am familiar with to express control logics rather than using JSON (which is intended to be a data exchange format, after all), for all the reasons you mentioned, including debuggability.

 

So, I think we can start out with just a set of awk/sed type rules to do simple transformations but also allow additional (pluggable) rules to be defined and evaluated elsewhere in an external script.  Not sure if you have looked into it, but Java does have a built-in Javascript engine that you can use to execute Javascript from within the JVM.  Java 6/7 uses the Rhino engine, while Java 8 uses the Nashorn engine which is supposed to be faster than Rhino:

 

http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html

 

As for security, we should be able to leverage Karaf security to gate access to the bundle that loads the script, assuming the embedded script engine is used.

 

Regards,

Liem

 

 

-----Original Message-----
From: aaa-dev-bounces@... [mailto:aaa-dev-bounces@...] On Behalf Of John Dennis
Sent: Wednesday, July 23, 2014 8:04 AM
To: aaa-dev@...
Subject: [Aaa-dev] Federated IdP attribute mapping proposal

 

I've been working on adding federated authentication. One of the requirements is the ability to receive attributes from an external IdP and map them into the roles and other attributes used internally by OpenDaylight. An administrator will author a set of rules, one for each external IdP which will defined how the foreign attributes are mapped.

 

We looked to other authentication/authorization systems for guidance, in particular Openstack's federation support in Keystone and my experience with RADIUS.

 

I would like you to review the proposed solution which is documented here:

 

http://jdennis.fedorapeople.org/federated_mapping/mapping.html

 

I have a working proof-of-concept implementation written in Python (because Python is the language of OpenStack and this will also be proposed for OpenStack and because I was able to do rapid prototyping in Python allowing me to flesh out ideas quickly). Provided the proposal is acceptable the idea is to implement it in Java. If the proposal is also accepted in OpenStack I'll likely maintain 2 parallel implementations, one in Python and one in Java.

 

You may find it instructional to initially read this introductory document which explains the rationale for the approach taken and possible alternatives.

 

http://jdennis.fedorapeople.org/federated_mapping/strategy.html

 

You will note I discuss 2 different possible solutions, scripts and rules. The above proposal is rule based because several people I had discussions with felt scripts were an advanced feature and I should concentrate on something simpler. As you can see from the proposal I'm not sure the rule based system is simpler to implement or use. In fact I'm still of the opinion a script based system is easier to implement, easier to use and will have fewer potential bugs.

 

--

John

 

_______________________________________________

Aaa-dev mailing list

Aaa-dev@...

https://lists.opendaylight.org/mailman/listinfo/aaa-dev