To enable trusts for federated environment, users need to manually set the following parameter in /etc/keystone/keystone.conf:
[federation]/cache_group_membership_in_db=True
When turned on, Keystone will save in DB group membership for federated users. Enabling this option is the only way so far to make trusts delegated by federated users work.
The downside is that a trust could be used even after the delegating user's permissions were changed in IdP. For example, consider the following scenario:
1. User A has role admin in tenant T.
2. User A generates trust for user B, granting him that role.
3. Cloud admin removes the role from user A in Identity Provider (IdP).
4. But Keystone has cached the role assignment and still thinks that A owns admin role in tenant T.
5. As a result, user B still can use the trust and act as an admin in T.
That situation will be resolved only once user A logs into Keystone (that is the only moment when Keystone gets update about user from IdP).
The issue could be mitigated by an automation script which propagates changes in group assignments in IdP to the Keystone.
To enable trusts for federated environment, users need to manually set the following parameter in /etc/keystone/ keystone. conf: /cache_ group_membershi p_in_db= True
[federation]
When turned on, Keystone will save in DB group membership for federated users. Enabling this option is the only way so far to make trusts delegated by federated users work.
The downside is that a trust could be used even after the delegating user's permissions were changed in IdP. For example, consider the following scenario:
1. User A has role admin in tenant T.
2. User A generates trust for user B, granting him that role.
3. Cloud admin removes the role from user A in Identity Provider (IdP).
4. But Keystone has cached the role assignment and still thinks that A owns admin role in tenant T.
5. As a result, user B still can use the trust and act as an admin in T.
That situation will be resolved only once user A logs into Keystone (that is the only moment when Keystone gets update about user from IdP).
The issue could be mitigated by an automation script which propagates changes in group assignments in IdP to the Keystone.