[openstack-dev] [keysstone] External authentication
Adam Young
ayoung at redhat.com
Thu Sep 27 19:23:45 UTC 2012
On 09/27/2012 02:03 PM, Matt Joyce wrote:
> Actually, have you considered SASL?
>
> That might be far superior to PAM.
I would say that we should make it possible to support anything that
is a standard mechanism. I would probably prioritize PAM above SASL in
order of implementation.
>
> 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.
Declined? What was the talk?
An identity plugin that allows you to fetch users and authenticate
against an external mechanism has come up several times, mostly in the
context of AD integration. I think getting something like that in needs
to be done fairly early in Grizzly.
>
> 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
> <mailto: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
>
>
> 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,
> 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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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/107cfe55/attachment-0001.html>
More information about the OpenStack-dev
mailing list