Open Stack

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,
-- 
Álvaro López García                              aloga at ifca.unican.es