access control & roles & uuid's

Justin Harris jharris at redhat.com
Tue Mar 23 14:59:18 UTC 2010


----- "Adam Young" <ayoung at redhat.com> wrote:

> On 03/19/2010 11:51 AM, Dmitri Dolguikh wrote:
> > 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.
> >>      
> REST implies the use of Hyperlinks, which we do not currently use.
> 
> A solution using Hyperlinks would be
> 
> 1)  A user needs a certain priviledge in order to enumerate pools from
> 
> /candlepin/pools, otherwise they get rejected 403 418 whatever..
> 
> 2) A user can read any pool that they have privs on via a direct url 
> /canlde/pools/abcd-1234....
> 
> 3)  A user gets a list of their pools from their own entry or from
> their 
> groups.    This list is just a list of hyperlinks.
> 
> In general, the rule is the object falls underneath the owning 
> collection.  To Point back up the tree, or across the tree, use 
> hyperlinks.  Enumeration of a collection implies a permission to do
> so.

+1000 to this.  I'm glad someone else is thinking along these lines...


> 
> 
> >> 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
> >>>
> >>>
> >>>
> >>>        
> >>
> >>
> >>      
> > _______________________________________________
> > candlepin mailing list
> > candlepin at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/candlepin
> >    
> 
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin



More information about the candlepin mailing list