Open Stack

Hi Matt

the content of authz tokens (because this is what you are really talking 
about isnt it?) is a well trodden path and there is a lot of expertise 
in this area. Conceptually an authz token should contain

- the id of the user (there are various forms of this used by different 
token formats, including LDPAP DNs, SAML PIds, public key, X.509 PKC 
issuer and serial number etc.) Pick your favourite
- the authz attributes of the user (this includes many properties such 
as roles, identity attributes, level of assurance (LoA) to link back to 
authn etc.)
- policy constraints of the token issuer (anything which limits where 
and how the token can be used, such as time constraints, service 
constraints, location constraints, delegation constraints etc.)

If a flexible extensible format is defined for tokens, which allows new 
authz attributes and policy constraints to be added in the future, then 
the API should not need to change again. ever. X.509v3 PKCs are a good 
example of an extensible token format that has not needed to change 
since they were conceived in 1993. (v1 in 1988, v2 in 1992 and v3 in 
1993 if I remember correctly). So 20 years for a format without change, 
considering the ubiquity and scope of usage, is pretty good going. X.509 
ACs have a similar format for authz as X.509 PKCs for authn

regards

David


On 24/01/2013 23:37, 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 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>