swift_auth should support ACL's with tenant_id:user_id

[Dan Prince]

The swift_auth middleware should support individual user ACL's in the user_id:tenant_id format.

Swift_auth middleware currently supports:

username:tenant_id
username: tenant_name

I'd like to be able to use user_id:tenant_id as well (to avoid having hard coded usernames in my Swift object permissions).

[OpenStack Infra (hudson-openstack)]

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

[Kun Huang (academicgareth)]

tenant_name:user_name ok
tenant_name:user_id bad
tenant_id:user_name ok
tenant_id:user_id you want to fix

This is more simple

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/22820
Committed: http://github.com/openstack/swift/commit/58a095b93e1e6f742e619a100e8cec693bc41dad
Submitter: Jenkins
Branch: master

commit 58a095b93e1e6f742e619a100e8cec693bc41dad
Author: Kun Huang <email address hidden>
Date: Tue Mar 26 13:20:09 2013 +0800

    Improve swift's keystoneauth ACL support

    Below three bug reports talk about one thing.
    Current keystoneauth ACL supports as:

    tenant_name:user_id ok
    tenant_name:user_name no
    tenant_name:* no
    tenant_id:user_id ok
    tenant_id:user_name no
    tenant_id:* no
    *:user_id ok
    *:user_name no
    *:* no

    This patch will make all of above work fine.
    Applying (tenant/user)name could let user put or get their data in a
    more readable way. The tenant_name:* and *:user_name is suitable for
    many usage.

    note: to keep compatibility here add a new keystone.identity just for
    authorize() itself and leave env['keystone.identity'] to other
    middlerwares.

    Fixes: bug #1020709
    Fixes: bug #1075362
    Fixes: bug #1155389
    Change-Id: I9354dedaad875117f6a9072c67e9ecf69bfca77e