Open Stack

Whilst on this topic, perhaps we should also expand it to discuss 
support for external authz as well. I know that Adam at Red Hat is 
working on adding additional authz attributes as env variables so that 
these can be used for authorising the user in keystone. It should be the 
same module in Keystone that handles the incoming request, regardless of 
whether it has only the remote user env variable, or has this plus a 
number of authz attribute env variables as well. I should like this 
module to end by returning the identity of the remote user in a standard 
internal keystone format (i.e. as a set of identity attributes), which 
can then be passed to the next phase of processing (which will include 
attribute mapping). In this way, we can have a common processing 
pipeline for incoming requests, regardless of how the end user was 
authenticated, ie. whether the request contains SAML assertions, env 
variables, OpenID assertions etc. Different endpoints could be used for 
the different incoming protocols, or a common endpoint could be used, 
with JSON parameters containing the different protocol information.

regards

David

On 29/10/2013 12:59, Álvaro López García wrote:
> Hi there,
>
> I've been working on this bug [1,2] related with the pluggable external
> authentication support in Havana. For those not familiar with it,
> Keystone can rely on the usage of the REMOTE_USER env variable, assuming
> that the user has been authenticated upstream (by an httpd server). This
> REMOTE_USER variable is supposed to store the username information that
> Keystone is going to use.
>
> In the Havana external authentication plugins, the REMOTE_USER variable
> is *always* split by the "@" character, assuming that the @ is being
> used as the domain separator (i.e. REMOTE_USER=username at domain).
>
> Now there are two plugins available:
>
> - ExternalDefault: Only the leftmost part of the REMOTE_USER after the
>    split is considered. The domain information is obtainted from the
>    default domain configured in keystone.conf.
>
> - ExternalDomain: The rightmost part is considered the domain, and the
>    leftover is considered the username.
>
> The change in [2] aims to solve this problem: ExternalDefault will not
> split the username by an "@" since we are going to use the default
> domain so we assume that no domain will be appended.
>
> However, this will work only if we are using a WSGI filter that is aware
> of the semantics: the filter should know if ExternalDefault is used so
> that the domain information is not appended, but append it if
> ExternalDomain is used. Moreover, if somebody is using directly the
> REMOTE_USER variable from Apache without any WSGI filter (for example
> using X509 auth with mod_ssl and the SSLUsername directive [3]) the
> REMOTE_USER will contain only the username and no domain at all.
>
> Does anybody have any concerns about this? Should we pass down the
> domain information by any other mean?
>
> [1] https://bugs.launchpad.net/keystone/+bug/1211233
> [2] https://review.openstack.org/#/c/50362/
> [3] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername
>