external authentication v2 and v3 mismatch

[Brant Knudson]

This is regarding external auth handling between v2 and v3.

I want to write an external auth handler that supports email addresses as user names and works with both v2 and v3. It has to set REMOTE_USER to something. My users are named like <email address hidden>, and domain is just the default.

External auth handling for v2 doesn't do anything with @ [0]. So I'd set the REMOTE_USER to <email address hidden> and it'll work with v2, but <email address hidden>@default will not work.

External auth handling for v3 with the Default external auth handler removes everything after first @ [1]. So I'd set the REMOTE_USER to <email address hidden>@domain and it'll work, but <email address hidden> doesn't.

ExternalDefault external auth handler requires @ [2]. So I'd set the REMOTE_USER to <email address hidden>@domain, but <email address hidden> doesn't.

So to summarize, v2 will work with <email address hidden>, but v3 doesn't. V3 will work with <email address hidden>@domain but that doesn't work with v2.

So I'm not sure how an external auth handler is supposed to be written that supports email addresses and both v2 and v3 auth.

[0] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/controllers.py?id=2ab2c624353067ba0989720414e5cde2d4792bcc#n290

[1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/plugins/external.py?id=2ab2c624353067ba0989720414e5cde2d4792bcc#n70

[2] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/plugins/external.py?id=2ab2c624353067ba0989720414e5cde2d4792bcc#n86

[Dolph Mathews (dolph)]

How does [0] not "allow" @? It specifically handles the REMOTE_USER as a username in the default domain and doesn't care whether it's an email address or not.

[Dolph Mathews (dolph)]

AFAICT, [0] and [2] both seem to support username=<email>

[Brant Knudson (blk-u)]

I updated the description so that hopefully it's clearer.

[Dolph Mathews (dolph)]

Thanks brant! I understand the issue now -- this would be good fodder for the keystone-meeting, as it sounds like we have a deeper architectural problem in that we probably shouldn't be handling EXTERNAL_USER two different ways at all.

[Alvaro Lopez (aloga)]

@Brant: This is solved by https://review.openstack.org/#/c/50362

[Alvaro Lopez (aloga)]

@Brant: Sorry, I re-read it and it is not solved by that review, although it is related. According to the WSGI specification [*] the REMOTE_USER variable should contain only the username (as the V2 [0] does) and the above review [**] does for the ExternalDefault.

[*] http://wsgi.readthedocs.org/en/latest/specifications/simple_authentication.html#specification
[**] https://review.openstack.org/#/c/50362

[Alvaro Lopez (aloga)]

This is related with https://bugs.launchpad.net/keystone/+bug/1211233

[Brant Knudson (blk-u)]

Alvaro Lopez - Are you still planning to work on this?

[Alvaro Lopez (aloga)]

Brant: Yes, I am working on this. I've added some changes to the patchset mentioned above to fix this (to align the V3 behaviour with V2), but it breaks backwards compatibility.

https://review.openstack.org/#/c/50362

I will resubmit it keeping the original plugins, so that backwards compatibility is not broken.

[Alvaro Lopez (aloga)]

Just for completeness: "ExternalDefault external auth handler requires @ [2]. So I'd set the REMOTE_USER to <email address hidden>@domain, but <email address hidden> doesn't."

This is not true. ExternalDefault will map "<email address hidden>@domain" to "blk" [1].

So to summarize:

- "<email address hidden>":
    * V2 -> "<email address hidden>"
    * V3 ExternalDefault -> "blk" with default domain
    * V3 ExternalDomain -> "blk" with "acm.org" as domain

- "<email address hidden>@domain"
    * V2 -> "<email address hidden>@domain"
    * V3 ExternalDefault -> "blk" with default domain
    * V3 ExternalDomain -> "<email address hidden>" with "domain" as domain

- "<email address hidden>@":
    * V2 -> "<email address hidden>@"
    * V3 ExternalDefault -> "blk" with default domain as domain
    * V3 ExternalDomain -> "<email address hidden>" with default domain

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/50362
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1889ff207561c57587384063d61ef0b6f78457c4
Submitter: Jenkins
Branch: master

commit 1889ff207561c57587384063d61ef0b6f78457c4
Author: Alvaro Lopez Garcia <email address hidden>
Date: Tue Oct 8 11:08:42 2013 +0200

    Fix external auth (REMOTE_USER) plugin support

    According to the WSGI specification "REMOTE_USER should be the string
    username of the user, nothing more" [1], therefore no modifications
    should be made to the REMOTE_USER variable and it should be fully
    considered as the username. Otherwise the expected semantics of the
    REMOTE_USER variable change, and an site administrator could get
    undesirable side-effects.

    [1] http://wsgi.readthedocs.org/en/latest/specifications/simple_authentication.html#specification

    Moreover, it is important to have a consistent behaviour regarding
    external authentication in V2 (not domain aware), V3 with default
    domain and V3 with domain (see Bug #1253484) so that we produce similar
    results with the three methods.

    This change aims to solve this issues by removing the split of the
    REMOTE_USER variable by "@" at all:

    - In external.DefaultDomain, we cannot split REMOTE_USER by "@". This split
      will cause errors for remote users containing an "@" (not only
      emails, but also X.509 subjects, etc). The external.DefaultDomain plugin
      considers the REMOTE_USER variable as the username, and the configured
      default domain as the domain

    - In external.Domain we should not split also the REMOTE_USER by "@". A
      new environment variable (REMOTE_DOMAIN) is introduced, so that any
      external plugin can pass down the right domain for the user. The
      external.Domain plugin considers the REMOTE_USER as the username, the
      REMOTE_DOMAIN as the domain if it is present, otherwise it takes the
      configured default domain.

    - Two legacy plugins are also provided with the same behaviour as the
      Havana shipped ones. This plugins should not be used and are provided
      for compatibility reasons (see Bug #1254619)

    Closes-Bug: #1254619
    Closes-Bug: #1211233
    Closes-Bug: #1253484

    DocImpact: This change breaks backwards compatibility in favour of
    security (see bug #1254619), therefore an upgrade not is needed. It is
    needed to document the new plugins and state clearly the semantics of
    the REMOTE_USER and REMOTE_DOMAIN variable for the WSGI filters. The
    default external authentication plugin has been changed from
    exernal.ExternalDefault to external.Default.

    Change-Id: I1b2521a526fa976146dfe2fcf4d4c1851416d8ae