HTTPUnauthorized does not include Keystone uri

[Salvatore Pinto]

Patch for https://bugs.launchpad.net/swift/+bug/1215491 fixed missing WWW-Authenticate header when 401 error is returned, but it set www-authenticate always to the Swift catch-all scheme, even when Keystone authentication is used.

Attached patch changes this behavior, setting the www-authenticate header to "Keystone uri" for the Keystone authentication scheme.

[Donagh McCabe (donagh-mccabe)]

The original reason that www-authenticate returns a catch-all "swift" response is that the auth_uri parameter is not available to keystoneauth. The proxy-server.conf file looks like::

    [filter:auth_token]
    ...
    auth_uri = https://identity-endpoint/v2.0
    ...

    [filter:keystoneauth]
    use = egg:swift#keystoneauth

It might seem a trivial change to move the auth_uri to the [default] section or to make a copy in [filter:keystoneauth]. However, that requires action by deployers....so your proposed patch is not backward compatible.

[Salvatore Pinto (salvatore-pinto)]

I could slightly modify the patch to include the keystone response (instead of the catch-all) only if auth_uri is present in the [filter:keystoneauth] section, thus this will be backward compatible. Would be this ok in your opinion?

It is quite important for us to have the capability to expose the keystone URI, because we are using directly the SWIFT endpoint as starting entry for the user.

[Donagh McCabe (donagh-mccabe)]

Probably a better way is for auth_token (in keystonemiddleware) to put it's version of www-authenticate or the auth_uri into the environment (in a similar way that HTTP_X_ROLES are put into the environment). That way, keystoneauth could construct a good www-authenticate.

I think this is a reasonable general purpose change for auth_token. Given that auth_token supports delay_auth_decision, which implies that the 401 can be generated by the service, it makes sense that the service needs the auth_uri.

However, I like your idea as a fall back. i.e., if HTTP_X_AUTH_URI is in the environment, keystoneauth uses it. Otherwise, if auth_uri is a parameter in [filter:keystoneauth], use it. All else failing use the catch-all.

Instead of attaching a patch to this bug, I suggest you submit code changes to review.openstack.org -- that way you will get more eyes on this problem.

[OpenStack Infra (hudson-openstack)]

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

[Salvatore Pinto (salvatore-pinto)]

Fix proposed to KeystoneClient master branch, to add HTTP_X_AUTH_URI: https://review.openstack.org/#/c/113579/

[OpenStack Infra (hudson-openstack)]

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

[Jamie Lennox (jamielennox)]

I hadn't seen any advancement on this since the keystoneclient review was to be moved to keystonemiddleware so I created a more general fix in middleware that should solve the issue. Hope that's ok.

https://review.openstack.org/119261

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/119261
Committed: https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=563991136646eb6d913e94e482323966b0393db2
Submitter: Jenkins
Branch: master

commit 563991136646eb6d913e94e482323966b0393db2
Author: Jamie Lennox <email address hidden>
Date: Thu Sep 4 17:58:49 2014 +1000

    Always add auth URI to unauthorized requests

    For those services that use delay_auth_decision we need to support
    adding the keystone URI rejection headers to the response in a uniform
    way. I feel this should be more generic and that every 401 response
    should contain this header.

    Create a WSGI wrapper so that if a 401 is ever returned through
    auth_token middleware we can add an additional WWW-Authenticate header.

    Closes-Bug: #1349364
    Change-Id: Ib5231a09fd5c6cb6cd17f07c87e982d2e8fde2bf

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alistair Coles (<email address hidden>) on branch: master
Review: https://review.openstack.org/113577
Reason: Alternative solution has merged https://review.openstack.org/#/c/119261

@Salvatore - thanks for raising this issue and your work on this patch. I believe the keystonemiddleware solves the issue so I'm abandoning this patch to avoid confusion.

[Tim Burke (1-tim-z)]

Looks like this was addressed in keystonemiddleware?