[rocky+] Creation of application credentials fails when role assignments only come from role assignments of federated groups

[Dmitrii Shcherbakov]

[Version]
Rocky (UCA)

[Problem Description]

(see the User Scenario section below for a description of the environment)

When no direct role assignments to federated users are done and only federated group role assignments are present, application credential creation via Horizon fails with the following errors:

horizon apache2 error.log:

[Sat Jun 08 14:27:59.153479 2019] [wsgi:error] [pid 150327:tid 139962773473024] [remote 10.232.46.207:35898] Recoverable error: Invalid application credential: Could not find role assignment with role: 91afa82fab85426fa741370dabad80bf, user or group: 794d430997c64060854bf77f2e7e6e16, project, domain, or system: 7de76f768cb84149b8b2d693d1d21f45. (HTTP 400) (Request-ID: req-da2e3322-2f6f-468f-bd0d-b08855f9893b)

keystone.log:

(keystone.common.wsgi): 2019-06-08 14:30:55,933 WARNING Invalid application credential: Could not find role assignment with role: 91afa82fab85426fa741370dabad80bf, us
er or group: 794d430997c64060854bf77f2e7e6e16, project, domain, or system: 7de76f768cb84149b8b2d693d1d21f45.
(keystone.middleware.auth): 2019-06-08 14:31:00,940 DEBUG Authenticating user token

Code-path:

create_application_credential -> _require_user_has_role_in_project -> _get_user_roles -> _get_user_roles -> list_role_assignments -> _list_effective_role_assignments -> _get_group_ids_for_user_id -> list_groups_for_user -> _get_group_ids_for_user_id

A detailed rpdb trace:
http://paste.openstack.org/show/752652/

 82 def _require_user_has_role_in_project(self, roles, user_id, project_id):
 83 user_roles = self._get_user_roles(user_id, project_id)
 84 -> for role in roles:
 85 if role['id'] not in user_roles:
 86 raise exception.RoleAssignmentNotFound(role_id=role['id'],
 87 actor_id=user_id,
 88 target_id=project_id)

[Possible Solution]

Group membership details obtained dynamically during federated authentication and embedded into a fernet token (first an unscoped token, then a project-scoped token) need to be used in addition to querying the database for user to group membership.

[User Scenario]

Federated authentication via SAML with the following mapping (i.e. no direct role assignment to a user on a project - only federated group-based role assignment):

openstack mapping show adfs_mapping
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | adfs_mapping |
| rules | [{'remote': [{'type': 'MELLON_NAME_ID'}, {'type': 'MELLON_groups'}], 'local': [{'domain': {'id': 'e834e57943714e058c203d4f544ea946'}, 'user': {'name': '{0}'}, 'groups': '{1}'}]}] |
+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

# a federated user
openstack user list --domain adfs
+----------------------------------+------------------------+
| ID | Name |
+----------------------------------+------------------------+
| 794d430997c64060854bf77f2e7e6e16 | intranet\Administrator |
+----------------------------------+------------------------+

# a group that that exists both on the IdP and Keystone (SP) side
openstack group list --domain adfs
+----------------------------------+------------+
| ID | Name |
+----------------------------------+------------+
| 701f70e7549d4de28cecd60127a1a444 | adfs_users |
+----------------------------------+------------+

# no group assignments are present in the keystone db - they are only populated on a per-token basis during federated authentication
 openstack user list --domain adfs --group adfs_users ; echo $?

0

# grouptest is a project that adfs_users group members get a Member role assignment on
openstack project list --domain adfs
+----------------------------------+-----------+
| ID | Name |
+----------------------------------+-----------+
| 7de76f768cb84149b8b2d693d1d21f45 | grouptest |
| 6a0657cf98684a62af99dc7b71a383dd | test |
+----------------------------------+-----------+

