Open Stack

On 09/27/2012 04: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?


Yes, I have, but you are aehad of me.  Please post your patch.  It is 
the right approach.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev