Open Stack

On 11/04/2014 02:46 AM, David Chadwick wrote:
> Hi John

Good morning David. I hope you're enjoying Paris and the summit is both
productive and enjoyable. Wish I was there :-)

> Its seems like your objective is somewhat different to what was intended
> with the current mapping rules. You seem to want a general purpose
> mapping engine that can map from any set of attribute values into any
> other set of values, whereas the primary objective of the current
> mapping rules is to map from any set of attribute values into a Keystone
> group, so that we can use the existing Keystone functions to assign
> roles (and hence permissions) to the group members. So the current
> mapping rules provide a means of identifying and then authorising a
> potentially random set of external users, who logically form a coherent
> group of users for authorisation purposes.

O.K. group assignment is the final goal in Keystone. I suppose the
relevant question then is the functionality in the current Keystone
mapper sufficiently rich such that you can present to it an arbitrary
set of values and yield a group assessment? It's been a while since I
looked at the mapper, things might have changed, but it seemed to me it
had a lot of baked in assumptions about the data (assertion) it would
receive. As long as those assumptions held true all is good.

My concern arose from real world experience where I saw a lot of "messy"
data (plus I had a task that had some other requirements). There is
often little consistency over how data is formatted and what data is
included when you receive it from a foreign source. Now combine the
messy data with complex rules dictated by management and you have an
admin with a headache who is asked to make sure the rules are
implemented. An admin might have to implement something like this:

"If the user is a member of domain D and has authenticated with
mechanisms X,Y or Z and has IdP attribute A but does not have suffix S
in their username and is not in a blacklist then assign them group G and
transform their username by stripping the suffix, replacing all hyphens
with underscores and lowercase it."

I'll grant you this example is perhaps a bit contrived but it's not too
far afield from the questions I've seen admins ask when trying to manage
actual RADIUS deployments. BTW, where is that domain information coming
from in the example? Usually it has to be extracted from the username in
any one of a number of formats.

It's things like this that motivate me towards a more general purpose
mechanism because at the end of the day the real world isn't pretty :-)

FWIW FreeRADIUS didn't start out with a policy language with
capabilities like this, it grew one out of necessity.

I'm definitely not trying to say Keystone needs to switch mappers,
instead what I'm offering is one approach you might want to consider
before the current mapping syntax becomes entrenched and ugly real world
problems begin to crop up. I don't have any illusions this solution is
ideal, these things are difficult to spec out and write. One advantage
is it's easy to extend in a backwards compatible manner with minimal
effort (basically it's just adding a new function you can "call").

FWIW the ideal mapper in my mind is something written in a general
purpose scripting language where you have virtually no limitations on
how you transform values and enforce conditions, but as I indicated in
my other document managing a script interpreter for this task has its
own problems. Which is the lesser of two evils, a script interpreter or
a custom policy "language"? I don't think I have the answer to that but
came down on the side of the custom policy "language" as being the most
palatable and portable.

> Am I right in assuming that
> you will also want this functionality after your general purpose mapping
> has taken place?

The mapper I designed does give you a lot of flexibility to assign a
foreign identity to a group (or multiple groups) with no additional
steps so I'm not sure I follow the above comment. There is no need for
any extra or multiple steps, it should be self contained.



-- 
John