keystoneauth1 v3 Token object ignores the token passed in

[prashkre]

The primary problem reported in the defect is that when a keystoneauth1 identity Token is set in the session and a REST call is made, the session does not use the same token for making the call.

auth = identity.v3.Token(auth_url, token)
s = session.Session(auth=auth, verify=False)
resp = s.get('http://localhost:9292/v2/images', headers={'Accept': 'application/json'}

Even though the token has been explicitly as part of the v3.Token object , the token that is set is not user to make the REST call. Instead a new unscoped token is generated. This new unscoped token which is generated doesn't have roles, project and catalog information as seen below

{"token": {"issued_at": "2017-05-11T12:07:13.000000Z", "audit_ids": ["_0-Hir4UTS-ATQmbiOP0Wg", "Zh4SNR-jREugwuoxGXL4wg"], "user": {"id": "0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9", "domain": {"id": "default", "name": "Default"}, "password_expires_at": null, "name": "root"}, "expires_at": "2017-05-11T18:05:50.000000Z", "methods": ["token", "password"]}}

The flow here is :

1. Using the keystoneauth1 session object a post call is made with the auth v3.Token object set.
2. When we make a session call, control comes here
>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/session.py#L491
>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/session.py#L818
>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/plugin.py#L90

The keystoneauth1.identity.v3.Token object does not have an implementation for get_token so the control finally falls back on the keystoneauth1 identity base implementation which is probably not even applicable for keystone v3.

>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/identity/base.py#L90
>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/identity/base.py#L135
>> https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/identity/base.py#L92

The above check for re-authenticate always returns True as it does not consider the token that has been passed into the v3.Token object and in all cases goes on to create a new token, which is subsequently used to make the REST call, which happens here>>
https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/identity/v3/base.py#L112
https://github.com/openstack/keystoneauth/blob/stable/ocata/keystoneauth1/identity/v3/base.py#L166

3. To resolve the above problem I overrided the get_token method inside v3.Token to return the token that was passed in instead of a re-authentication and everything worked fine..Of course this is more of a hack to check if this helped fix this problem. The below doesn't have logic to check if the token was going to expire and if re-authentication was required etc.

class Token(base.AuthConstructor):
    _auth_method_class = TokenMethod
    token_new = None

    def __init__(self, auth_url, token, **kwargs):
        super(Token, self).__init__(auth_url, token=token, **kwargs)
        self.token_new = token

    def get_token(self, session, **kwargs):
        return self.token_new

[Matthew Edmonds (edmondsw)]

v3.Token will never be able to support re-authentication (you can use one token to get another, but the expiration date of the next token cannot exceed that of the original token, to prevent a malicious user that is able to get a token from being able to extend their access indefinitely). So simply returning the existing token from get_token without worrying about checking expiration and re-authentication should be a sufficient fix here.

[OpenStack Infra (hudson-openstack)]

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

[Lance Bragstad (lbragstad)]

The report here seems specific to keystoneauth. Is there an issue with keystone server?

[Divya K Konoor (dikonoor)]

No..There's no problem with keystone. Keystone can be removed

[Matthew Edmonds (edmondsw)]

I dug into the keystoneauth code today, and I don't think this is actually a defect after all. The Token auth plugin appears to be designed, like the other auth plugins, to get you a token with the scope that you ask for. This makes sense when you consider that it's possible to use a token with one scope to request a new token with a different scope. So if you don't specify a project_id (or other scope) when constructing keystoneauth1.identity.v3.Token, it's not surprising that you get an unscoped auth.

[Lance Bragstad (lbragstad)]

Thanks for the clarification, Matthew.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Divya K Konoor (<email address hidden>) on branch: master
Review: https://review.openstack.org/464934