Open Stack

Excerpts from Adam Young's message of 2014-04-04 18:48:40 -0700:
> On 04/04/2014 02:46 PM, Clint Byrum wrote:
> > Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700:
> >> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624
> >>
> >> I still have concerns though about the design approach of creating a new
> >> project for every stack and new users for every resource.
> >>
> >> If I provision 1000 patterns a day with an average of 10 resources per
> >> pattern, you're looking at 10,000 users per day. How can that scale?
> >>
> > If that can't scale, then keystone is not viable at all. I like to think
> > we can scale keystone to the many millions of users level.
> >
> >> How can we ensure that all stale projects and users are cleaned up as
> >> instances are destroy? When users choose to go through horizon or nova to
> >> tear down instances, what cleans up the project & users associated with
> >> that heat stack?
> >>
> > So, they created these things via Heat, but have now left the dangling
> > references in Heat, and expect things to work properly?
> >
> > If they create it via Heat, they need to delete it via Heat.
> >
> >> Keystone defines the notion of tokens to support authentication, why
> >> doesn't the design provision and store a token for the stack and its
> >> equivalent management?
> >>
> > Tokens are _authentication_, not _authorization_.
> 
> Tokens are authorization, not authentication.  For Authentication you 
> should be using a real cryptographically secure authentication 
> mechanism:  either Kerberos or X509.
> 

Indeed, I may have used the terms incorrectly.

Unless I'm mistaken, a token is valid wherever it is presented. It is
simply proving that you authenticated yourself to keystone and that you
have xyz roles.

Perhaps the roles are "authorization". But those roles aren't scoped to
a token, they're scoped to a user, so it still remains that it serves
as authentication for what you have and what you're authorized to do as
a whole user.

That is why I suggest OAUTH, because that is a scheme which offers
tokens with limited scope. We kind of have the same thing with trusts,
but that also doesn't really offer the kind of isolation what we want,
nor does it really offer advantages over user-per-deployment.