yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

When getting tokens from keystone, the response will contain a token
body. One of the attributes of the token response is a list of roles
that correspond to the scope of the token (e.g. roles for a project, or
domain, etc.)

Traditionally, the list of roles only consists of two pieces of
information about each role, the `id` and the `name`. During the
implementation of domain-specific roles, the token provider API was
modified to handle those cases [0]. The result is that when you get a
trust scoped token, the list of roles actually includes the `domain_id`,
too. This is because the token provider API copies the role reference
from the role API directly into the token response [1], instead of only
using the `id` and `name` attributes.

The good this is that this is only done when the role's domain_id ==
None, which means we're not leaking any sensitive information about
domain-specific roles. The bad thing is that it doesn't really present
any useful information and if 'domain_id' is in the role reference it's
always None. This results in trust-scoped tokens having different
responses than other token formats. It also opens up the ability for
more data leakage in the event we ever expand the role entity to include
another attribute.

This was uncovered in a patch to make parts of our JSONschema testing
more DRY [2].

[0] https://review.openstack.org/#/c/263064/19
[1] https://github.com/openstack/keystone/blob/694ef627dd5a544b8200703fa4a42220d6f4784c/keystone/token/providers/common.py#L393-L394
[2] https://review.openstack.org/#/c/407587/1

** Affects: keystone
     Importance: Undecided
         Status: New

** Description changed:

  When getting tokens from keystone, the response will contain a token
- body. One of the attributes of the token response is a list of roles the
- correspond to the scope of the token (e.g. roles for a project, or
+ body. One of the attributes of the token response is a list of roles
+ that correspond to the scope of the token (e.g. roles for a project, or
  domain, etc.)
  
  Traditionally, the list of roles only consists of two pieces of
  information about each role, the `id` and the `name`. During the
  implementation of domain-specific roles, the token provider API was
  modified to handle those cases [0]. The result is that when you get a
  trust scoped token, the list of roles actually includes the `domain_id`,
  too. This is because the token provider API copies the role reference
  from the role API directly into the token response [1], instead of only
  using the `id` and `name` attributes.
  
  The good this is that this is only done when the role's domain_id ==
  None, which means we're not leaking any sensitive information about
  domain-specific roles. The bad thing is that it doesn't really present
  any useful information and if 'domain_id' is in the role reference it's
  always None. This results in trust-scoped tokens having different
- responses than other token formats.
+ responses than other token formats. It also opens up the ability for
+ more data leakage in the event we ever expand the role entity to include
+ another attribute.
  
  This was uncovered in a patch to make parts of our JSONschema testing
  more DRY [2].
  
- 
  [0] https://review.openstack.org/#/c/263064/19
  [1] https://github.com/openstack/keystone/blob/694ef627dd5a544b8200703fa4a42220d6f4784c/keystone/token/providers/common.py#L393-L394
  [2] https://review.openstack.org/#/c/407587/1

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1763510

Title:
  Trust scoped tokens leak domain information about a role

Status in OpenStack Identity (keystone):
  New

Bug description:
  When getting tokens from keystone, the response will contain a token
  body. One of the attributes of the token response is a list of roles
  that correspond to the scope of the token (e.g. roles for a project,
  or domain, etc.)

  Traditionally, the list of roles only consists of two pieces of
  information about each role, the `id` and the `name`. During the
  implementation of domain-specific roles, the token provider API was
  modified to handle those cases [0]. The result is that when you get a
  trust scoped token, the list of roles actually includes the
  `domain_id`, too. This is because the token provider API copies the
  role reference from the role API directly into the token response [1],
  instead of only using the `id` and `name` attributes.

  The good this is that this is only done when the role's domain_id ==
  None, which means we're not leaking any sensitive information about
  domain-specific roles. The bad thing is that it doesn't really present
  any useful information and if 'domain_id' is in the role reference
  it's always None. This results in trust-scoped tokens having different
  responses than other token formats. It also opens up the ability for
  more data leakage in the event we ever expand the role entity to
  include another attribute.

  This was uncovered in a patch to make parts of our JSONschema testing
  more DRY [2].

  [0] https://review.openstack.org/#/c/263064/19
  [1] https://github.com/openstack/keystone/blob/694ef627dd5a544b8200703fa4a42220d6f4784c/keystone/token/providers/common.py#L393-L394
  [2] https://review.openstack.org/#/c/407587/1

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1763510/+subscriptions