remote_id_attribute config options prevents multiple protocol variations for Federation

Bug #1724645 reported by Adam Young on 2017-10-18
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Low
Unassigned

Bug Description

In order to activate a protocol for Federation, you need SOME value for remote_id_attribute. However , this is set once per protocol in the config file, not in the federated data. Thus, if two different SAML implementations both wanted to use different values for remote_id_attribute (DN vs CN for example) they could not.

Colleen Murphy (krinkle) wrote :

The workaround is to do something like this in the config:

[auth]
methods = [...],saml2_mellon, saml2_shib
saml2_mellon = keystone.auth.plugins.mapped.Mapped
saml2_shib = keystone.auth.plugins.mapped.Mapped

[saml2_mellon]
remote_id_attribute = MELLON_IDP

[saml2_shib]
remote_id_attribute = Shib-Identity-Provider

It would be nice if we could make this more intuitive.

Adam Young (ayoung) wrote :

remote_id_attribute should be added to the protocolo object such as in the create call here:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/backends/base.py#n96

Changed in keystone:
status: New → Confirmed
importance: Undecided → Low
tags: added: feder
tags: added: federation
removed: feder
Guang Yee (guang-yee) wrote :

For Federation, we can't cleanly demarcates configuration from (API) operation, as we have other third party dependencies (i.e. Apache, mellon, shibd, haproxy, etc). In other words, you can't just add a new provider, protocol, and mapping via API, and whalah things just magically work. You'll also need to adjust the 3rd party services before the data even gets to the Keystone app.

While being able to dynamically configure the remote_id_attribute is nice, but I am not sure it is a giant leap for mankind, so to speak. :-) I am OK with making the documentation more intuitive.

Adam Young (ayoung) wrote :

The fact that we can modify both tthe Federation protocol object *AND* the Apache config means that we do not need to be able to also tweak things inside the configuration file, and right now, that config is making it impossible to the the federation protocol right. So, yes, we need to drop the config option from the file and move it to the federation protocol, and no, that will not negatively impact our ability to make things work based on the Apache config.

The Apache Config will, for the most part, determine whether to let a parameter through from the assertion or not. In some cases, it will perform minor modifications of a parameter, but it will be something like whether to remove the REALM from a Kerberos principal. Having the configuration value in file will not do anything that having it in the protocol object (or mapping, to be honest) would not do any way.

Reviewed: https://review.openstack.org/513960
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=cbdc84ac7fc88e891968116db4866dc719337b16
Submitter: Zuul
Branch: master

commit cbdc84ac7fc88e891968116db4866dc719337b16
Author: Colleen Murphy <email address hidden>
Date: Sat Oct 21 20:38:34 2017 +0200

    Partially clarify federation auth plugins

    Federation protocols in keystone are very confusing due to the way they
    have evolved since the original service provider implementation where
    the auth plugin was defined in saml2.py. We renamed saml2.py to
    mapped.py[1] and now we can effectively support any federation protocol
    as long as there is some kind of Apache module that can understand it
    and pass certain IdP and user attributes through to keystone. So we
    started recommending not using the 'saml2' auth plugin and instead using
    the 'mapped' plugin, eventually removing the the notice when we removed
    the plugin[2]. Since the name of the federation protocol resource
    created in keystone must match one of the [auth]/methods, we also
    changed the documentation to start creating the 'mapped' protocol and
    use 'mapped' in the Apache settings[3]. This was really the wrong
    course. 'mapped' is not a protocol. Using only 'mapped' prevents us from
    defining multiple remote_id_attributes for different protocols.

    This patch changes references to the 'mapped' protocol and 'mapped'
    plugin back to 'saml2' (we never changed the openid ones). While the
    saml2 plugin does not itself exist, it is defined as an entrypoint to
    the mapped plugin, so it all works out. This doesn't solve the problem
    for if we want to define different remote_id_attributes for different
    SAML2.0 implementations, but there is a workaround for that[4]. Using
    'saml2' as the protocol name is just much more intuitive than 'mapped'.

    [1] https://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/keystone/juno/generic-mapping-federation.rst
    [2] https://review.openstack.org/#/c/397456/
    [3] https://review.openstack.org/#/c/371210/
    [4] https://bugs.launchpad.net/keystone/+bug/1724645/comments/1

    Change-Id: I23fc3f1f651c12c4e3c1987dc71008e6e97b4ed8
    Related-bug: #1724645

tags: added: office-hours
Colleen Murphy (krinkle) wrote :

I marked https://bugs.launchpad.net/keystone/+bug/1585472 as a duplicate of this bug

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers