potential user_id conflict when REMOTE_USER is set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Wishlist
|
Richard |
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:/
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:/
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:/
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.
Changed in keystone: | |
importance: | Undecided → Wishlist |
Changed in keystone: | |
assignee: | nobody → Richard (csravelar) |
Changed in keystone: | |
status: | Triaged → In Progress |
Changed in keystone: | |
assignee: | Richard (csravelar) → Samuel de Medeiros Queiroz (samueldmq) |
Changed in keystone: | |
assignee: | Samuel de Medeiros Queiroz (samueldmq) → Richard (csravelar) |
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?