Hi Marek, Done. ;)
Regards, Ioram 2015-08-03 8:07 GMT+01:00 Marek Denis <marek.de...@cern.ch>: > Hi Ioram, > > How about moving this discussion to the mailing list? Maybe others will > find it useful too. > > cheers, > Marek > > On 02.08.2015 11:28, Ioram Schechtman Sette wrote: > >> Hi Marek, hi all, >> >> Just to complement, I thought in some cases that I don't know how they >> are handled by the mapping engine. >> >> For instance: >> >> - Remote attribute "a1" with value "v1" maps to domain/user "D1/U1" >> - Remote attribute "a2" with value "v2" maps to domain/user "D1/U2" >> >> If the remote user has the attributes "a1=v1" and "a2=v2", will he >> be mapped to D1/U1 or D1/U2? >> >> The situation can be repeated for different combinations of local users >> and groups. >> >> Using the super set (union) of the privileges of D1/U1 and D1/U2 to the >> remote user, I think it solves the problem. >> According to this reasoning, the expression "local": {"user": {"name": >> "{0}"}} will mean that we will search for a local user whose name >> matches the remote user id in order to get its privileges. >> The set of privileges can be increased if other mapping rules also >> matches to other users or groups. >> >> Regards, >> Ioram >> >> >> 2015-07-30 17:32 GMT+01:00 David Chadwick <d.w.chadw...@kent.ac.uk >> <mailto:d.w.chadw...@kent.ac.uk>>: >> >> >> Hi Marek >> >> Thanks for the clear exposition. >> >> To answer your question Why are you interested in such a feature? is >> that it seemed to be the logical thing to do. A user is identified by >> a >> set of identity attributes (by the IdP) and these are mapped into >> permission by mapping rules. I assume the admin who sets up the >> mapping >> rules knows what he is doing, and if he wants a remote user to have >> the >> privileges of a local user plus some more, then the easiest way to do >> this would be to map into one or more groups plus the local user. >> >> Since the same thing can be achieved by creating a new group >> equivalent >> to the local user, and mapping the remote user into all of these >> groups, >> then why downgrade the most logical (and easiest) way of achieving the >> same ultimate objective? >> >> regards >> >> David >> >> >> On 30/07/2015 11:26, Marek Denis wrote: >> > Hi David, >> > >> > On 29.07.2015 18:59, David Chadwick wrote: >> > >> >> this is very helpful thanks, and it answers our question. >> >> >> >> So to summarise, you can map a federated user into multiple >> groups, or >> >> into an existing local user/domain, but not into both, since the >> latter >> >> will override the former and the groups will be discarded. Was >> this >> >> behaviour actually discussed anywhere? ie. why cannot a >> federated user >> >> have a superset of the permissions of a local user and some >> additional >> >> groups? >> > >> > Well, it was mostly discussed at one of the Keystone midcycles, I >> think >> > the one in January. The spec for this (along with new keyword >> > 'whitelist' and 'blacklist') can be found here: >> > >> >> https://github.com/openstack/keystone-specs/blob/master/specs/kilo/federated-direct-user-mapping.rst >> > >> > >> > And to answer your question "why a federated user cannot have a >> superset >> > of the permissions of a local user and some extras" is probably >> because >> > we wanted to simply leverage authentication to IdP, not create any >> > superpower user. Also, it is because the returned identity is >> 'existing >> > user', with her/his id, set of role assignments on a >> project/domain. I >> > am not sure it's good to be able to dynamically upgrade average >> users - >> > if so, i'd rather make 'ephemeral users with all the role >> assignments >> > equal to user X'. >> > Why are you interested in such a feature? We can probably discuss >> it on >> > a ML as Morgan suggested and >> > >> > >> >> On 29/07/2015 15:01, Marek Denis wrote: >> >>> Hi David, all, >> >>> >> >>> Thanks for your e-mail. >> >>> I will quickly respond to your question about mapping rules. >> >>> >> >>> Currently we can map to either ephemeral user (who is dynamically >> >>> assigned some group memberships) as well as existing user. >> >>> For the latter you need to specify a mapping rule a user_id and >> an >> >>> existing domain. >> >>> Currently there is a service domain called 'Federated' and >> ephemeral >> >>> users are members of that one. >> >>> >> >>> So for mapping to existing users you should build your rule like: >> >>> >> >>> user: { >> >>> "id": "madenis" >> >>> "domain": { >> >>> "name": "CERN" >> >>> } >> >>> } >> >>> >> >>> Mapping engine will see the domain is not "Federated" and will >> actually >> >>> query for user madenis. If there is no such user authentication >> will >> >>> fail. >> >>> Please note, that any extra group memberships mandated by other >> mapping >> >>> rules are discarded when we map to an existing user - as a >> response he >> >>> get what he has configured locally regarding role assignmnets on >> >>> projects/domains. >> >>> >> >>> Hope this helps, >> >>> >> >>> Marek Denis >> >>> >> >>> On 29.07.2015 15:52, David Chadwick wrote: >> >>>> Hi Guys >> >>>> >> >>>> I have a student working on an attribute mapping GUI for >> Horizon. He >> >>>> has >> >>>> published his screen shots using InVision, here >> >>>> >> >>>> https://openstack.invisionapp.com/d/main#/projects/3983114 >> >>>> >> >>>> Could you take a look and see what you think. >> >>>> >> >>>> One quick question about the mappings. Is only mapping to groups >> >>>> supported, or can you map to a user and a domain instead? >> >>> >> >>> >> >>> >> >>> >> >>> >> > >> >> >>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev