potential user_id conflict when REMOTE_USER is set

[Guang Yee]

For Federation, the identity is validated outside of Keystone and its attributes are conveyed in the request environment. One of them is REMOTE_USER. If this attribute is present, Keystone will indiscriminately invoke the "external" plugin to "authenticate"

https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L496

Since the default "external" plugin is DefaultDomain, it automatically validated the user in the "Default" domain. This is not the end of it, the authentication sequence will continue with other plugins.

https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L516

For Federation, the Mapped plugin is also being invoked to validate the attributes in the request environment. Now consider this scenario.

 1. There are two distinct users with the same username "foo", one in the "Default" domain while other is in the "BAR" domain.
 2. The external Federation modules (i.e. mod_shib) sets the REMOTE_USER attribute.
 3. Mapping which maps the incoming identity to "foo" in the "BAR" domain.

This will result in user_id conflict because the first "external" plugin sets the user_id for user "foo" in the "Default" domain, while the Mapped plugin is trying to set the user_id for "foo" in the "BAR" domain.

https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L121

One may argue that this is a "corner case". That it can be avoided by

 1. configuring the external Federation modules not to set the REMOTE_USER attribute, or
 2. disabling the "external" auth plugin

However, "external" auth with DefaultDomain is enabled by default. We really need to clearly distinguish "externa" auth from mapped auth. Do not invoke both at the same sequence. At the very least, I think this scenario need to be clearly documented. Moreover, I think we should deprecated "external" auth plugins altogether and enhance the Mapped plugin to support direct scoped token request. "external" auth is just another form of Mapped auth IMO.

[Dolph Mathews (dolph)]

There is pretty good reasoning for having it enabled by default for v3 (it can't be disabled for v2, as documented in the following link), and we already have docs on how to enable it:

  http://docs.openstack.org/developer/keystone/external-auth.html#configuration

I'm not sure we can reasonably deprecate it, because I'd wager it's used quite heavily in some deployments.

All that said, perhaps we should be documenting that it should be explicitly disabled if you're using federation?

[Guang Yee (guang-yee)]

Dolphm, I agree, documenting the behavior when using federation should be adequate. I'll submit a doc patch.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/339165
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=82c7b8bedcc18d47722efa852ebaf5024bb9f846
Submitter: Jenkins
Branch: master

commit 82c7b8bedcc18d47722efa852ebaf5024bb9f846
Author: “Richard <email address hidden>
Date: Thu Jul 7 17:54:49 2016 +0000

    Doc update on enabled external auth and federation

    By default the external auth is enabled and can cause user_id conflict
    when REMOTE_USER is set due to the fact that federation uses
    REMOTE_USER as well. Therefore, the docs were updated to advise users
    against using both external auth and federation on the same sequence.

    Closes-Bug: #1563454

    Change-Id: I193f78ae0ad0232471b725d5700870c349703310

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/keystone 10.0.0.0b2 development milestone.