Open Stack

Hi,

I am wondering if the solution I was trying to sketch with the spec
"https://review.openstack.org/#/c/96867/13" 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.

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:
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5483 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140905/e6fa494b/attachment.bin>