Open Stack

On 09/05/2014 04:49 AM, Marco Fargetta wrote:
> 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.
That is a very well written, detailed spec.  I'm impressed.

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.

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.

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.


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.

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140905/4a9193aa/attachment.html>