Open Stack

Hi,
I won't be at the summit. However the email Adam replied to below is old 
-- I was at the Keystone meeting this week and we discussed this issue. 
We've also been discussing this topic offline and I have a different 
impl which I'm working (as per our discussion) to upstream which 
supports external authn via the REMOTE_USER context environ.

If you want to peek at the latest impl its here: 
https://github.com/BodenRussell/keystone/commit/2bee928f2dd88dd8e0fd18466194f3f217336cf7

again, I'm in the process of upstreaming so you should see a code review 
in the not so distant future. The new impl supports the bp (by using a 
piece of paste middleware to do the external authN) and also supports 
fronting keystone with something like HTTPD.

Thx

On 10/11/2012 6:06 PM, heckj wrote:
> Hey Boden,
>
> Nice setup - we definitely won't be having a regular keystone meeting next week (and I missed this week's as well). Are you going to be at the summit? Can we catch up there and discuss the blueprint?
>
> - joe
>
> On Oct 11, 2012, at 1:19 PM, Adam Young <ayoung at redhat.com> wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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
>