Comment 8 for bug 1299146

Maybe add:

> You must configure and run Identity API v 2.0 with Object Storage so that access control lists protect access to objects.
As a consequence you cannot use domain based tenants created via the V3.0 identity API with Object Storage. Note that
Current python clients for most services also do not yet support authentication for domain based tenants.

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf
> Of Anne Gentle
> Sent: 08 April 2014 17:07
> To: Day, Phil
> Subject: [Bug 1299146] Re: keystoneauth middleware not domain aware
> (keystone v3 issue)
>
> I'd like to add this warning in the install guide. Let me know if that location is
> sufficient and if you accept this wording:
>
> You must configure and run Identity API v 2.0 with Object Storage so that
> access control lists protect access to objects.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1299146
>
> Title:
> keystoneauth middleware not domain aware (keystone v3 issue)
>
> Status in OpenStack Identity (Keystone):
> Incomplete
> Status in OpenStack Security Advisories:
> Incomplete
> Status in OpenStack Object Storage (Swift):
> New
>
> 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/keystone/+bug/1299146/+subscriptions