Hi John there is another way of tackling this problem, based on the following assumption "We know the person who should be authorised, but we dont know what random set of attributes the IDP will provide for him (or if we do know, they are as horrible as you indicated in your example below)".
We will demonstrate this solution this week at the keystone design summit. It is based on the administrator sending the user (out of band) the name of the group he is invited to join (specified as a Virtual Organisation name and role) plus a secret. The user logs in with his IDP, the IDP sends the unknown/horrible set of attributes to keystone, the user asks to join the group and presents the secret, and our code automatically adds a mapping rule specifically for this user to put him in the group. The user can either be automatically added to the group, or put in a pending queue for the administrator to OK at a later time. Users who try to hack in are blacklisted if they present a wrong secret for 3 times. Would this solve your problem? regards David On 04/11/2014 15:30, John Dennis wrote: > 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. > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
