Open Stack

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?