[openstack-dev] [keysstone] External authentication

Dolph Mathews dolph.mathews at gmail.com
Thu Sep 27 18:26:12 UTC 2012

On Thu, Sep 27, 2012 at 7:24 AM, boden <boden at linux.vnet.ibm.com> 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
> 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.
> 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).
> 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.

I've thought about this, specifically for the v3 API. In keystone.conf, I
would simply require a list of callables that accept details of the auth
request. Callables that accept username+password and existing tokens should
be provided out of the box.

For example, iterate through the list of callable authentication modules
until one either returns successfully, or returns False (indicating that
perhaps the user authenticated successfully, but the account is otherwise

    for authenticate in authentication_callables:
            return authenticate(**credentials)
        except exception.ValidationError:
            # module does not support these credentials
        # authentication method not recognized
        return False

> * 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.

Context, yes. But why the full body? There's only certain attributes in the
request body that would be applicable. What are you interested
in, specifically?

> * 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.

+1. In my v3 implementation (see pending reviews on the feature/keyston-v3
branch) all internal API's are passed to every controller on __init__ --
authentication modules could be initialized in basically the same way.

> * 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.

How about extracting authentication from the drivers (they're largely
similar), and instead making even username+password and token credentials
configurable authentication callables in keystone.conf (and providing them
out of the box as the two default, of course)?

> 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
> >   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120927/e26e7928/attachment.html>

More information about the OpenStack-dev mailing list