Invalid fernet X-Subject-Token token should result in 404 instead of 401

Bug #1541621 reported by Guang Yee on 2016-02-03
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Lance Bragstad
Liberty
Medium
Guang Yee

Bug Description

When a scoped fernet token is no longer valid (i.e. all the roles had been removed from the scope), token validation should result in 404 instead of 401. According to Keystone V3 API spec, 401 is returned only if X-Auth-Token is invalid [0]. Invalid X-Subject-Token should yield 404. Furthermore, auth_token middleware only treat 404 as invalid subject token and cache it accordingly [1]. Improper 401 will cause unnecessary churn as middleware will repeatedly attempt to re-authenticate the service user.

To reproduce the problem:

1. get a project scoped token
2. remove all the roles assigned to the user for that project
3. attempt to validate that project-scoped token will result in 401

[0] https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#401-unauthorized
[1] https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_identity.py#L215

Steve Martinelli (stevemar) wrote :

is this specific to fernet?

Guang Yee (guang-yee) wrote :

Yes, it is specific to fernet. UUID token got deleted when all the roles are removed from the given scope. I verified it with latest devstack yesterday.

Changed in keystone:
milestone: none → mitaka-3
tags: added: fernet
Lance Bragstad (lbragstad) wrote :

The fernet provider leverages the get_token_data() method in keystone/token/providers/common.py. We could add a check when we populate the scope there - https://github.com/openstack/keystone/blob/931d589586a99f057ce17b9f3f0f6ec954031d7d/keystone/token/providers/common.py#L379

summary: - Invalid subject fernet token should result in 404 instead of 401
+ Invalid fernet X-Subject-Token token should result in 404 instead of 401
Changed in keystone:
importance: Undecided → Medium
Lance Bragstad (lbragstad) wrote :
Changed in keystone:
status: New → Confirmed
description: updated
Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Confirmed → In Progress
Changed in keystone:
assignee: Lance Bragstad (lbragstad) → Steve Martinelli (stevemar)
Changed in keystone:
assignee: Steve Martinelli (stevemar) → Lance Bragstad (lbragstad)

Changing an error response code is allowed according to our API changes guidelines [1]:

"The following types of changes are generally considered acceptable:
    [...]
    Changing an error response code to be more accurate."

[1] http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html

Changed in keystone:
assignee: Lance Bragstad (lbragstad) → Raildo Mascena de Sousa Filho (raildo)
Changed in keystone:
assignee: Raildo Mascena de Sousa Filho (raildo) → Guang Yee (guang-yee)
Changed in keystone:
assignee: Guang Yee (guang-yee) → Lance Bragstad (lbragstad)
Changed in keystone:
assignee: Lance Bragstad (lbragstad) → Guang Yee (guang-yee)
Changed in keystone:
assignee: Guang Yee (guang-yee) → Steve Martinelli (stevemar)
Changed in keystone:
assignee: Steve Martinelli (stevemar) → Guang Yee (guang-yee)
Changed in keystone:
milestone: mitaka-3 → mitaka-rc1
Changed in keystone:
assignee: Guang Yee (guang-yee) → Lance Bragstad (lbragstad)

Reviewed: https://review.openstack.org/277436
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=f1792f4089ccf28ec870104d0853e7fba242f24c
Submitter: Jenkins
Branch: master

commit f1792f4089ccf28ec870104d0853e7fba242f24c
Author: Raildo Mascena <email address hidden>
Date: Mon Feb 8 14:58:34 2016 +0000

    Return 404 instead of 401 for tokens w/o roles

    If a scoped-token was validated and the user didn't have any role assignment
    on a project, keystone would return a 401 Unauthorized. This was the
    case when the fernet token provider was enabled because the reference is
    rebuilt on every request. The uuid token provider has a different behavior - if
    the token isn't found in the backend a 404 Not Found is returned. Furthermore,
    for persisted tokens, any validation error will result in 404, such as in the
    case where user no longer have any roles assigned for the given scope.

    These two behaviors should be consistent regardless of the token provider.

    Closes-Bug: 1541621
    Change-Id: If9fd6060ed13a7c03ab8d70ebed1adecafef9160

Changed in keystone:
status: In Progress → Fix Released

This issue was fixed in the openstack/keystone 9.0.0.0rc1 release candidate.

Reviewed: https://review.openstack.org/288816
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=53a6dc0e6a95f74905106d51f650bf4c2014bc08
Submitter: Jenkins
Branch: stable/liberty

