Open Stack

Hi Marek,

Done. ;)

Regards,
Ioram


2015-08-03 8:07 GMT+01:00 Marek Denis <marek.denis at 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.chadwick at kent.ac.uk
>> <mailto:d.w.chadwick at 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?
>>      >>>
>>      >>>
>>      >>>
>>      >>>
>>      >>>
>>      >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/af6a2e73/attachment.html>