<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/05/2014 04:49 AM, Marco Fargetta
wrote:<br>
</div>
<blockquote
cite="mid:20140905084932.GA4062@sonny.areagrid.ct.infn.it"
type="cite">
<pre wrap="">Hi,
I am wondering if the solution I was trying to sketch with the spec
<a class="moz-txt-link-rfc2396E" href="https://review.openstack.org/#/c/96867/13">"https://review.openstack.org/#/c/96867/13"</a> is not easier to implement
and manage then the steps highlated till n.2. Maybe, the spec is not
yet there and should be improved (I will abandon or move to Kilo as
Marek suggest) but the overall schema I think it is better then try to
complicate the communication between Horizon and Keystone, IMHO.</pre>
</blockquote>
That is a very well written, detailed spec. I'm impressed.<br>
<br>
The S4U2Proxy/Step one stuff will be ready to go as soon as I drop
off the Net for a while and clean up my patches. But that doesn't
address the Federation issue.<br>
<br>
The Javascript approach is, I think, simpler and better than using
OAUTH2 as you specify, as it is the direction that Horizon is going
anyway: A single page App, Javascript driven, talking direct to all
the Remote Services.<br>
<br>
I want to limit the number of services that get tokens. I want to
limit the scope of those tokens as much as possible. Keeping
passwords out of Horizon is just the first step to this goal.<br>
<br>
<br>
As I see it Keystone tokens and the OAUTH* protocols are both ways
of doing distributed single sign on and delegation of privileges.
However, Keystone specifies data that is relevant to OpenStack, and
OAUTH is necessarily format agnostic. Using a different mechanism
punts on the hard decisions and rewrites the easy ones.<br>
<br>
Yes, I wish we had started with OAUTH way back a couple years ago,
but I can't say it is so compelling that we should do it now.<br>
<br>
<blockquote
cite="mid:20140905084932.GA4062@sonny.areagrid.ct.infn.it"
type="cite">
<pre wrap="">
Step 3 is a different story and it needs more evaluation of the
possible scenarios opened.
Cheers,
Marco
On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote:
</pre>
<blockquote type="cite">
<pre wrap="">While the Keystone team has made pretty good strides toward
Federation for getting a Keystone token, we do not yet have a
complete story for Horizon. The same is true about Kerberos. I've
been working on this, and I want to inform the people that are
interested in the approach, as well as get some feedback.
My first priority has been Kerberos. I have a proof of concept of
this working, but the amount of hacking I had to
Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A
few discussions today have moved things such that I think I can
clean up the approach.
Phase 1. DOA should be able to tell whether to use password or
Kerberos in order to get a token from Keystone based on an variable
set by the Apache web server; mod_auth_kerb will set
request.META['KRB5CCNAME']
only in the kerberos case. If it gets this variable, DOA will only
do Kerberos. If it does not, it will only do password. There will
be no fallback from Kerberos to password; this is enforced by
mod_auth_kerb, not something we can easily hack around in Django.
That gets us Kerberos, but not Federation. Most of the code changes
are common with what follows after:
Phase 1.5. Add an optional field to the password auth page that
allows a user to log in with a token instead of userid/password.
This can be a hidden field by default if we really want. DOA now
needs to be able to validate a token. Since Horizon only cares
about the hashed version of the tokens anyway, we only to Online
lookup, not PKI token validation. In the successful response,
Keystone will to return the properly hashed (SHA256 for example) of
the PKI tokens for Horizon to cache.
Phase 2. Use AJAX to get a token from Keystone instead of sending
the credentials to the client. Then pass that token to Horizon in
order to login. This implies that Keystone has set up CORS support.
This will open the door for Federation. While it will provide a
different path to Kerberos than the stage 1, I think both are
valuable approaches and will serve different use cases. This
Phase 3. Never send your token to Horizon. In this world, the
browser, with full CORS support, makes AJAX calls direct to Nova,
Glance, and all other services.
Yep, this should be a cross project session for the summit.
_______________________________________________
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>
<pre wrap="">
</pre>
<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>