Open Stack

I agree with the comment made below regarding adding pluggable authN 
handlers to Keystone in addition to HTTPD support...

To me the ideal support for maximal flexibility is:
(a) We have (optional) HTTPD 'fronting' support for those consumers who 
wish to proxy a HTTP (WSGI capable) based server in front of the WSGI 
service. In this configuration the fronting server can optionally 
perform authN on behalf of Keystone.
(b) We continue to support the eventlet based model for those who wish 
to run as-is today, but also add support for pluggable authN handlers 
along the lines with the pluggable authentication handlers blueprint.

Having support for both opens the doors for many schemes.

For example, I currently have a requirement to support conditional authN 
based on a 'simple token' in the request header (AES encrypted with 
shared key). I'm not an apache expert, but it appears to handle this 
custom authN via apache I might use the mod_authnz_external module which 
calls my custom handler. As I understand, this approach could (although 
I have no hard evidence yet) introduce performance hits due the external 
module having to create a new process for each request and piping to it. 
I would likely prefer to implement a Python based authN handler and plug 
it into Keystone (which I've already done with a PoC).

BTW -- Based on recent side conversations, I believe some members of the 
Swift community will soon be publishing a blueprint which focuses on 
enabling (optional) HTTPD support for all WSGI services. With that in 
mind maybe we should be working across the OpenStack projects for this 
support so that all services have consistent behavior. The blueprint 
should be published by the Swift team in the next few days, and I'll 
post it to this list once it becomes available.

Thx

On 10/3/2012 8:18 AM, Álvaro López García wrote:
> Hi Adam.
>
> On Tue 02 Oct 2012 (10:36), Adam Young wrote:
>> On 10/02/2012 07:51 AM, Alvaro Lopez wrote:
>>
>> (...)
>>
>>>> 1.  If the user is not in the local store, look in the remote store
>>>> 2.  If the user is in the local store, still authenticate against
>>>> the remote store.
>>> I think this is a key part of the design, that is, how to define the
>>> rules that apply to either the plugged modules and the identity store
>>> backend.
>>>
>>>> 3.  Use the REMOTE_USER as id, iff there is no other ID specified
>>>> (gets into the original topic of this thread)
>>>> 4.  Use the Client Certificate from the SSL connection.
>>> With the BP in mind I see these as a particular case of two different
>>> pluggable modules, lets say keystone.identity.authN.external for
>>> REMOTE_USER and keystone.identity.authN.SSL for client certificates.
>>
>> Kerberos is a potential third.  However,  user certs and Kerberos
>> are both probably best done by Apache HTTPD.  Take a look at how
>> mod_nss handles the Client Cert code and you will realize that we do
>> not want to try and reproduce that in Eventlet.
>
> Indeed you're right. Reinventing the wheel was not my intetion (see
> below).
>
>>>> I am starting to worry that this is more work than justified, as
>>>> Apache HTTPD already supports this form of authentication.  I am not
>>>> sure it makes sense to rebuild this functionality.
>>>>
>>>> Do the features of Apache HTTPD authentication solve your use cases
>>>> if they are done in conjunction with REMOTE_USER?  if so, perhaps we
>>>> should put our effort into making HTTPD the default server instead.
>>>> Note that I am not saying "no"  just want to justify the effort.
>>>> Even if we go HTTPD, we will still need to address the local/remote
>>>> split.
>>> Apache could solve most of the use cases (plain x509 certificates,
>>> kerberos, etc), but not all of them (I am not too familiar with
>>> apache authn though). For example, some authN modules could require
>>> some more logic behind that could difficult to be made in Apache.
>>
>> Lets defer that thought until we have the real limit to HTTPD.  I am
>> not suggesting that we check Eventlet completely just yet, but I
>> would be surprised to find there was something that we just could
>> not do completely within the scope of HTTPD.
>
> Maybe I was not clear, I didn't meant that at all.
>
> I agree with you in going HTTPD. What I wanted to state is not to just
> add support for external authn via REMOTE_USER, but add support for the
> pluggable authn modules (as described in the the BP) being "external
> authN" one of these modules. This way:
>
>   - If there's a way to do authN (ldap, X.509, kerberos, etc) in Apache,
>     the external authn module should be the way to go.
>   - If there's somebody that wants to develop/implement an additional
>     authentication module provide them with the pluggable infrastructure
>     needed to do so.
>
> Cheers,
>