Open Stack

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