----- "Dmitri Dolguikh" ddolguik@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 10-03-19 11:48 AM, Justin Harris wrote:
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.
hmm. I don't think I follow you. Let's consider
GET /consumers
And let's assume that the caller has 'owner' (or owner-admin in bryan's taxonomy of roles) role. We don't have owner uuid in the url, but the request is valid. We can't return a 403; instead we should return all consumers in the owner's organization.
Unless we create a management-client-specific methods (for the example above: GET /owners/{owner_uuid}/consumers) I don't see any other way around it.
-d
----- "Dmitri Dolguikh" dmitri@redhat.com wrote:
On 10-03-19 11:48 AM, Justin Harris wrote:
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.
hmm. I don't think I follow you. Let's consider
GET /consumers
And let's assume that the caller has 'owner' (or owner-admin in bryan's taxonomy of roles) role. We don't have owner uuid in the url, but the
request is valid. We can't return a 403; instead we should return all
consumers in the owner's organization.
Unless we create a management-client-specific methods (for the example
above: GET /owners/{owner_uuid}/consumers) I don't see any other way around it.\
Yeah so this actually goes back to the collections thing. I think that for REST this is interpreted as "all consumers in the system", which IMO should only be available to the super-user (or whatever we call it) role. The way to get a collection of consumers under an owner is, like you said: GET /owners/4/consumers - these are the consumers under this owner, and I think that the URL conveys that.
- Justin
-d _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 10-03-19 12:57 PM, Justin Harris wrote:
----- "Dmitri Dolguikh"dmitri@redhat.com wrote:
On 10-03-19 11:48 AM, Justin Harris wrote:
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.
hmm. I don't think I follow you. Let's consider
GET /consumers
And let's assume that the caller has 'owner' (or owner-admin in bryan's taxonomy of roles) role. We don't have owner uuid in the url, but the
request is valid. We can't return a 403; instead we should return all
consumers in the owner's organization.
Unless we create a management-client-specific methods (for the example
above: GET /owners/{owner_uuid}/consumers) I don't see any other way around it.\
Yeah so this actually goes back to the collections thing. I think that for REST this is interpreted as "all consumers in the system", which IMO should only be available to the super-user (or whatever we call it) role. The way to get a collection of consumers under an owner is, like you said: GET /owners/4/consumers - these are the consumers under this owner, and I think that the URL conveys that.
- Justin
Agreed. So is it how we want to approach this? I'm not sure if this is an issue in our case, but I would like to avoid the situation when the client has to be specifically coded for a particular role. We have at least another role owner_admin, which means:
we still need: GET /owners/4/consumers (super_admin has access to any owner_uuid) but also: GET /owners (returns all owners in the system - only super_admin has access to this one)
-d
candlepin@lists.fedorahosted.org