OS-INHERIT does not seem to work for users but works for groups

[Christophe Balczunas]

Using Kilo, I'm following thehttp://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-inherit-ext.html#what-s-new-in-version-1-1 instructions to experiment with role inheritances on projects of a domain. (not dealing with subprojects just yet).

I'm having some problem getting OS-INHERIT to work when the target of the assignment is a user. It works if the target is a group.

I'm able to PUT a project role inheritance record but not get it back:

PUT: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects

(side note: I noticed though that it validates domain, roles, but not user. The PUT succeeds if I put an invalid user.)

HEAD on the same path above returns 404.

Also, this:
GET: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/inherited_to_projects

returns 200, but an empty list of roles.

So somehow, the PUT doesn't stick, I'm not sure why. Consequently, I'm also not able to get a project token with expected roles from the domain etc.

Interestingly, this works with groups. In other words, if I do a:
PUT: /v3/OS-INHERIT/
domains/d
groups/g/
roles/x

then, a user from that group g can get a project scoped token with role x in any project of domain d.

It doesn't seem to be working when using the inherited grant on users directly?

[Henry Nash (henry-nash)]

Thanks for the detailed problem description. With regard to checking for existence of the user, this was by design (in preparation for potentially federated users coming in...although we may now be able to re-add that check since we handle federation a little differently than planned).

I'll investigate the other problem asap.

[Christophe Balczunas (pentatonic)]

I was wondering when it gets decided if a bugfix gets backported to Kilo?

Also, have we identified that it is indeed a bug? Thank you.

[Henry Nash (henry-nash)]

Hi

Sorry for the delay. Could you check to see if there is a non-inherited role off the same type, i.e. if

HEAD: /v3/OS-INHERIT/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects

fails, then see if:

HEAD: /v3/
domains/288b1c4d3f7b43a4b8708016d9ae3ec5/
users/257cc461fde84f8aac1af1b42a7314f2/
roles/daa86839ba154426ad34a95975d2d188

works?

There used to be a bug that we couldn't store both an inherited and non-inherited assignment on the same target...

works?

[Christophe Balczunas (pentatonic)]

Interesting. Yes if there is a domain role assignment for the user, then the inherited role doesn't work. If I remove the domain role first, then do the inherited role assignment only, it works.

[Rudolf Vriend (rudolf-vriend-deactivatedaccount)]

Just ran into the same issue.

I believe the problem has several causes:

- a unique composite primary key DB index on the assignment table that does not include the 'inherited' column and hence will prevent the definition of 'regular' and 'inherited' role assignments for the same set of assignment-type, actor_id, target_id and role_id (which should be supported IMHO).

- sql.DBDuplicateEntry exceptions are ignored during role assignment creation in create_grant and hence the api returns ok even if the call failed due to the unique index rejecting a 'duplicate' since it ignores the 'inherited' column.

[Henry Nash (henry-nash)]

OK, agreed, this is a known issue - and is fixed in Liberty (see: https://bugs.launchpad.net/keystone/+bug/1403539)

[Henry Nash (henry-nash)]

I'm closing this defect, since it is essentially a duplicate of https://bugs.launchpad.net/keystone/+bug/1403539. Please re-open if you think there is a distinct defect here.