Comment 4 for bug 1626046
Revision history for this message
| Nikolay Pliashechnikov (npliashechnikov) wrote | #4 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Hello everyone,
I have recently investigated deeper into this issue.
Shortly, there is a way to use Heat and its dependant services on MOS version 9, though it requires significant changes in the Keystone and, probably, authorization model.
The core reason behind this issue is that Heat tries to use Keystone V3 Trusts API in order to be able to perform deferred actions on behalf of the user who created stack, such as scale up/scale down. There is no way to fix this in Heat, as all logic relies on this functionality (and works perfectly with SQL and LDAP users), so the fixes should be made on Keystone's side.
When Keystone issues scoped token for a federated user, it uses User ID supplied by Identity Provider. Keystone also stores shadow copy of federated user in its DB on a first login. However, in this case, it DOES NOT use the ID supplied by IdP - instead of this, it generates its own uuid4() ID!
So, when Heat goes to Keystone and asks to create a trust for the user_id (IdP-supplied) specified in the token, Keystone can't find anything similar in its DB as IDs do not match. And, if you can make Keystone use User IDs provided by IdP to create shadow users, half of the problems are solved.
Another issue is with the group-based access model that is currently used with federated authentication. After some testing I have found that user with group-derived roles is not able to grant trusts, as Keystone does not take it into account when validating if the user is eligible to create trust with given permissions.
There is currently no fix for that behaviour that I am aware of, but, since Newton release, individual role assignment are supported for federated users. This was made possible by this change:
https:/
I believe it can be backported to Keystone Mitaka. This, however, would probably require some changes in the users' mapping rules.
I was able to use Heat on MOS 9.0 after explicitly assigning admin role to a federated user. Before that I made sure that ID of the user in Keystone DB is the same as supplied by IdP.
I'm adding patch that forces Keystone to take IdP-supplied user ID to its DB.