Open Stack

I recently pushed my PoC pluggable authN handler code to a personal 
fork. The commit can be viewed here: 
https://github.com/BodenRussell/keystone/commit/e794705ad3a4ec2101090490b682690d0863c44d

It's not fully baked, but does the trick.

To add an authN handler:
a) Implement your handler class which extends the 
keystone.identity.authn.core.AuthenticationDriver
b) Provide a concrete impl of the 'authenticate(...)' method from that 
interface using the semantics noted in the method py doc. Note that the 
actual request object is in the context so you can access it like: 
context['request']
c) Make sure your handler class is in the python path for keystone
d) Add your package/class name to the '[authentication]' group/section 
of keystone.conf -- this is a list opt
e) Start keystone

I'm hoping this sample can help move along the pluggable authN 
blueprint: 
https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-authentication-handlers 
or some form of it.

I will try to join the keystone weekly meeting next week to sync up on 
our direction for this support.

Thanks


On 10/3/2012 12:08 PM, boden wrote:
> 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,
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>