Open Stack

I understand the general idea and the motivations but I am not sure
about the implementation. Even with a SPA you still need to provide
credentials and manage tokens for the authentication/authorisation in
a way not too much different from the current implementation.

Additionally, this might have some implications with the security since
you have to open the services to accept connection from clients everywhere.

Is there some schema/spec/pad/whatever describing this new approach for
Horizon and the other services?

Cheers,
Marco


On Fri, Sep 05, 2014 at 10:14:00AM -0400, Adam Young wrote:
> 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
> 

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


-- 
====================================================
Eng. Marco Fargetta, PhD
 
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy

EMail: Marco.Fargetta at ct.infn.it
====================================================

-------------- 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/ae89e2fa/attachment.bin>