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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
