Open Stack

+1

(except possibly for the environmental variables portion, which could and perhaps should be handled through provisioning).

On Oct 29, 2013, at 8:35 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:

> 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
>> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev