Trust API does not support delegating federated roles (roles obtained from federated groups)

[Dmitrii Shcherbakov]

Version: Queens (UCA) 2:13.0.2-0ubuntu1

When a trust is created a trustor user is required to have a role on a project in question. This is verified via a call to the keystone database without looking at roles that can be inferred from federated groups present in a token.

In this scenario a federated user does not have any direct role assignments in the Keystone database - only the ones that can be inferred from federated group membership.

https://opendev.org/openstack/keystone/src/branch/stable/queens/keystone/trust/controllers.py#L141
https://opendev.org/openstack/keystone/src/branch/stable/queens/keystone/trust/controllers.py#L172-L178

A call to /v3/auth/tokens which verifies that "roles" for groups present in "OS-FEDERATION" section are properly populated:
http://paste.openstack.org/show/753298/
    "roles": [
      {
        "id": "e4ab04a7c6ec4c91a826b2a3ba333407",
        "domain_id": null,
        "name": "Member"
      }
# ...
    "user": {
      "OS-FEDERATION": {
        "identity_provider": {
          "id": "adfs"
        },
        "protocol": {
          "id": "mapped"
        },
        "groups": [
          {
            "id": "7594d86688c54ee2aab4c9df020f5468"
          }
        ]
      },

This bug is similar to this one for application credentials: https://bugs.launchpad.net/keystone/+bug/1832092

Users, Member role and role assignments:
http://paste.openstack.org/show/753300/

The issue was discovered while troubleshooting "Error: ERROR: Missing required credential: roles [u'Member']" showed by heat dashboard during a stack creation:

http://paste.openstack.org/show/753301/ (heat API rpdb trace where a Keystone trust API call is made)

Keystone side:
http://paste.openstack.org/show/753302/ (keystone trust API rpdb trace)

[Colleen Murphy (krinkle)]

I think this is a duplicate of https://bugs.launchpad.net/keystone/+bug/1589993 . Do you see "Could not find role: XXX" in the keystone logs?

[Dmitrii Shcherbakov (dmitriis)]

Yes, in the trace it goes as:

-> raise exception.RoleNotFound(role_id=trust_role['id'])

which maps to

class RoleNotFound(NotFound):
    message_format = _("Could not find role: %(role_id)s.")

So you are right - this looks like a duplicate.

I can see that the current proposal is to introduce expiring group memberships which will be temporary persisted in the DB.

https://review.opendev.org/#/c/604201/9/specs/keystone/train/expiring-group-memberships.rst@42