access control & roles & uuid's

Justin Harris jharris at redhat.com
Fri Mar 19 14:48:46 UTC 2010


----- "Dmitri Dolguikh" <ddolguik at redhat.com> wrote:

> We need both: role based access control and more granular form of
> access control.
> 
> An example of a simple role-based access:
> GET /owners/{owner_uuid} - shouldn't be accessoble to 'client' role,
> but should be available for 'owner'.

I think this is also more than strictly role based, you would only want
that owner to access the info, not any owner.

> 
> More granular access control, based on client or owner uuid:
> GET /consumers/{consumer_uuid}/entitlements - a 'consumer' can issue
> this call for themselves only, while 'owner' for any consumer (within
> the organization).

This slightly more complicated, because you are having to examine entity relationships,
as opposed to just checking if ids are equal - but I think this is the same class of access
control as the previous example.

> 
> While role-based access control is rather straightforward, the latter
> form of access control is much less so. I can think of two possible
> implementations.
> 
> url-based:
> - at the resource level;
> - have to specify role AND uuid (probably in the form of a url
> pattern)
> - relatively simple
> - something in the form:
> @Requires(role = Roles.CONSUMER, assertUUID =
> '/consumers/{uuid}/entitlements') // has to match uuid
> 
> the trouble: above url doesn't contain any references to the owner.
> Are we going to have a different url for 'owners'? If we are to keep
> the same url, then the implementation won't differ significantly from
> the next approach.

The url doesn't, but our database does (or user service or whatever).

> 
> entity-based
> - at the curator level
> - will have to have a way to relate to consumer & owner (it seems that
> it might not be that difficult - we have references to both on main
> entities)
> - something in the form: @RequiresConsumerRole, @RequiresOwnerRole
> - under the hood (assume GET /consumers/{consumer_uuid}/entitlements
> is being accessed) :
> 
> POST/DELETE Role.CONSUMER: extract consumer_uuid from the certificate,
> compare it with consumer.uuid on the entitlement
> GET Role.CONSUMER: extract consumer_uuid from the certificate, apply
> filter: where consumer.uuid = consumer_uuid
> or
> POST/DELETE Role.OWNER: extract owner_uuid from the user object,
> compare it with owner.uuid on the entitlement
> GET Role.OWNER: extract extract owner_uuid from the user object, apply
> filter: where owner.uuid = owner_uuid

I still feel funny about a given resource url resulting in different results
based on who is asking.  My inital thought on this was to have a similar setup
to what you proposed for the curators, but on the resources.  The main difference
being that instead of applying filters to a query, it simply allows access or 403s.

> 
> 
> Thoughts? Comments?
> -d
> 
> 
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin



More information about the candlepin mailing list