trustor_user_id not available in v2 trust token

Bug #1331882 reported by Jamie Lennox
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Wishlist
wanghong
OpenStack Security Notes
Won't Fix
Medium
Jamie Finnigan

Bug Description

The trust information in the v2 token is missing the trustor_user_id and impersonation values. This means you are unable to tell who gave you the trust.

The following two examples were generated with the same information. (They are printed from client.auth_ref which is why they are missing some structure information)

v2 Trust token:

{u'metadata': {u'is_admin': 0,
               u'roles': [u'136bc06cef2f496f842a76644feaed03',
                          u'7d42773abeff45ea90fdb4067f6b3a9f']},
 u'serviceCatalog': [...],
 u'token': {u'expires': u'2014-06-19T02:41:19Z',
            u'id': u'4b8d23d9707a4c9f8a270759725dfcf8',
            u'issued_at': u'2014-06-19T01:41:19.811417',
            u'tenant': {u'description': u'Default Tenant',
                        u'enabled': True,
                        u'id': u'9029b226bc894fa3a23ec24fd9f4796c',
                        u'name': u'demo'}},
 u'trust': {u'id': u'0b16de31a8c64fd5b0054054db468a00',
            u'trustee_user_id': u'f6cce259563e40acb3f841f5d89c6191'},
 u'user': {u'id': u'f6cce259563e40acb3f841f5d89c6191',
           u'name': u'bob',
           u'roles': [{u'name': u'can_create'}, {u'name': u'can_delete'}],
           u'roles_links': [],
           u'username': u'bob'}}

v3 Trust token:

{u'OS-TRUST:trust': {u'id': u'0b16de31a8c64fd5b0054054db468a00',
                     u'impersonation': False,
                     u'trustee_user': {u'id': u'f6cce259563e40acb3f841f5d89c6191'},
                     u'trustor_user': {u'id': u'5fcb10539aa646ea8b0fe3c80e15d33d'}},
 'auth_token': '0b8a2d2e081e4e6e8ae3ad5dfedcf9db',
 u'catalog': [...],
 u'expires_at': u'2014-06-19T02:41:19.935302Z',
 u'extras': {},
 u'issued_at': u'2014-06-19T01:41:19.935330Z',
 u'methods': [u'password'],
 u'project': {u'domain': {u'id': u'default', u'name': u'Default'},
              u'id': u'9029b226bc894fa3a23ec24fd9f4796c',
              u'name': u'demo'},
 u'roles': [{u'id': u'136bc06cef2f496f842a76644feaed03',
             u'name': u'can_create'},
            {u'id': u'7d42773abeff45ea90fdb4067f6b3a9f',
             u'name': u'can_delete'}],
 u'user': {u'domain': {u'id': u'default', u'name': u'Default'},
           u'id': u'f6cce259563e40acb3f841f5d89c6191',
           u'name': u'bob'}}

Dolph Mathews (dolph)
Changed in keystone:
importance: Undecided → Wishlist
status: New → Triaged
wanghong (w-wanghong)
Changed in keystone:
assignee: nobody → wanghong (w-wanghong)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

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

Changed in keystone:
status: Triaged → In Progress
tags: added: meeting-topic
Changed in keystone:
milestone: none → juno-rc1
Revision history for this message
Lance Bragstad (lbragstad) wrote :

This was discussed in the #openstack-keystone meeting and we've decided to move forward with the proposed fix and include this for Juno RC1.

tags: removed: meeting-topic
Revision history for this message
Dolph Mathews (dolph) wrote :

Added OSSN to this bug because in the above code review [1], Guang Yee suggested that it's a security concern that v2 trust-based tokens lack:

1) any indication of WHO is entrusting another user with their authorization (the trustor_user_id).
2) a flag indicating whether the identity presented by the token is the trustor's or trustee's (impersonation=True/False).

Given the trustee_user_id IS included with v2 trust tokens, an auditor will be able to discern if impersonation is in effect based on whether trustee_user_id matches the user ID presented by the token. So:

  Impersonation enabled: trustee_user_id != token's user ID (unless the user created a trust with themselves).
  Impersonation disabled: trustee_user_id == token's user ID, and the trustor is NOT discernible without referencing the trust entity.

All of this sounds a bit scary, but trusts are immutable and v2 trust tokens DO contain a reference to a trust ID, which provides a fallback for auditing purposes here.

[1] https://review.openstack.org/#/c/101829/ - see Guang Yee's comment on September 9

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

I've confirmed there is no exposure in revocations / revocation events. in all cases we directly refer to the trust_id instead of trustor_user. This is likely not an OSSN and definitely falls into the "would be nice but not required" category.

I believe we should hold this for Kilo (if it is to be accepted).

Dolph Mathews (dolph)
tags: added: juno-rc-potential
Changed in keystone:
milestone: juno-rc1 → none
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit 16760cd13d9edd050ba8dc6c017cf3b221bd2deb
Author: wanghong <email address hidden>
Date: Mon Jun 23 16:34:53 2014 +0800

    trustor_user_id not available in v2 trust token

    The trust information in the v2 token is missing the trustor_user_id
    and impersonation values. This means you are unable to tell who gave
    you the trust.

    Change-Id: I7ed215b3353079d8ed9514c586d256c1226a2c19
    Closes-bug: #1331882
    DocImpact

Changed in keystone:
status: In Progress → Fix Committed
Dolph Mathews (dolph)
Changed in keystone:
milestone: none → juno-rc1
Thierry Carrez (ttx)
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in keystone:
milestone: juno-rc1 → 2014.2
Grant Murphy (gmurphy)
Changed in ossn:
assignee: nobody → Grant Murphy (gmurphy)
importance: Undecided → Medium
status: New → In Progress
Grant Murphy (gmurphy)
Changed in ossn:
assignee: Grant Murphy (gmurphy) → Jamie Finnigan (jamiefinnigan)
Revision history for this message
Jamie Finnigan (jamiefinnigan) wrote :

Per commentary here and on https://review.openstack.org/#/c/101829/, there is a minimal data gap but no security exposure. Skipping the OSSN, given this conclusion.

Changed in ossn:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.