REMOTE_USER support should be more flexible in how domain is specified

(from IRC discussion)

This bug makes difficult to properly use external authentication with usernames containing a "@" in Havana. For example, authentication based in X.509 certificates containing a "@" in their DNs (REMOTE_USER is set to the DN in these cases) will cause that the username is splited by the "@" and the username will be wrong.

The solution of passing the domain via the request-block will work for WSGI filters, but may fail in the case of Apache setting the REMOTE_USER variable (for example in X.509 auth [1]).

[1] http://docs.openstack.org/developer/keystone/external-auth.html#x-509-example

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

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/51797

I think that its importance should be moved from wishlist.

Currently, it is impossible to use external authentication for usernames containing an "@" without domains in Havana.

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

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