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
