[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