<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/27/2012 02:03 PM, Matt Joyce
wrote:<br>
</div>
<blockquote
cite="mid:CAGYSk8ccCJPc5H1AfTAiAejq07d+1h8ncAYYRhEq0MwLCAigNw@mail.gmail.com"
type="cite">Actually, have you considered SASL?<br>
<br>
That might be far superior to PAM.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAGYSk8ccCJPc5H1AfTAiAejq07d+1h8ncAYYRhEq0MwLCAigNw@mail.gmail.com"
type="cite"><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>
</blockquote>
<br>
Declined? What was the talk?<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAGYSk8ccCJPc5H1AfTAiAejq07d+1h8ncAYYRhEq0MwLCAigNw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://blueprints.launchpad.net/keystone/+spec/sql-identiy-pam"
target="_blank">https://blueprints.launchpad.net/keystone/+spec/sql-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 moz-do-not-send="true"
href="http://docs.openstack.org/developer/keystone/keystone.identity.html#module-keystone.identity.core"
target="_blank">http://docs.openstack.org/developer/keystone/keystone.identity.html#module-keystone.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
moz-do-not-send="true"
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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>