Dolph, Thank you so much. I understand that using OS-REVOKE Extension will solve these issues.
Regards, Takashi Natsume NTT Software Innovation Center Tel: +81-422-59-4399 E-mail: [email protected] From: Dolph Mathews [mailto:[email protected]] Sent: Thursday, June 26, 2014 12:11 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Keystone] Token invalidation in deleting role assignments This is a known limitation of the token backend and the token revocation list: we don't index tokens in the backend by roles (and we don't want to iterate the token table to find matching tokens). However, if we land support for token revocation events [1] in the auth_token [2] middleware, we'll be able to deny tokens with invalid roles as they are presented to other services. [1] https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-revoke-ext.md [2] https://launchpad.net/keystonemiddleware On Wed, Jun 25, 2014 at 1:19 AM, Takashi Natsume <[email protected]> wrote: Hi all, When deleting role assignments, not only tokens that are related with deleted role assignments but also other tokens that the(same) user has are invalidated in stable/icehouse(2014.1.1). For example, A) Role assignment between domain and user by OS-INHERIT(*1) 1. Assign a role(For example,'Member') between 'Domain1' and 'user' by OS-INHERIT 2. Assign the role('Member') between 'Domain2' and 'user' by OS-INHERIT 3. Get a token with specifying 'user' and 'Project1'(in 'Domain1') 4. Get a token with specifying 'user' and 'Project2'(in 'Domain2') 5. Create reources(For example, cinder volumes) in 'Project1' with the token that was gotten in "3." it is possible to create them. 6. Create reources in 'Project2' with the token that was gotten in "4." it is possible to create them. 7. Delete the role assignment between 'Domain1' and 'user' (that was added in "1.") (After validated token cache is expired in cinder, etc.) 8. Create reources in 'Project1' with the token that was gotten in "3." it is not possible to create them. "401 Unauthorized." 9. Create reources in 'Project2' with the token that was gotten in "4." it is not possible to create them. "401 Unauthorized." In "9.", my expectation is that it is possible to create resources with the token that was gotten in "4.". *1: v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_ to_projects B) Role assignment between project and user 1. Assign a role(For example,'Member') between 'Project1' and 'user' 2. Assign the role('Member') between 'Project2' and 'user' 3. Get a token with specifying 'user' and 'Project1' 4. Get a token with specifying 'user' and 'Project2' 5. Create reources(For example, cinder volumes) in 'Project1' with the token that was gotten in "3." it is possible to create them. 6. Create reources in 'Project2' with the token that was gotten in "4." it is possible to create them. 7. Delete the role assignment between 'Project1' and 'user' (that was added in "1.") (After validated token cache is expired in cinder, etc.) 8. Create reources in 'Project1' with the token that was gotten in "3." it is not possible to create them. "401 Unauthorized." 9. Create reources in 'Project2' with the token that was gotten in "4." it is not possible to create them. "401 Unauthorized." In "9.", my expectation is that it is possible to create resources with the token that was gotten in "4.". Are these bugs? Or are there any reasons to implement these ways? Regards, Takashi Natsume NTT Software Innovation Center Tel: +81-422-59-4399 E-mail: [email protected] _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
