[openstack-dev] [keysstone] External authentication

Matt Joyce matt.joyce at cloudscaling.com
Thu Sep 27 18:03:43 UTC 2012


Actually, have you considered SASL?

That might be far superior to PAM.

And sitting on the other side, has anyone considered writing a name switch
directory to integrate with keystone directly?  I was going to bring that
up at the design summit, my now declined talk made use of that
functionality.  I am working on a blog post with some demo code and I'll
toss that up with a more in depth description of the idea when I get it
together and have approval to post code.

But I'd like for people to roll that around in their heads.

-Matt

On Thu, Sep 27, 2012 at 10:55 AM, Adam Young <ayoung at redhat.com> 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<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<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 <OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120927/2112ab2b/attachment-0001.html>


More information about the OpenStack-dev mailing list