openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

Hi Jorge,

Thanks for the detailed description, and sorry for the delayed
response, I was at a conference this week. This clears up the
terminology, but I guess I'm still not seeing what this really gives
use (specifically resource groups). It seems overly complicated,
but I'm probably just missing something. More below:

On Mon, Apr 11, 2011 at 04:04:44PM +0000, Jorge Williams wrote:
> In use case #2, permissions are instead assigned to a "refresh" token (see OAuth 2 spec).  This token (T[1]) is offered to M and is used (after it's traded in for an access token) to get access to resources.
> 
> T[1] -> {P[4], P[5], P[6], P[7]}
> 
> Why not simply create a group for Company M and assign permissions to that group?  We could do this, but it turns out that's not very useful for M.  From Company M's perspective, when working on your account, getting a list of servers should return only the servers that you've given them access to. They should not see instances that belong to other customers etc.  This simplifies their code a lot. M doesn't need to necessarily  sort out whom resources belong to -- instead they need only keep track of who each token belongs to.  Also tokens allow us to  keep track of "on behave of" which works out great for billing.

If we did use a group for Company M, why would the group able to see
resources it doesn't have access to? It seems that when Company M logs
in it would only see resources it is supposed to manage, and can get
details to see who actually owns each resource only if it is important
to the tool. As for "on behalf of", it seems that this is always going
to be the Company M group since this is the authenticated user. It may
have permissions to manage instances owned by other groups/users/etc,
and if this service needed to start new instances, you could specify
who the owner would be too (for example, POST /group_b/servers/
instead of /company_m_group/servers/).

To me it seems just using a group is sufficient, but perhaps you can
explain a bit further.

> Note that we're not planning on assigning privileges to users directly.  Instead when a user is created it's assigned a refresh token like M is.  Privileges are assigned to that token.  User's may themselves enter into delegation which means that there may be several tokens assigned to a single user.  When the user launches an operation their set of permissions is the sum of all of the permissions associated with their refresh token PLUS the set of permissions  associated with each group the user belongs to. 

Why is there a need for this extra level of indirection? Wouldn't a
simple (user, perms) list provide the same functionality? The perms
can be stored in both the AuthZ service and overridden per resource
(stored in the resource record) to give fine grained control. This
means we wouldn't need to store and manage an extra token objects
for every service/zone.

> Up until now, I haven't discussed resource groups.  Resource groups are used to help define a permission (P[x]).  We say that a permission is a capability (C[x]), such as "reboot", "create server",  plus a set of Resource Group IDs (RGID[x]) -- these IDs must be globally unique.
> 
> P[1] = { C[1], {RGID[1], RGID[2],  RGID[3]}}
> 
> As Sandy has described, each service (or Zone in nova) is responsible for maintaining the group of resources associated with the ID.  These groups are created and managed by users as part of the delegation process.  The same resource group ID can be used to combine resources from multiple zones or services.  For example, RGID 0x19a8c73  may be associated with instance 5 and 6 in Zone 1 and instance 10 in Zone 2 and with Load balancer 8 in the load balancing service.  The logical resource group contains all of those resources, but all Zone 1 knows is that 5, 6 are associated with 0x19a8c73.  And that's all it needs to know, when a requests comes in, Zone 1 validates the token and asks for all permissions that are associated with it (that is the sum of token and group permissions) -- the service may ask to narrow the set of permissions it gets to only those that make sense to compute.  Then Zone 1 checks the capability with the operation and makes sure that the instance is a member of one of the RGIDs.

Hmm, so this is another level of indirection? What problem is this
trying to solve exactly? Why wouldn't the resources just contain
user/group lists on them directly like swift does?

If I understand correctly, this means we would have the following
layers:

user/group -> refresh token -> resource group -> resources

I think I get what you are proposing, I'm just not understanding why
these extra layers are needed.

Thanks in advance for further explanation. :)

-Eric