Open Stack

On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:
> On 27 June 2013 04:55, Adam Young <ayoung at redhat.com> wrote:
> > Right now Keystone provides so called bearer tokens: This means that whoever
> > has a token can do whatever the token entitles him to do. If I
> > manage to get somebody's token I can do whatever this person is able to do.
> > To fix it, the other services that use tokens to:
> >
> > 1. Authenticate the identity
> > 2. Match the name in the token to the  identity that authenticated the
> > connection.
> 
> I am confused: HTTP is a message orientated protocol, connection based
> authentication is a terrible antipattern. Do you really mean
> 'connection' here?

More the HTTPs handshake i guess, the point is to have for example a
client certificate or kerberos identity that is used to connect to the
individual servers.

When a token is generated from keystone we put into the token a
reference to the kerberos or cert that was used to generate the token,
then when this token is used on a server the auth_token middleware
ensures that the same kerberos principal or certificate is used to make
that connection as made the original. That means even if you get the
token unless you have the cert/kerberos id you can't use it. 

The full blueprint is:
https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token

> > If the names match then you can be sure that the user that connected to the
> > service and presented a token is the same user that acquired the token from
> > keystone in the first place.
> 
> That would prevent the use case of 'create a token and hand it off'
> which AIUI Heat depends on/will depend on.

Yes it would, but this is where heat would need to make use of the
trusts mechanism that was released with Grizzly, something that i
understand is planned anyway. 

> > To make this happen we need to add authentication to the connections between
> > clients and services.
> 
> Again, if you mean actual TCP Connection here then this design is deeply flawed.
> 
> Whats the actual problem we're trying to solve (vs this proposed solution).
> 
> -Rob
>