remote_id_attribute config options prevents multiple protocol variations for Federation

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

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:

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

remote_id_attribute = MELLON_IDP

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:

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.

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 We renamed to[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'.


    Change-Id: I23fc3f1f651c12c4e3c1987dc71008e6e97b4ed8
    Related-bug: #1724645

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

I marked as a duplicate of this bug

Changed in keystone:
assignee: nobody → erus (erus)
status: Confirmed → In Progress
Changed in keystone:
assignee: erus (erus) → Colleen Murphy (krinkle)

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

    Closes-bug: #1724645

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

    Change-Id: I9802c8a5c187bae16de89893ca8639b01cd7cb1b

Changed in keystone:
status: In Progress → Fix Released

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

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