access control & roles & uuid's

Dmitri Dolguikh dmitri at redhat.com
Fri Mar 19 15:51:32 UTC 2010


heh heh. Devan offers a real-world example of the situation i described 
earlier.
-d

On 10-03-19 12:49 PM, Devan Goodwin wrote:
> Trying to make sense of this all, but here's a potentially unfriendly
> scenario that may influence which way you go,
>
> consider /pools with optional ?consumer=BLAH
>
> Pools don't belong to any consumer so you can't do any "where
> consumer_uuid" filtering. If a consumer requests /pools I don't know
> if they should get refused or just see all pools filtered by their
> owner.
>
> If they hit /pools?consumer={myuuid} they're getting a list of all
> pools that are useful to them, i.e. the rules check should pass if
> they asked for an entitlement from those.
>
> Meanwhile if an owner admin hits /pools they should obviously see all
> pools for  themselves, and if a superuser hits /pools they should see
> all pools for all owners.
>
> Honestly I'm having a hard time piecing together how any of these
> strategies would work to cover all scenarios if we're using just one
> set of URLs, but I wanted to pitch that example anyhow to see if it
> helps clarify the best approach.
>
> Devan
>
> On Fri, Mar 19, 2010 at 10:34 AM, 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'.
>>
>> 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).
>>
>> 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.
>>
>> 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
>>
>>
>> Thoughts? Comments?
>> -d
>>
>>
>> _______________________________________________
>> candlepin mailing list
>> candlepin at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
>>
>>      
>
>
>    




More information about the candlepin mailing list