Actually, have you considered SASL?<br><br>That might be far superior to PAM.<br><br>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.<br>
<br>But I'd like for people to roll that around in their heads. <br><br>-Matt<br><br><div class="gmail_quote">On Thu, Sep 27, 2012 at 10:55 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/27/2012 08:24 AM, boden wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
I was recently looking into this same topic and came across the related<br>
blueprint: <a href="https://blueprints.launchpad.net/keystone/+spec/sql-identiy-pam" target="_blank">https://blueprints.launchpad.<u></u>net/keystone/+spec/sql-<u></u>identiy-pam</a><br>
</blockquote>
<br></div>
This is a little different.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have been trying to reach the blueprint author by email for a few days<br>
to understand if there has been any community interest in his blueprint,<br>
but no response from him yet.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
IMO PAM support in Keystone decoupled from the underlying Identity<br>
Driver would be a nice value-add. This would allow consumers to use PAM<br>
transparently across all concrete identity drivers (LDAP, SQL, etc.)<br>
opening the door for numerous authentication mechanisms (as you mentioned).<br>
</blockquote></div>
Agreed<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I recently implemented a prototype for PAM support in Keystone, and<br>
although similar to what you describe it appears to be more generic...<br>
<br>
Rather than going into the details of the design, let me state the core<br>
use cases that my prototype supports:<br>
* As a keystone admin, I want the ability to specify 1 or more<br>
authentication module classes in keystone.conf that can conditionally be<br>
used to authenticate a POST /tokens request in the keystone service.<br>
* As a keystone admin, I want to be able to use keystone PAM classes<br>
irrespective of the concrete identity driver type (SQL, LDAP, KVS, etc.).<br>
* As an keystone PAM developer, I want my module implementation to have<br>
access to the request body/header in the POST /tokens request so that I<br>
can get/put properties from/into it and also conditionally determine if<br>
my module is applicable for the current request.<br>
* As a keystone PAM developer, I want my module implementation to have a<br>
reference to the concrete identity driver being used so that I can<br>
interface with it as needed.<br>
* As a keystone admin, I want my concrete identity driver's<br>
authentication functionality used when no PAM classes are specified in<br>
keystone.conf (i.e. what we have today) or when none of the PAM classes<br>
are applicable to the given POST /tokens request.<br>
</blockquote>
<br></div>
Definitely write this up a blueprint.  We will replace the PAM one above with yours.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I realize the proper way to socialize this idea is via a blueprint.<br>
However given this idea encompasses the existing blueprint I linked<br>
above I was hoping to 1st sync up with the existing blueprint author.<br>
<br>
That said, I'm doing a little fishing here -- anyone have interest in<br>
this idea?<br>
<br>
Thx<br>
<br>
<br>
On 9/27/2012 4:15 AM, Ralf Haferkamp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 25, 2012 at 04:06:36PM -0700, heckj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ralf -<br>
<br>
Keystone supports this by having an internal API that allows you to write<br>
your own authentication backend for the various components. For this sort of<br>
use, I'd recommend writing your own backend for Identity that interacts with<br>
and translates from the back-end systems you're interested in using.<br>
</blockquote>
Hm, I am trying to implement this in a way that is independed of the identity<br>
backend that is actually used. And currently it is only meant to handle the<br>
authentication part. Information about which Users, Roles and Tenants are<br>
present is still handled by the existing Drivers. So implementing another<br>
Identity backend for this seemed wrong (if possible at all). Keystone, when<br>
configured for external Authentication, would just trust apache (or another<br>
entity external to keystone) for doing authentication and providing information<br>
about the authenticated user. This is I think very helpful to support things<br>
like Kerberos Authentication (or X.509 Client Certificates) which do not rely<br>
on the username/password scheme that "normal" keystone authentication currently<br>
requires.<br>
<br>
Currently I have implemented my prototype in this way:<br>
- implemented a wsgi.Middleware, that when added into keystone's<br>
   public-/admin_api pipelines, extracts apache's information about the<br>
   authenticated user from the Enviroment and adds that information to<br>
   keystone's request context.<br>
<br>
- in TokenControler.authenticate(), if the above information is present in the<br>
   context, I check if that user is present (and not disabled) in the currently<br>
   configured identitiy backend and issue a new token for that user. (That means<br>
   there's no need for any username/password to be present in the POSTed JSON<br>
   document)<br>
<br>
So this should really work independed of the identity backend that is in use<br>
and doesn't require the introduction of a new backend I think.<br>
<br>
regards,<br>
     Ralf<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chris Hoge at U Oregon did something very much like this with the UOregon SSO<br>
system (I heard about it at OSCON this past July).<br>
<br>
The relevant internal API for Identity is documented in<br>
<a href="http://docs.openstack.org/developer/keystone/keystone.identity.html#module-keystone.identity.core" target="_blank">http://docs.openstack.org/<u></u>developer/keystone/keystone.<u></u>identity.html#module-keystone.<u></u>identity.core</a>,<br>

and you can read the backends that implement that set of methods in<br>
keystone/identity/backends - kvs.py, sql.py, etc.<br>
<br>
- joe<br>
<br>
On Sep 25, 2012, at 2:20 AM, Ralf Haferkamp <<a href="mailto:rhafer@suse.de" target="_blank">rhafer@suse.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been thinking about adding support for External Authentication to<br>
keystone. By "External Authentication" I mean that e.g. when I run keystone<br>
behind apache it would be nice if I could just let apache handle the<br>
authentication (via mod_auth_kerb for example) and have keystone issue a Token<br>
based on the information that apache provides about the authenticated user<br>
(e.g. the username is usually passed via the REMOTE_USER env variable).<br>
<br>
I am currently wondering how the client should indicate to the server that<br>
External Auth should be used? One could add another parameter to the JSON doc<br>
that's POSTed during keystone authentication instead of the username/password<br>
tuple, but is that really needed or should keystone just check of the presence<br>
of specific ENV variables (e.g. REMOTE_USER as set by apache2) when external<br>
auth is enabled. In my current prototype implementation I do just that. What<br>
would be the preferable approach here?<br>
<br>
BTW, has anybody else been working on this already? Does this even sound like a<br>
feature worth adding?<br>
</blockquote></blockquote>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>