Open Stack

Hi there.

On Fri 28 Sep 2012 (10:15), Adam Young wrote:
> On 09/28/2012 09:29 AM, boden wrote:
> >I wrote this up as a blueprint:
> >https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-authentication-handlers
> >
> >Direct link to the spec (wiki) for your convenience:
> >http://wiki.openstack.org/PluggableIdentityAuthenticationHandlers

This is something that we are also focusing on. Currently we have a
prototype implementing several authentication modules (very similar to
the idea posted by Dolph some days ago) but I think that the design
described by boden fits better into our needs.

>  One thing I'd like to clarify is how it would work along side a
> local identity store in conjunction with a remote, read-only
> identity store.  I am thinking local SQL with remote LDAP, as that
> is the use case most people have brought up.  We need to be able to
> specify a rules that say things like:

If I understood the BP correctly, there will be only one identity
backend, thus any other authN module should be implemented as a
pluggable module, right?

> 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.

> 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.

Cheers,
-- 
Álvaro López García                              aloga at ifca.unican.es