A Keystone user can't perform revoke_token operation due to absence of target in context

Should these calls require any authentication at all (with a default policy configuration)? If the caller is in possession of a token, why should they not be able to validate or revoke it? Revoking your own token is analogous to "logging out."

I definitely *don't* think that these calls should receive special treatment in terms of how X-Auth-Token vs X-Subject-Token is handled. In other words, the X-Subject-Token should not be treated as an X-Auth-Token, and if policy.json requires authorization, that should apply to the X-Auth-Token.

I'm not sure if this is a security vulnerability though, because the token can still be revoked on the v2 API.

It's not a vulnerability, unless you can somehow think that your token was revoked when it was not.

OK, Let’s not treat it as vulnerability.

As per the V3 API we have to pass "X-Auth-Token" to authenticate the caller for all the below mentioned APIs and "X-Subject-Token" is the token on which caller is operating on.

identity:check_token
identity:validate_token
identity:revoke_token

The default policy comes with below rule, which mean either admin or user is authorized for revoke token. Now to do the authz check we need a target which should the user_id associated with X-Subject-Token. In the current implementation the traget is coming empty (at check(rule, target, creds, exc=None, *args, **kwargs) call). Due to that ["user_id:%(user_id)s"] rule will never satisfied.

 "identity:revoke_token": [["rule:admin_required"], ["user_id:%(user_id)s"]],

What I am proposing is to derive user_id (or target) from X-Subject-Token so that at check(rule, target, creds, exc=None, *args, **kwargs) method can evaluate policy on a target.

Opening bug so that it gets a wider audience

I'd suggest revising the default policy.json to not require an X-Auth-Token for these calls.

I think we should not make these APIs open for all, because that way we will lose all audit ability of who revoked the token as In a well behaved system, the admin would have a priv to revoke tokens of their users. We need it at least for public cloud scenarios and policy engine supports it.

I know holder of token (user/impersonator) can revoke a token then why authorization, but what I want to achieve here in this bug is, someone (a good team member) should not accidentally revoke my token we can control impersonator use case if someone has access to my token.

thoughts???

That sounds like a perfectly valid reason for requiring that those calls require authorization, however it's a corner case that doesn't necessarily support requiring authorization out of the box. policy.json is intended to be customized, after all.

Also, if someone has access to your token and is using it, they are not impersonating you, they are simply stealing your identity without traceability.

So is it a bug or not? if yes I will start fixing the same.

Sorry I am new to the process.

I think the bug is that we require authorization on these calls in our default policy.json configuration.

Since the tokens are bearer tokens, then we have the vulnerability that anyone who steals your token can impersonate you to do anything you can do, including revoking your token (which effectively performs a DOS attack on you). You can only remove this vulnerability when the tokens are no longer bearer tokens, e.g. once they are PKI tokens, you can prove they belong to you by signing the request with your private key. But until that time there is little point in wanting authorisation of bearer tokens, since the tokens themselves are their own authorisation (just like a dollar bill is its own authz for buying something).

If you want someone else, such as admin, to be able to revoke your bearer token, and you want an audit of this, then it makes sense to authenticate the caller. I would say that you do this by putting the token of the requestor as the auth token, and the token to be revoked as the subject token. If you want to revoke your own token, you could put the same token in both places, or leave the auth token empty (and it defaults to the subject token)

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

Reviewed: https://review.openstack.org/46123
Committed: http://github.com/openstack/keystone/commit/f1f0bbc4b42adeeced224778271f1297b9632b96
Submitter: Jenkins
Branch: master

commit f1f0bbc4b42adeeced224778271f1297b9632b96
Author: Arvind Tiwari <email address hidden>
Date: Wed Sep 11 12:28:14 2013 -0600

    Validate token calls return 404 on invalid tokens

    Invalid X-Subject-Token was resulting in HTTP 401 rather than 404
    This is causing the auth_token middleware to re-authenticate
    It expects a 404 on an invalid token.

    Change-Id: Ieb4cbd4f69b4f3c5944eebc262e694e831d1ca6d
    Fixed-Bug: #1221889
    Fixed-Bug: #1186059