commit 53a6dc0e6a95f74905106d51f650bf4c2014bc08
Author: Raildo Mascena <email address hidden>
Date: Mon Feb 8 14:58:34 2016 +0000

    Return 404 instead of 401 for tokens w/o roles

    If a scoped-token was validated and the user didn't have any role assignment
    on a project, keystone would return a 401 Unauthorized. This was the
    case when the fernet token provider was enabled because the reference is
    rebuilt on every request. The uuid token provider has a different behavior - if
    the token isn't found in the backend a 404 Not Found is returned. Furthermore,
    for persisted tokens, any validation error will result in 404, such as in the
    case where user no longer have any roles assigned for the given scope.

    These two behaviors should be consistent regardless of the token provider.

    Conflicts:
     keystone/tests/unit/test_v3_auth.py
     keystone/token/provider.py

    Closes-Bug: 1541621
    Change-Id: If9fd6060ed13a7c03ab8d70ebed1adecafef9160
    (cherry picked from commit f1792f4089ccf28ec870104d0853e7fba242f24c)

Roxana Gherle (roxana-gherle) wrote :

I still hit this issue with the latest master branch.
From what I see -> https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L298
that call should be surrounded with a try/catch for the Unauthorized exception.
Seems like X-Subject-Token is validated twice, once through the API and once through the protected decorator: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L155.

This issue was fixed in the openstack/keystone 8.1.2 release.

Roxana Gherle (roxana-gherle) wrote :

The bug (and the believe that the bug was fixed) was masked by token caching in devstack, so I proposed another patch that fixes this problem.

Reviewed: https://review.openstack.org/322280
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=fde57f68e290575e874234fc751d2380637a07f5
Submitter: Jenkins
Branch: master

commit fde57f68e290575e874234fc751d2380637a07f5
Author: Roxana Gherle <email address hidden>
Date: Fri May 27 10:00:39 2016 -0700

    Return 404 instead of 401 for tokens w/o roles

    If a scoped-token was validated and the user didn't have any role assignment
    on a project, keystone would return a 401 Unauthorized. This was the
    case when the fernet token provider was enabled because the reference is
    rebuilt on every request. The uuid token provider has a different behavior - if
    the token isn't found in the backend a 404 Not Found is returned. Furthermore,
    for persisted tokens, any validation error will result in 404, such as in the
    case where user no longer have any roles assigned for the given scope.

    These two behaviors should be consistent regardless of the token provider.

    This problem was not fixed entirely with https://review.openstack.org/#/c/277436/
    because of token caching in devstack which masks the wrong error code for the
    period of time the token is cached. Therefore, in order to test this in devstack
    you need to take into account the caching time after un-assigning the role on
    a project and while using the same fernet token.

    Closes-Bug: #1541621
    Change-Id: I9d36c5c73d5a832cd04dd4c1368b8d769e0acc4c

Reviewed: https://review.openstack.org/327386
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6b84b243a1c92ecfc8c525631747c0f6eaa30f2d
Submitter: Jenkins
Branch: stable/mitaka

commit 6b84b243a1c92ecfc8c525631747c0f6eaa30f2d
Author: Roxana Gherle <email address hidden>
Date: Fri May 27 10:00:39 2016 -0700

    Return 404 instead of 401 for tokens w/o roles

    If a scoped-token was validated and the user didn't have any role assignment
    on a project, keystone would return a 401 Unauthorized. This was the
    case when the fernet token provider was enabled because the reference is
    rebuilt on every request. The uuid token provider has a different behavior - if
    the token isn't found in the backend a 404 Not Found is returned. Furthermore,
    for persisted tokens, any validation error will result in 404, such as in the
    case where user no longer have any roles assigned for the given scope.

    These two behaviors should be consistent regardless of the token provider.

    This problem was not fixed entirely with https://review.openstack.org/#/c/277436/
    because of token caching in devstack which masks the wrong error code for the
    period of time the token is cached. Therefore, in order to test this in devstack
    you need to take into account the caching time after un-assigning the role on
    a project and while using the same fernet token.

    Closes-Bug: #1541621
    Change-Id: I9d36c5c73d5a832cd04dd4c1368b8d769e0acc4c
    (cherry picked from commit fde57f68e290575e874234fc751d2380637a07f5)

tags: added: in-stable-mitaka

This issue was fixed in the openstack/keystone 9.1.0 release.

This issue was fixed in the openstack/keystone 10.0.0.0b2 development milestone.

This issue was fixed in the openstack/keystone 8.1.2 release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers