Open Stack

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