Open Stack

On 09/28/2012 11:37 AM, boden wrote:
> Good points Adam...
> I'm not intimately familiar Apache authN (or all the various auth 
> modules for Apache), so I'll have to do some poking and get back to 
> you on this one. I think we obviously need to understand the overall 
> pros/cons with each approach -- for example what else does Apache 
> buy/cost us, even if it can enable the use cases...

I've thought about this a bit over time.

http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/
http://adam.younglogic.com/2012/04/keystone-httpd/

The code to deploy Keystone in HTTPD was committed over the summer.

Here is a short list of the things that you get:

Basic Auth and its variants
Kerberos
X509
Preemptive Multitasking
IPv6 Support
SELinux Policy support, but that requires you to deploy on port 443 as 
opposed to 5000 and 35357.

Aside from battling with Horizon for control of HTTPD in installs where 
they are on the same system, I don't really see any drawbacks.  I have 
reason to believe that it will scale at least as well as Eventlet based 
on the actual usage, but I don't have then numbers to back it up yet.  
However, with PKI enabled, it is likely to be a non-issue anyway.


> Does it make sense to move this discussion into the blueprint 
> whiteboard or wiki spec so that we can document the current discussion 
> outside of the email list?
Lets keep it on email until we have a consensus of which approach is better.
>
> Thx
>
>
> On 9/28/2012 10:15 AM, 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
>>
>>
>>   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:
>>
>> 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.
>> 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.
>>
>> 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.
>>
>>
>>>
>>> On 9/27/2012 1:55 PM, Adam Young wrote:
>>>> On 09/27/2012 08:24 AM, boden wrote:
>>>>> Hi,
>>>>> I was recently looking into this same topic and came across the 
>>>>> related
>>>>> blueprint:
>>>>> https://blueprints.launchpad.net/keystone/+spec/sql-identiy-pam
>>>> This is a little different.
>>>>
>>>>> I have been trying to reach the blueprint author by email for a few
>>>>> days
>>>>> to understand if there has been any community interest in his
>>>>> blueprint,
>>>>> but no response from him yet.
>>>> That is OK,  I can plauy that role. I am not sure that I want to 
>>>> tie it
>>>> to PAM,  but I can see the rationale that you *should* be able to use
>>>> PAM for this.
>>>>
>>>> BTW, there is nothing that should be SQL specific to it. The LDAP code
>>>> uses a Simple Bind, and that is also something I would like to make
>>>> optional.
>>>>
>>>>> IMO PAM support in Keystone decoupled from the underlying Identity
>>>>> Driver would be a nice value-add. This would allow consumers to 
>>>>> use PAM
>>>>> transparently across all concrete identity drivers (LDAP, SQL, etc.)
>>>>> opening the door for numerous authentication mechanisms (as you
>>>>> mentioned).
>>>> Agreed
>>>>> I recently implemented a prototype for PAM support in Keystone, and
>>>>> although similar to what you describe it appears to be more 
>>>>> generic...
>>>>>
>>>>> Rather than going into the details of the design, let me state the 
>>>>> core
>>>>> use cases that my prototype supports:
>>>>> * As a keystone admin, I want the ability to specify 1 or more
>>>>> authentication module classes in keystone.conf that can
>>>>> conditionally be
>>>>> used to authenticate a POST /tokens request in the keystone service.
>>>>> * As a keystone admin, I want to be able to use keystone PAM classes
>>>>> irrespective of the concrete identity driver type (SQL, LDAP, KVS,
>>>>> etc.).
>>>>> * As an keystone PAM developer, I want my module implementation to 
>>>>> have
>>>>> access to the request body/header in the POST /tokens request so 
>>>>> that I
>>>>> can get/put properties from/into it and also conditionally 
>>>>> determine if
>>>>> my module is applicable for the current request.
>>>>> * As a keystone PAM developer, I want my module implementation to
>>>>> have a
>>>>> reference to the concrete identity driver being used so that I can
>>>>> interface with it as needed.
>>>>> * As a keystone admin, I want my concrete identity driver's
>>>>> authentication functionality used when no PAM classes are 
>>>>> specified in
>>>>> keystone.conf (i.e. what we have today) or when none of the PAM 
>>>>> classes
>>>>> are applicable to the given POST /tokens request.
>>>> Definitely write this up a blueprint.  We will replace the PAM one 
>>>> above
>>>> with yours.
>>>>
>>>>> I realize the proper way to socialize this idea is via a blueprint.
>>>>> However given this idea encompasses the existing blueprint I linked
>>>>> above I was hoping to 1st sync up with the existing blueprint author.
>>>>>
>>>>> That said, I'm doing a little fishing here -- anyone have interest in
>>>>> this idea?
>>>>>
>>>>> Thx
>>>>>
>>>>>
>>>>> On 9/27/2012 4:15 AM, Ralf Haferkamp wrote:
>>>>>> On Tue, Sep 25, 2012 at 04:06:36PM -0700, heckj wrote:
>>>>>>> Ralf -
>>>>>>>
>>>>>>> Keystone supports this by having an internal API that allows you to
>>>>>>> write
>>>>>>> your own authentication backend for the various components. For 
>>>>>>> this
>>>>>>> sort of
>>>>>>> use, I'd recommend writing your own backend for Identity that
>>>>>>> interacts with
>>>>>>> and translates from the back-end systems you're interested in 
>>>>>>> using.
>>>>>> Hm, I am trying to implement this in a way that is independed of the
>>>>>> identity
>>>>>> backend that is actually used. And currently it is only meant to
>>>>>> handle the
>>>>>> authentication part. Information about which Users, Roles and 
>>>>>> Tenants
>>>>>> are
>>>>>> present is still handled by the existing Drivers. So implementing
>>>>>> another
>>>>>> Identity backend for this seemed wrong (if possible at all).
>>>>>> Keystone, when
>>>>>> configured for external Authentication, would just trust apache (or
>>>>>> another
>>>>>> entity external to keystone) for doing authentication and providing
>>>>>> information
>>>>>> about the authenticated user. This is I think very helpful to 
>>>>>> support
>>>>>> things
>>>>>> like Kerberos Authentication (or X.509 Client Certificates) which do
>>>>>> not rely
>>>>>> on the username/password scheme that "normal" keystone 
>>>>>> authentication
>>>>>> currently
>>>>>> requires.
>>>>>>
>>>>>> Currently I have implemented my prototype in this way:
>>>>>> - implemented a wsgi.Middleware, that when added into keystone's
>>>>>>     public-/admin_api pipelines, extracts apache's information
>>>>>> about the
>>>>>>     authenticated user from the Enviroment and adds that
>>>>>> information to
>>>>>>     keystone's request context.
>>>>>>
>>>>>> - in TokenControler.authenticate(), if the above information is
>>>>>> present in the
>>>>>>     context, I check if that user is present (and not disabled) 
>>>>>> in the
>>>>>> currently
>>>>>>     configured identitiy backend and issue a new token for that 
>>>>>> user.
>>>>>> (That means
>>>>>>     there's no need for any username/password to be present in the
>>>>>> POSTed JSON
>>>>>>     document)
>>>>>>
>>>>>> So this should really work independed of the identity backend 
>>>>>> that is
>>>>>> in use
>>>>>> and doesn't require the introduction of a new backend I think.
>>>>>>
>>>>>> regards,
>>>>>>       Ralf
>>>>>>
>>>>>>> Chris Hoge at U Oregon did something very much like this with the
>>>>>>> UOregon SSO
>>>>>>> system (I heard about it at OSCON this past July).
>>>>>>>
>>>>>>> The relevant internal API for Identity is documented in
>>>>>>> http://docs.openstack.org/developer/keystone/keystone.identity.html#module-keystone.identity.core, 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> and you can read the backends that implement that set of methods in
>>>>>>> keystone/identity/backends - kvs.py, sql.py, etc.
>>>>>>>
>>>>>>> - joe
>>>>>>>
>>>>>>> On Sep 25, 2012, at 2:20 AM, Ralf Haferkamp <rhafer at suse.de> wrote:
>>>>>>>> I've been thinking about adding support for External
>>>>>>>> Authentication to
>>>>>>>> keystone. By "External Authentication" I mean that e.g. when I run
>>>>>>>> keystone
>>>>>>>> behind apache it would be nice if I could just let apache 
>>>>>>>> handle the
>>>>>>>> authentication (via mod_auth_kerb for example) and have keystone
>>>>>>>> issue a Token
>>>>>>>> based on the information that apache provides about the
>>>>>>>> authenticated user
>>>>>>>> (e.g. the username is usually passed via the REMOTE_USER env
>>>>>>>> variable).
>>>>>>>>
>>>>>>>> I am currently wondering how the client should indicate to the
>>>>>>>> server that
>>>>>>>> External Auth should be used? One could add another parameter to
>>>>>>>> the JSON doc
>>>>>>>> that's POSTed during keystone authentication instead of the
>>>>>>>> username/password
>>>>>>>> tuple, but is that really needed or should keystone just check of
>>>>>>>> the presence
>>>>>>>> of specific ENV variables (e.g. REMOTE_USER as set by apache2) 
>>>>>>>> when
>>>>>>>> external
>>>>>>>> auth is enabled. In my current prototype implementation I do just
>>>>>>>> that. What
>>>>>>>> would be the preferable approach here?
>>>>>>>>
>>>>>>>> BTW, has anybody else been working on this already? Does this even
>>>>>>>> sound like a
>>>>>>>> feature worth adding?
>>>>>> _______________________________________________
>>>>>> 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
>>
>>
>> _______________________________________________
>> 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