# no direct Member role assignments for federated users
openstack role assignment list --names
+--------+----------------------------------+-----------------+-------------------------+--------------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+----------------------------------+-----------------+-------------------------+--------------+--------+-----------+
| Admin | neutron@service_domain | | services@service_domain | | | False |
| Admin | designate@default | | services@default | | | False |
| Admin | image-stream@default | | services@default | | | False |
| Admin | nova_placement@service_domain | | services@service_domain | | | False |
| Member | admin@admin_domain | | admin@admin_domain | | | False |
| Admin | admin@admin_domain | | admin@admin_domain | | | False |
| Admin | admin@admin_domain | | | admin_domain | | False |
| Member | swift@service_domain | | services@service_domain | | | False |
| Admin | swift@service_domain | | services@service_domain | | | False |
| Admin | cinderv2_cinderv3@default | | services@default | | | False |
| Member | | adfs_users@adfs | grouptest@adfs | | | False |
| Member | | adfs_users@adfs | | adfs | | False |
| Admin | neutron@default | | services@default | | | False |
| Admin | glance@default | | services@default | | | False |
| Admin | image-stream@service_domain | | services@service_domain | | | False |
| Admin | cinderv2_cinderv3@service_domain | | services@service_domain | | | False |
| Admin | glance@service_domain | | services@service_domain | | | False |
| Admin | designate@service_domain | | services@service_domain | | | False |
| Member | swift@default | | services@default | | | False |
| Admin | swift@default | | services@default | | | False |
| Admin | nova_placement@default | | services@default | | | False |
+--------+----------------------------------+-----------------+-------------------------+--------------+--------+-----------+

# same as above - no direct role assignments
openstack role assignment list --names --user 794d430997c64060854bf77f2e7e6e16 ; echo $?

0

# role assignments for the adfs_users group (domain and project level although only the project-level one is needed)
openstack role assignment list --names --group adfs_users --group-domain adfs
+--------+------+-----------------+----------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------+-----------------+----------------+--------+--------+-----------+
| Member | | adfs_users@adfs | grouptest@adfs | | | False |
| Member | | adfs_users@adfs | | adfs | | False |
+--------+------+-----------------+----------------+--------+--------+-----------+

===================

Just to make sure, adding group membership for the federated/shadow-mapped user to the db directly allows an application credential to be created successfully. So the issue is not applicable to group membership in general - just to the federated case where there is no record of membership in the db.

openstack group add user --group-domain adfs --user-domain adfs adfs_users 'intranet\Administrator'

openstack user list --domain adfs --group adfs_users
+----------------------------------+------------------------+
| ID | Name |
+----------------------------------+------------------------+
| 794d430997c64060854bf77f2e7e6e16 | intranet\Administrator |
+----------------------------------+------------------------+

# *creation of an app credential succeeds via horizon*

[Colleen Murphy (krinkle)]

Interesting that the application credential can't be created at all. Unfortunately even if you could create it, you couldn't use it because of this bug: https://bugs.launchpad.net/keystone/+bug/1773967

[Colleen Murphy (krinkle)]

This should be fixed when https://bugs.launchpad.net/keystone/+bug/1809116 is addressed, so marking as a duplicate.

[JF Taltavull (jftalta)]

It should be but it does not.

The fix related to https://bugs.launchpad.net/keystone/+bug/1809116 does not fix the present bug.

[Hemanth Nakkina (hemanth-n)]

@krinkle Can we remove duplicate link as the bug is still reproducible with bug #1809116 fix.

[Hemanth Nakkina (hemanth-n)]

Sorry for the noise.

I have gone through the specs and the code mentioned in bug #1809116 and understand it better now.

Setting default_authorization_ttl [1] to a non zero value resolved the issue.

[1] https://docs.openstack.org/keystone/latest/configuration/config-options.html#federation.default_authorization_ttl

[Graeme Moss (graememoss)]

For users that use charms this option is missing in the charm to configure this option and will need to be added.

I also have this problem tested and confirmed that added that option fixes the problem.

the following will need to be changed.
"section-federation" in the parts templates will need to have default_authorization_ttl added

[Hemanth Nakkina (hemanth-n)]

Raised a bug on charm - https://bugs.launchpad.net/charm-keystone/+bug/1970388