yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan.fainberg@xxxxxxxxx>]

Based on conversation with John Dickinson and the bug, I am removing
KEystone from this bug as there is nothing to do within Keystone.

** No longer affects: keystone

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1299146

Title:
  keystoneauth middleware not domain aware (keystone v3 issue)

Status in OpenStack Manuals:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Object Storage (Swift):
  Fix Committed

Bug description:
  
  With Keystone V3, user's in two different domains can have the same name. Swift ACLs contian the "bare" username. Example:

      X-Container-Read: *:sally

  This is ok with Keystone V2, where all users have unique names.
  However, with Keystone V3, there could be a "sally" in domain "A" and
  a different "sally" in domain "B". As-is, this allows information to
  leak to unauthorized/unintended users. Hence this bug is marked as a
  security vulnerability.

  Note: the solution is not to simply to continue use the v2 API in
  auth_token. The problem is at the Keystone server side; specifically
  if you allow multiple domains, user name clashes can occur. With the
  v2 API, auth_token does not know what the domain name is. With the V3
  API auth_token, it adds X-DOMAIN-NAME and X-DOMAIN-ID to the
  environment. However, since keystoneauth does not look at these
  variables, using V3 in auth_token does not add anything.

  We could extend the ACL syntax to assoicate the domain with the
  intended user. For example: sally@A. However, exisitng ACLs must be
  supported. However, swift does not know the domain associated with an
  account...making it difficult to map usernames in the ACL to a domain.

  Even if the Swift middleware is made domain-aware, we need to warn
  deployers that they must not combine V3 multiple domains with V2
  auth_token in the pipeline. A solution that would allow that is to
  have an option in Keystone to enforse unique usernames across domains.
  With that option, there would be no need to worry about domains when
  processing Swift ACLs. I'll file a Keystone bug for this suggestion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1299146/+subscriptions