Open Stack

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

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
>