Open Stack

On 06/27/2013 10:45 PM, Simo Sorce wrote:
> On Thu, 2013-06-27 at 17:49 -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.
> Using a private key to sign requests is certainly an option that is
> certainly to be considered.

It was  considered.  However, when you get down to the management of 
those keys, and how to sign the messages, it is no less complex than 
dealing with X509 Certificates, and X509 is already implemented.

X509 has a format for authentication information in a separate signed 
document from the initial certificate itself, but deployment of it is 
not very wide spread.  From our perspective, it makes more sense to 
continue to use Keystone tokens for authorization information, and link 
it to a secure Authentication source.  We are giving people the choice 
between X509 and Kerberos out the door, although any other secure 
authentication source would be viable as well.

>
> In order to do that thought it would be easier if all clients would use
> the same http library and keystone client so that signing can also be
> done mostly transparently to the clients by hooking into the http
> library and signing the request before it is sent.
>
> Simo.
>