Fernet trust token is still valid when trustee's domain is disabled.

[Lance Bragstad]

When you have a Fernet trust-scoped token, and the user's domain is disabled, the token is still valid. This is inconsistent with the behavior of the UUID token provider.

Part of the fix has already been incorporated into a patch up for review [0], it was discovered by jorge_munoz in some of his testing. But, since this is an inconsistency between token providers - there was a case for breaking it out into it's own bug and it's own fix.

Steps to reproduce:
- Enable the Fernet token provider in the keystone.conf file
- Create domain A
- Create a user in domain A
- Create a project in domain A
- Grant the user in domain A a role on the project in domain A
- Create domain B
- Create a user in domain B
- As the user in domain A, create a trust with the user in domain B on the project in domain A
- As the user in domain B, get a project-scoped token using the trust
- As the admin, disable domain B (which is the trustee's domain)
- As the user in domain B, validate the trust-scoped token

This validation should return 404 Not Found, but instead it returns 200 OK. We have a patch in review that exposes the behavior for the Fernet provider [1].

[0] https://review.openstack.org/#/c/253273/27
[1] https://review.openstack.org/#/c/265455/4

[OpenStack Infra (hudson-openstack)]

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

[Lance Bragstad (lbragstad)]

I don't think this is a problem anymore. I have https://review.openstack.org/#/c/265455 passing locally.

[Lance Bragstad (lbragstad)]

I don't think this is specific to fernet anymore, so I'm going to remove the tag. https://review.openstack.org/#/c/265455/3 adds a test that is run by all token providers and it seems to be passing against master. Once that patch merges I think we can close this since we've added test coverage and it's no longer reproducible.

[Lance Bragstad (lbragstad)]

Actually - this is a bug. It only happens with the Fernet provider. The original test that I was using to reproduce this had the project for the trust and the trustee in the same domain. When that domain was disabled, the trust-scoped token would fail to validate because the owning domain of the project was disabled, which is a consistent behavior across all token providers.

This can be recreated if the project used in the trust and trustor are in their own domain and the trustee is in another. A trust is established between the trustor in domain X and the trustee in domain Y for a project in domain X. If domain Y is disabled, the trust-scoped token is still valid.

I'm going to rework the patch that exposes the behavior through tests and remove 'Closes-Bug' from the commit message.

[Lance Bragstad (lbragstad)]

So I think the reason for the inconsistency between the uuid provider and the fernet provider is because when a uuid token is revoked it is actually removed from the backend. Keystone fails to validate the trust-scoped token because it can't find it, not because it notices that the user is in a domain that is disabled. We should patch keystone to explicitly check to make sure the trustee's domain is enabled when we validate the token. This should make the behavior consistent across all providers.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit a7f059f8bd9aff68e39ffe88d1f9da4843c17487
Author: Lance Bragstad <email address hidden>
Date: Fri Jan 8 21:34:18 2016 +0000

    Expose bug with Fernet tokens and trusts

    When a trustee has a trust established with a project in a different domain, it
    is possible for trust-scoped tokens to still be valid even though the trustee's
    domain has been disabled. This commit adds a test to expose the behavior when
    using the Fernet token provider.

    Change-Id: I6e287735168ecdd52c28b7e5acf010b7a82e33c7
    Partial-Bug: 1532280

[OpenStack Infra (hudson-openstack)]

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

commit d53db1889e17d493202743246243936af90234b9
Author: Lance Bragstad <email address hidden>
Date: Thu Jul 7 18:32:11 2016 +0000

    Fix fernet token validate for disabled domains/trusts

    This commit adds a check when rebuilding the authorization context of a
    trust-scoped token to make sure that both the trustor and the trustee are in
    enabled domains. With this patch the uuid token provider and the fernet token
    provider give the same response when caching is disabled. If caching is
    enabled, the fernet provider will still consider a trust-scoped token valid
    even though the trustor/trustee is in a disabled domain. A subsequent patch
    will fix the revocation event to make sure the token is removed from the cache
    when a domain is disabled.

    Change-Id: If3e941018d5c2c9bd22397e69f83b7bf92643340
    Partial-Bug: 1532280

[OpenStack Infra (hudson-openstack)]

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

commit 81c9ddcd5056e4efb330d1590ba0f110d0802c4a
Author: Lance Bragstad <email address hidden>
Date: Thu Jul 7 20:53:48 2016 +0000

    Invalidate token cache on domain disablement

    This will invalidate the token cache when a domain is disabled. As a result,
    trust-scoped tokens that have a trustor or a trustee in a disabled domain will
    have to rebuild the authorization context instead of just retrieving it from
    the cache.

    Change-Id: I3f6b528c64a07980422d82c8ab5b5d4f9b01485c
    Closes-Bug: 1532280

[Davanum Srinivas (DIMS) (dims-v)]

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