<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>