Open Stack

On Thu, Jun 27, 2013 at 05:49:00PM -0700, Clint Byrum wrote:
> On 2013-06-27 16:28, Jamie Lennox wrote:
> >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
> >
> 
> So you need the cert/kerberos ticket to both create and use the
> token. So this means you are really trying to solve the problem of
> us transmitting whole tokens for each request, making them open to
> interception during transmission or theft from backing storage.
> 
> >>>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.
> >
> 
> Indeed it is. But right now, the most excellent "make an EC2 keypair
> and sign stuff with it" scheme is working out pretty well. That
> scheme at least eliminates the transmission vulnerability.

We're getting pretty OT here, but since you mention it, I think we just
need a way to generate an ec2 keypair from a trust token, and ideally scope
that token to a specific endpoint.

Obviously long-term a keystone native way to sign requests would be great,
and could be used by Heat, and e.g Swift which has it's own method for
generating pre-signed URLs.

Steve