remote_id_attribute config options prevents multiple protocol variations for Federation

[Adam Young]

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

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.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/513960

[Adam Young (ayoung)]

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

[Guang Yee (guang-yee)]

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

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.

[OpenStack Infra (hudson-openstack)]

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

[Colleen Murphy (krinkle)]

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

[OpenStack Infra (hudson-openstack)]

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

commit bf67b3c88409d2f0b2086d363ed91394953d85ba
Author: erus <email address hidden>
Date: Tue Feb 19 17:32:07 2019 -0300

    Add new attribute to the federation protocol API

    Modify the FederationProtocolModel class and add the
    remote_id_atributte to the federation_protocol table.
    Add the respective migration and tests files. And
    also modify the schema to expect a remote_id_attribute
    property.

    Closes-bug: #1724645

    Co-authored-by: Colleen Murphy<email address hidden>

    Change-Id: I9802c8a5c187bae16de89893ca8639b01cd7cb1b

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 16.0.0.0rc1 release candidate.