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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
