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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp