yahoo-eng-team team mailing list archive

[OpenStack Infra <1563454@xxxxxxxxxxxxxxxxxx>]

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 <csravelar@xxxxxxxxx>
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


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1563454

Title:
  potential user_id conflict when REMOTE_USER is set

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1563454/+subscriptions