Duplicate users (federated and sql) results in 401

[Eric Brown]

Release: Mitaka

I setup federation (saml2) with a product called vIDM which automatically has a user named "admin". I also have keystone configured to use a sql backend and have a user named "admin". These users exist on different domains (Federated) and (default), and have different user_ids, yet I cannot login with this federated user without a hard error:

2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] identity_values: [{u'group': {u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}, u'user': {u'name': u'admin'}}] process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:543
2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] mapped_properties: {'group_ids': [], 'user': {'domain': {'id': 'Federated'}, 'type': 'ephemeral', u'name': u'admin'}, 'group_names': [{u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}]} process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:545
2017-01-05 21:59:56.482 19546 WARNING keystone.common.wsgi [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] Authorization failed. Unable to reconcile identity attribute user_id as it has conflicting values 9b2dde9538864fc0ab7992bdbeb1f877 and e38f2348129a41d0940a29287c06a130 (Disable insecure_debug mode to suppress these details.) (Disable insecure_debug mode to suppress these details.) from 10.146.29.206

http://paste.openstack.org/show/594063/

[Eric Brown (ericwb)]

root@controller02:/home/viouser# openstack user list --long
Password:
+----------------------------------+-------------------+----------------------------------+----------------------------------+-------------+-------+---------+
| ID | Name | Project | Domain | Description | Email | Enabled |
+----------------------------------+-------------------+----------------------------------+----------------------------------+-------------+-------+---------+
| 0ad39c049606490bb3068256e0cc5ccd | browne | | None | | | True |
| 2abd39636fe14d28bc1fa32ebfb4d179 | cinder | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 2cb443b8fbf84574a3bc460c11a034b5 | vio-service | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 3afb280b434348ce89adb06b3fbf06c7 | nova | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 527dde44764d4f3ca6b8f50a68a9306b | ericwb | 8e67167398e74488a045b403a44dd326 | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 5edfe02f8bb7403987d12438c7163e8a | neutron | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 7c0f4e167b704985b9785ce2496fc975 | glance | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 8ba3a407d0b6448da1b8e1a93cbc40d1 | heat | ceabb23c085a4bdd80d870efad1aab3b | 4d216d7412ef47599e42a4c829ada905 | | | True |
| 907f97ca68f94d22a4ca72ad0213362c | vio-service | | default | | | True |
| 9b2dde9538864fc0ab7992bdbeb1f877 | admin | | None | | | True |
| e38f2348129a41d0940a29287c06a130 | admin | 701b5fafaf0f470eb77749ab0869714d | default | | | True |
| e916b1a1f79944c9bacfa6b6283f4261 | heat_domain_admin | | 4d216d7412ef47599e42a4c829ada905 | | | True |
| f90cb7cb04074d0dba5b37102586ad78 | ericwb | 701b5fafaf0f470eb77749ab0869714d | default | | | True |
+----------------------------------+-------------------+----------------------------------+----------------------------------+-------------+-------+---------+

[Lance Bragstad (lbragstad)]

It looks like the uniqueness constraint isn't being applied somewhere. Technically, they should be different users if they are in different domains.

[David Stanek (dstanek)]

I'm unable to product this in my test environment. When I login from testshib as 'superego' I get mapped to username 'testshib:<email address hidden>'. Here is my relevant user list:

# openstack --os-cloud devstack-admin user list --long | grep superego
| 76f9475610914883baf532efeb7798b9 | testshib:<email address hidden> | d7991f5fbaa54085a34261e7c3fe738d | default | | | True |
| bf3b8abda43a4d37bb24fe2b7198ddc9 | testshib:<email address hidden> | | None | | | True |

What does your mapping look like?

[Eric Brown (ericwb)]

I can recreate this consistently. Very easy to do in our environment (Mitaka based).

Here's the mapping:
http://paste.openstack.org/show/595841/

[Eric Brown (ericwb)]

Log: http://paste.openstack.org/show/595842/'

Output of user list: http://paste.openstack.org/show/595843/

So its confusing to me, but do the federated users always map to the Federated domain or not?

[Eric Brown (ericwb)]

Here's a traceback I created by raising a hard Exception.

http://paste.openstack.org/show/595846/

[Eric Brown (ericwb)]

I was able to resolve the issue by removing "external" from the authentication methods in keystone.conf.

methods = external,password,token,saml2
  to
methods = password,token,saml2

I "think" this occurs because my mapping uses REMOTE_USER and if external is configured, it creates an AuthContext using the external method and then later attempts to set the user_id using the saml auth method, resulting in a dup.

Note: this doc warns against external and federation: http://docs.openstack.org/developer/keystone/external-auth.html#configuration

[Lance Bragstad (lbragstad)]

Automatically unassigning due to inactivity.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Identity (keystone) because there has been no activity for 60 days.]