Open Stack

On Thu, 2014-09-04 at 17:37 -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.

So it was brought up briefly in Atlanta that keystone should provide a
way to discover the available auth mechanisms. This would mean to me for
example: 

1. a GET /auth/methods or just GET /auth which would include a list of
the methods for retrieving a token. (or just jsonhome entries)
2. a GET /OS-FEDERATION/idp that would list the available federated
IDPs. (or just jsonhome entries)

Horizon would then be able to do a similar thing to web services with
'login using your google id' or with user/pass and do some sensible
things based on what is allowed, or if it is receiving a kerberos ticket
and kerberos is one of the allowed methods then bypass all this stuff.

If we did this wouldn't most of 'use CORS/AJAX/kerberos/whatever' be on
a case by case basis? 

I don't know Horizon or the DOA very well at all so just let me know if
i've picked up on completely the wrong things here. 


Jamie

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev