yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #83750
[Bug 1893794] [NEW] Keystone returns spurious federated users for LDAP-backed domain
Public bug reported:
I have the following setup:
- "ldap" domain is configured to point to LDAP instance via domain specific drivers
- I have also enabled federation via OpenIDConnect to my developer Okta.com account
$ openstack domain list
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
| ID | Name | Enabled | Description |
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
| 40e2fcb908e64f8b85bc0ff9230df16c | ldap | True | |
| 870037de4a514c12b6230e5dfd4c121f | 870037de4a514c12b6230e5dfd4c121f | True | Auto generated federated domain for Identity Provider: okta |
| default | Default | True | The default domain |
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
These are the users in each domain:
$ openstack user list --domain ldap
+------------------------------------------------------------------+-------+
| ID | Name |
+------------------------------------------------------------------+-------+
| 79b6059c726cb41444ae7a8b48a5014b0ebcc55d28cf2ada6dc6efc824fb66fb | admin |
| 4c18fa92b731f0151704bf08b426ddf1c1ce224a086b33b7459cfc6ef38f9bfa | dm |
| 54b404b1c0f3faec91045802f81e56c1c69bdb8b5fbc5011a95fa8e0f446c5fa | kb |
+------------------------------------------------------------------+-------+
$ openstack user list --domain 870037de4a514c12b6230e5dfd4c121f
+------------------------------------------------------------------+-----------------+
| ID | Name |
+------------------------------------------------------------------+-----------------+
| 0729a3d45a8f1489ad19d5b542ed5cc36f85974571253589c4f80d9997242fd9 | parrot@xxxxxxxx |
+------------------------------------------------------------------+-----------------+
The mapping for federation is the following:
$ openstack mapping show openidc_mapping -f value -c rules
[{'local': [{'user': {'name': '{0}'}, 'group': {'domain': {'name': 'Default'}, 'name': 'federated_users'}}], 'remote': [{'type': 'REMOTE_USER'}]}]
and the group has assignments on
$ openstack role assignment list --group federated_users --names
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
| member | | federated_users@Default | federated_project@Default | | | False |
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
no mention of "ldap" domain anywhere.
What I perceive as as an issue happens when I try to show a user from federated domain
while specifying the "ldap" domain:
$ openstack user show parrot@xxxxxxxx --domain ldap
+---------------------+------------------------------------------------------------------+
| Field | Value |
+---------------------+------------------------------------------------------------------+
| domain_id | 40e2fcb908e64f8b85bc0ff9230df16c |
| enabled | True |
| id | 9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246 |
| name | parrot@xxxxxxxx |
| options | {} |
| password_expires_at | None |
+---------------------+------------------------------------------------------------------+
This returns a user with spurious user ID that can not be found
afterwards:
$ openstack user show 9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246
No user with a name or ID of '9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246' exists.
It seems the reason is that code decides that as LDAP driver is domain unaware
and removes domain hints too early, while these hints are being used afterwards to query the
federation provider as well:
https://opendev.org/openstack/keystone/src/commit/0b9d98b37b88d1be3a5e419ecc8395eb459f5a93/keystone/identity/core.py#L1106-L1108
Instead I think this check and removal of domain hints should be done later,
immediately before the actual identity driver (which may be domain unaware) is called
in "_handle_shadow_and_local_users" method
https://opendev.org/openstack/keystone/src/commit/0b9d98b37b88d1be3a5e419ecc8395eb459f5a93/keystone/identity/core.py#L1091
** Affects: keystone
Importance: Undecided
Assignee: Pavlo Shchelokovskyy (pshchelo)
Status: In Progress
--
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/1893794
Title:
Keystone returns spurious federated users for LDAP-backed domain
Status in OpenStack Identity (keystone):
In Progress
Bug description:
I have the following setup:
- "ldap" domain is configured to point to LDAP instance via domain specific drivers
- I have also enabled federation via OpenIDConnect to my developer Okta.com account
$ openstack domain list
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
| ID | Name | Enabled | Description |
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
| 40e2fcb908e64f8b85bc0ff9230df16c | ldap | True | |
| 870037de4a514c12b6230e5dfd4c121f | 870037de4a514c12b6230e5dfd4c121f | True | Auto generated federated domain for Identity Provider: okta |
| default | Default | True | The default domain |
+----------------------------------+----------------------------------+---------+-------------------------------------------------------------+
These are the users in each domain:
$ openstack user list --domain ldap
+------------------------------------------------------------------+-------+
| ID | Name |
+------------------------------------------------------------------+-------+
| 79b6059c726cb41444ae7a8b48a5014b0ebcc55d28cf2ada6dc6efc824fb66fb | admin |
| 4c18fa92b731f0151704bf08b426ddf1c1ce224a086b33b7459cfc6ef38f9bfa | dm |
| 54b404b1c0f3faec91045802f81e56c1c69bdb8b5fbc5011a95fa8e0f446c5fa | kb |
+------------------------------------------------------------------+-------+
$ openstack user list --domain 870037de4a514c12b6230e5dfd4c121f
+------------------------------------------------------------------+-----------------+
| ID | Name |
+------------------------------------------------------------------+-----------------+
| 0729a3d45a8f1489ad19d5b542ed5cc36f85974571253589c4f80d9997242fd9 | parrot@xxxxxxxx |
+------------------------------------------------------------------+-----------------+
The mapping for federation is the following:
$ openstack mapping show openidc_mapping -f value -c rules
[{'local': [{'user': {'name': '{0}'}, 'group': {'domain': {'name': 'Default'}, 'name': 'federated_users'}}], 'remote': [{'type': 'REMOTE_USER'}]}]
and the group has assignments on
$ openstack role assignment list --group federated_users --names
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
| member | | federated_users@Default | federated_project@Default | | | False |
+--------+------+-------------------------+---------------------------+--------+--------+-----------+
no mention of "ldap" domain anywhere.
What I perceive as as an issue happens when I try to show a user from federated domain
while specifying the "ldap" domain:
$ openstack user show parrot@xxxxxxxx --domain ldap
+---------------------+------------------------------------------------------------------+
| Field | Value |
+---------------------+------------------------------------------------------------------+
| domain_id | 40e2fcb908e64f8b85bc0ff9230df16c |
| enabled | True |
| id | 9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246 |
| name | parrot@xxxxxxxx |
| options | {} |
| password_expires_at | None |
+---------------------+------------------------------------------------------------------+
This returns a user with spurious user ID that can not be found
afterwards:
$ openstack user show 9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246
No user with a name or ID of '9eaa86cad8bb421335f42a8011e28f539903cbd3586656507b9223adc5935246' exists.
It seems the reason is that code decides that as LDAP driver is domain unaware
and removes domain hints too early, while these hints are being used afterwards to query the
federation provider as well:
https://opendev.org/openstack/keystone/src/commit/0b9d98b37b88d1be3a5e419ecc8395eb459f5a93/keystone/identity/core.py#L1106-L1108
Instead I think this check and removal of domain hints should be done later,
immediately before the actual identity driver (which may be domain unaware) is called
in "_handle_shadow_and_local_users" method
https://opendev.org/openstack/keystone/src/commit/0b9d98b37b88d1be3a5e419ecc8395eb459f5a93/keystone/identity/core.py#L1091
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1893794/+subscriptions
