Comment 19 for bug 1561199

Reviewed: https://review.openstack.org/438719
Committed: https://git.openstack.org/cgit/openstack/swift3/commit/?id=cd094eea4a0da214d11b67ee6371629379afee1f
Submitter: Jenkins
Branch: master

commit cd094eea4a0da214d11b67ee6371629379afee1f
Author: Tim Burke <email address hidden>
Date: Mon Mar 21 20:40:41 2016 -0700

    Stop using client headers for cross-middleware communication

    Previously, we would use client-accessible headers to pass the S3 access
    key, signature, and normalized request to authentication middleware.
    Specifically, we would send the following headers:

        Authorization: AWS <access key>:<signature>
        X-Auth-Token: <base64-encoded normalized request>

    However, few authentication middleware would validate that the
    Authorization header actually started with "AWS ", the only prefix that
    Swift3 would actually handle. As a result, the authentication
    middlewares had no way to validate that the normalized request came from
    swift3 rather than the client itself. This leads to a security hole
    wherein an attacker who has captured a single valid request through the
    S3 API or who has obtained a valid pre-signed URL may impersonate the
    user that issued the request or pre-signed URL indefinitely through the
    Swift API.

    Now, the S3 authentication information will be placed in a separate
    namespace in the WSGI environment, completely inaccessible to the
    client. Specifically,

        environ['swift3.auth_details'] = {
            'access_key': <access key>,
            'signature': <signature>,
            'string_to_sign': <normalized request>,
        }

    (Note that the normalized request is no longer base64-encoded.)

    UpgradeImpact

    This is a breaking API change. No currently-deployed authentication
    middlewares will work with this. This patch includes a fix for s3_token
    (used to authenticate against Keystone); any deployers still using
    keystonemiddleware to provide s3_token should switch to using swift3.
    Similar changes are being proposed for Swauth and tempauth. Proprietary
    authentication middlewares will need to be updated to use the new
    environment keys as well. When upgrading Swift3, operators will need to
    upgrade their Swift3-capable authentication middleware at the same time.

    Closes-Bug: 1561199
    Change-Id: Ia3fbb4938f0daa8845cba4137a01cc43bc1a713c
    Depends-On: Ib90adcc2f059adaf203fba1c95b2154561ea7487