Open Stack

On 10/29/2013 12:18 PM, Tim Bell wrote:
> We also need some standardisation on the command line options for the client portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this is not yet in Oslo so there would be multiple packages to be enhanced.
There is a OS client talk on Wednesday that you should atend. Getting 
the Auth options striaght in a common client will be a huge benefit.


>
> Tim
>
>> -----Original Message-----
>> From: Alan Sill [mailto:kilohoku150 at gmail.com]
>> Sent: 29 October 2013 16:36
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [keystone] Support for external authentication (i.e. REMOTE_USER) in Havana
>>
>> +1
>>
>> (except possibly for the environmental variables portion, which could and perhaps should be handled through provisioning).
THis is the Apache ENV dictionary,  not system environemnte variables.  
This means that Apache modules can potentially pas on more than just the 
username or comparable authentication value.


>>
>> 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.
Love this idea.  We can discuss in the Federation session.


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