Open Stack

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 <
natsume.takashi at lab.ntt.co.jp> 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: natsume.takashi at lab.ntt.co.jp
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/64b39df6/attachment.html>