Open Stack

On Wed, Mar 02, 2011 at 05:07:04AM -0600, Michael Barton wrote:
> > Swift
> >
> > Swift has the concept of accounts, users, and groups. An account
> > contains users, and a user can belong to groups. Accounts names have an
> > abstraction layer, so while you may login with account "example.com",
> > the account name used within swift is a UUID with a prefix.
> >
> > By default, a user belongs to a group for the user "user:account"
> > and a group for the account "account". The other group names can
> > be arbitrary strings, so they may be other account names, users,
> > or some application-specific term.
> >
> > All operations are done in the context of a user and account. A user
> > may not be a member of the account it's acting on since resources
> > can specify ACLs, this is especially true for public resources (where
> > user is undefined or anonymous).
> 
> 
> To be clear, users in swift are entirely a function of the auth
> middleware.  Once you get past middleware, swift only has a concept of
> accounts, which are designated in the URL.  The middleware decides
> whether or not you have access to that account based on info in the
> request (or combined with metadata stored in swift, which is how ACLs
> are implemented).
> 
> The Cloud Files installation, for example, has no concept of multiple
> users in an account, because its authentication system doesn't.

Thanks for the clarification. Perhaps I should restate my proposal
in terms of 'accounts' instead of 'entities', as this already maps
closely to what Swift does.

-Eric