Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1480067

Summary: Federated users not able to create heat stack
Product: Red Hat OpenStack Reporter: Md Nadeem <mnadeem>
Component: openstack-heatAssignee: Zane Bitter <zbitter>
Status: CLOSED DUPLICATE QA Contact: Ronnie Rasouli <rrasouli>
Severity: high Docs Contact:
Priority: high    
Version: 10.0 (Newton)CC: aarapov, asimonel, dhill, mburns, panburaj, ramishra, rhel-osp-director-maint, sbaker, shardy, sputhenp, srevivo, therve
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-09-21 14:30:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Md Nadeem 2017-08-10 05:09:30 UTC
Description of problem:

Stack creation gets failed with error message: "Missing required credential: roles [u'_member_', u'admin']"

Every time a federated user tries to create a stack.

1. The role are assigned to the group, and the users are the part of the group.
2. Heat tries to treat Federated user as regular Keystone user which usually has ID, assigned project(s) and assigned role(s). However, federated users don't belong to Keystone database. They get mapped to user groups and inherit group roles and projects in runtime, during the authentication process. When someone, for example, Heat, tries to query Keystone about federated user, this will lead to Identity Error and, as a consequence, make Heat fail.

Workaround
-----------
We need to manually assign the role for federated users, so that the assignment is stored in keystone database.
1. Get the user id for the federated user.
~~~
$openstack user show c7612
+----------+----------------------------------+
| Field    | Value                            |
+----------+----------------------------------+
| ..       | ..                               |
| id       | f321a124ad524dedb0c2492fce5f38ee |
| name     | c7612                            |
| ..       | ..                               |
+----------+----------------------------------+
~~~

2. Use the 'user id'  and 'project name' to manually assign role for that user.
~~~
$openstack role add --user f321a124ad524dedb0c2492fce5f38ee --project project-name _member_
$openstack role add --user f321a124ad524dedb0c2492fce5f38ee --project project-name heat_stack_owner
~~~

3. Check if the role has been properly assigned.
~~~
$openstack role assignment list --user f321a124ad524dedb0c2492fce5f38ee --project project-name
~~~

4. Now you can create the stack, it will work.

This should be done only once, so that authorization details are stored in keystone database.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. 
2. 
3.

Actual results:


Expected results:


Additional info:

Upstream related Bug: https://bugs.launchpad.net/keystone/+bug/1600366

Comment 1 Rabi Mishra 2017-08-10 10:30:52 UTC
I think this is a known issue as heat (using keystone trusts) and federated keystone does not work as discussed here[1][2].

If the user and role assignments are local to keystone as it's done with 'workaround' above, it would work.

There were some discussions on leveraging the 'shadow user' with federated keystone to help fix this issue, where there can be an option to fetch roles from the IDP when the user logs first time.

I don't think this has been implemented in keystone yet due to the number of issues associated with the approach.

[1] https://bugs.launchpad.net/fuel/+bug/1626046
[2] https://bugs.launchpad.net/keystone/+bug/1589993

Comment 4 Rabi Mishra 2017-08-24 07:19:22 UTC
Keystone trusts is the only way heat can do deferred_auth on behalf of a user now. We don't have any other alternative for that atm.

AFAIK, Keystone federation was implemented after trusts and it's unfortunate that trusts don't work with it.

We understand the issues and complexity associated with the workaround above. But, IMHO, unless keystone can fix this issue, heat can do very little.

Comment 13 Thomas Hervé 2017-09-21 14:30:57 UTC

*** This bug has been marked as a duplicate of bug 1487459 ***