[openstack-dev] [keysstone] External authentication

Adam Young ayoung at redhat.com
Tue Oct 2 14:36:39 UTC 2012


On 10/02/2012 07:51 AM, Alvaro Lopez wrote:
> 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.
We can likely do REMOTE_USER as one of those modules.  I think that is 
the right place for it:  assumethat we already have authentication 
performed at the time the middleware asks for it.

>
>>   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?
Yes.  We should split off the "authentication backend" from the 
"identity backend"  with the degenerate case being the authN backend 
defaults to the Id backend.


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

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

>
> Cheers,




More information about the OpenStack-dev mailing list