Open Stack

On 10/04/2012 02:13 PM, boden wrote:
> 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

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

Next week is the Summit, so the meeting will likely not happen.

>
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev