Open Stack

Wrote  really long answer to this, and then realized I missed the 
point.  Lets talk soon, ou raise some interesting ideas, but I have a 
lot of short term goals I need to get through before I can give you my 
undivided attention.

On 01/24/2013 06:37 PM, Matt Joyce wrote:
> 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 
> <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/1a8f825c/attachment.html>