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