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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
