possible to grant role to user on domain/project when this domain/user was disabled

Bug #1401040 reported by Wei Xiaoli
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Won't Fix
Medium
Unassigned

Bug Description

when domain/user was disabled, we still can grant role to user on domain/project, but doc shows these operations should not be allowed.

see doc: http://docs.openstack.org/api/openstack-identity-service/3/content/domains-v3domains.html
{
...
Setting this attribute to false prevents users from authorizing against this domain or any projects owned by this domain, and prevents users owned by this domain from authenticating or receiving any other authorization. Additionally, all pre-existing tokens applicable to the above entities are immediately invalidated. Re-enabling a domain does not re-enable pre-existing tokens.
}

(morganfainberg): It is likely the documentation should be updated as well to make the expected behavior a bit more clear.

Revision history for this message
Rodrigo Duarte (rodrigodsousa) wrote :

I think the docs are correct since it states that the user is not allowed to get a token, but, I'm not sure if granting a role should be authorized or not (which is not what the docs are saying).

Revision history for this message
Wei Xiaoli (xiao-li-wei) wrote :

Hi Rodrigo,

Thank you for your comments. :)

Could you let me know if we can grant role to user on domain/project when the domain/user was disabled, if yes, and we can leave this bug as it and need to correct the doc[prevent users from receiving any other authorization], if not, we need to fix this bug in code to forbidden role assignment operation on this user. am I right?

Thanks,
Lily

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

I think the documents are correct, the behavior is incorrect. We should fix the behavior.

summary: - documents show we can't grant role to user on domain/project when this
- domain/user was disabled, but we actually do these operation, please
- correct the content of documents.
+ possible to grant role to user on domain/project when this domain/user
+ was disabled
tags: added: icehouse-backport-potential juno-backport-potential
Changed in keystone:
importance: Undecided → Medium
description: updated
Revision history for this message
Wei Xiaoli (xiao-li-wei) wrote :

Thanks, Morgan!

wanghong (w-wanghong)
Changed in keystone:
assignee: nobody → wanghong (w-wanghong)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/141746

Changed in keystone:
status: New → In Progress
Revision history for this message
Brant Knudson (blk-u) wrote :

I don't see why this is an issue... who is it hurting to be able to create a role assignment on a disabled project or domain?

Revision history for this message
wanghong (w-wanghong) wrote :

In my opinion, disable it means you can't do anything on it except enable it again.

Revision history for this message
wanghong (w-wanghong) wrote :

But, in current keystone, disabled a user/project/domain just means you can't get token any more. So, I don't sure if this is an issue.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on keystone (master)

Change abandoned by wanghong (reviewwanghong@126.com) on branch: master
Review: https://review.openstack.org/141746

wanghong (w-wanghong)
Changed in keystone:
assignee: wanghong (w-wanghong) → nobody
tags: removed: icehouse-backport-potential
Alan Pevec (apevec)
tags: removed: juno-backport-potential
Revision history for this message
Steve Martinelli (stevemar) wrote :

Adding a role to a disabled user/group should be fine. Authentication will still fail for the user if she is disabled or the project is disabled.

Changed in keystone:
status: In Progress → Won't Fix
Revision history for this message
Henry Nash (henry-nash) wrote :

In fact being able to "prepare the assignments" for the domain before enabling it, might well be common practice, and hence the current functionality is desirable.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.