yahoo-eng-team team mailing list archive

[Guang Yee <1563454@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: keystone
     Importance: Wishlist
         Status: New

** Changed in: keystone
   Importance: Undecided => Wishlist

-- 
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):
  New

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