Open Stack

A thought about tokens and cloud
=========================

Below is a quick thought I've been mulling over on and off in my free
time.   It relates to how we build authentication structures for use inside
of the cloud.


The Dream
========

Imagine if you will an alternate future:

I spin up an instance on my openstack cloud.  I do NOT inject a key.  I
instead try to log in directly using my keystone credentials ( whatever
they may be, maybe two factor? ).  This means that cloud providers can cut
perms on running instances remotely with simple changes to keystone or
backend authentication systems.  They can also allow users to begin to
login to systems they previously did not have access to without sharing
keys or injecting anything into those instances.  In short this gets us non
suck ACL control on instances from keystone.

Some folks will point out this is not cross cloud friendly.  It's totally
not.  And maybe IAM is the solution for that.  But maybe we'll need this
for real IAM support.

The history
========

A long while back I tried to build pam authentication services for
keystone.  This was a great idea that resulted in terrible failure.

The fundamental problem I ran into basically stems from all ssh clients
wanting to perform an getpwnam() on a user requesting to authenticate
BEFORE handing auth creds off to PAM.

In short, if the instance can't query by user name for posix schema
information ( uid, gid, home_dir, etc ) BEFORE any authentication query can
occur the authentication will fail.  And there is just no way around that
without modifying the way ssh works.  Which is probably never going to
happen as the radius folks have tried and failed for years to do so.

So what we need is an NSS ( Name Switch Service ) access to keystone.

I mean sure,  if you backend to LDAP and allow anonymous read queries from
your instance network space, you can just use the nss module to ldap.
However that's not very portable between openstack clouds.  And it means
building administrative utilities for LDAP in addition to openstack.

But the problem becomes more fundamental when you consider the issue....

The problem
=========

This got me to thinking about the fundamental nature of cloud instances and
performing any sort of elevated permissions query or unauthenticated query
to our APIs.  We need a service ticket functionality but we can't protect
anything we place on instances.

However instances can be fully qualified as part of the cloud.  You can in
effect tie a token to an instance and ensure that when the token is used
it's being used on an instance it's intended for.  Do we want that?  What
does it get us REALLY?

Then there's single use tokens...  do they get used once and die?  do they
only allow for a reduced set of queries?  can there bet a getpwnam only
token?

In effect the issue we face is a very complex one.  I don't think we should
try to solve every problem, but we will want a token structure that is
flexible as we can possibly make it.  Because there's a good chance we'll
end up running in a few different directions before we settle on something
we like.  And I don't want use to be revisiting token structure in v4 api.

Token Structure
============

looking at the straw man...

{
user : { id,  other user specific attributes },
domain : {id},
project : { roles [role ids]},
auth_mechanisms[],
services:[
    compute: [https://nova/endpoint],
    identity: [https://keystone/endpoint],
...
]
}

We'll want for the user attributes to be expandable to include things like
posix schema... or windows domain schema... or who knows.

Domain ID works for me... but I am a fan of comment fields that can be NULL
but also be there in case someone  wants to send some extra info down the
line.

projects...  an interesting question.

I think the multiple token spanning token is... interesting.  I think roles
could be an answer for some of the ACL control for a token... but i have
not trodden that path yet.

projects : [{ id: id1, roles [role1, role2]}, { id: id2, roles [role1,
role3]},

service identifiers are great.  again you may want to make internal vs
public url tokens that are idenfitied as such on the backend... with a
quick identifier on the front end just to let you know they are?

I think also on the backend allowing a token to be reserved for use with a
specific instance id and a means to verify that instance id is the query
origin.

I think that matters.

Also the question for external queries becomes an issue.  What happens when
i need to make a query from outside to the publicurl by nest some internal
query structure?  No idea if we'd ever need to... but it's good to leave an
area to plug something in if we need it.


Conclusion
========

I don't have one.

Just a few thoughts.  And I think they can help.

-Matt



On Thu, Jan 24, 2013 at 7:03 AM, Adam Young <ayoung at redhat.com> wrote:

> On 01/24/2013 04:06 AM, David Chadwick wrote:
>
>>
>>
>> On 24/01/2013 00:50, Adam Young wrote:
>>
>>>
>>>> By the way, introducing holder of key into tokens solves the bearer
>>>> problem and does not require SSL/TLS. What it requires is simply that
>>>> the client signs the message containing the token with the key and
>>>> includes a nonce/timestamp in the signed message so that the recipient
>>>> can validate that the user is the holder of the token and the token
>>>> has not been replayed.
>>>>
>>> Are you saying that the whole web requests would then be signed? Yes,
>>> that would work, and would be very effecient, but it would require
>>> extending all of the HTML aware parts to allow for signatures. I think
>>> that would be a  very valuable extension.
>>>
>>
>> The body of the POST needs to be signed. This does not stop a MITM, but
>> then neither does SSL if you have a forged cert in the name of the sender.
>>
>> David
>>
>
> Just thinking this through:
>
> Keystone still is the authority on keys and signing, so I think this might
> actually prevent a man-in-the-middle attack.  The key signed in the token
> is the one used to sign the message.  The token is signed by the keystone
> server.  The token is authenticated against keystone.   So a man in the
> middle either has to try to use the secret key associated with the public
> key from the token, which they won't have access to, or they have to inject
> their own key.
>
> If they inject their own key, they need to get a new token.  Which means
> they would need to convince Keystone that they are the original user, and
> that keystone should sign a different key.  That is a pretty high barrier
> to overcome.
>
>
> Am I missing something?
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130124/ff20d620/attachment.html>