[openstack-dev] [keysstone] External authentication
boden at linux.vnet.ibm.com
Fri Sep 28 13:29:35 UTC 2012
I wrote this up as a blueprint:
Direct link to the spec (wiki) for your convenience:
On 9/27/2012 1:55 PM, Adam Young wrote:
> On 09/27/2012 08:24 AM, boden wrote:
>> I was recently looking into this same topic and came across the related
> 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
>> 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
>> 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?
>> 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
>>>> 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
>>> backend that is actually used. And currently it is only meant to
>>> handle the
>>> authentication part. Information about which Users, Roles and Tenants
>>> present is still handled by the existing Drivers. So implementing
>>> Identity backend for this seemed wrong (if possible at all).
>>> Keystone, when
>>> configured for external Authentication, would just trust apache (or
>>> entity external to keystone) for doing authentication and providing
>>> about the authenticated user. This is I think very helpful to support
>>> like Kerberos Authentication (or X.509 Client Certificates) which do
>>> not rely
>>> on the username/password scheme that "normal" keystone authentication
>>> 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
>>> 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
>>> 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.
>>>> 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
>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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 mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev