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