On Tue, Jun 14, 2011 at 4:34 PM, Bryan Kearney <bkearney(a)redhat.com> wrote:
On 06/14/2011 03:21 PM, James Bowes wrote:
> On Tue, Jun 14, 2011 at 03:14:41PM -0300, Devan Goodwin wrote:
>> The problem, consumer principals need to access sub-sets of owner
>> information, such as:
>>
>> GET /pools?owner={id}
>> GET /owners/{key}/pools
>>
>> In each case, GET implies we need READ_ONLY, and the only parameter we
>> have to verify on is an owner. So I added an implicit READ_ONLY
>> permission for an Owner to all ConsumerPrincipals.
>>
>> This however now means a whole bunch of GET methods in the API which
>> verify access to an owner will now be available. A consumer principal
>> can now view info on other consumers in that owner, or history on the
>> entire owner. This is a problem, if for instance a system was
>> compromised, and that identity certificate could now be used to gather
>> some information on the rest of the organization.
>>
>> My proposal is to add optional 'tags' to the security we're
checking,
>> something akin to: @Verify(Owner.class, tag="pools"), which means we
>> check for any permission which responds to those parameters. A
>> permission with no tags will be assumed to provide any tags requested.
>> If the permission does carry tags, it will only respond if it has the
>> tag in question. If no tag is requested, then only permissions with no
>> tags will respond.
>>
>> Not super pretty, but solves a real problem.
>>
>> Thoughts?
>
> How about changing the annotation to @Verify("owner")
> and @Verify("owner.pools")?
>
> What do other apps using similar security models do in this case?
>
Katello is doing something akin to this. The only wierd thing is that
there is a nested hierarhcy here... which is owner.pool. what are all
the tags we have now?
This is the only example so far. We hit something similar yesterday,
the consumer export URL which was previously not accessible to the
consumer themselves. We solved that by reasoning it's probably ok for
them to be able to hit that URL. That couldn't really be solved by
this however because it's an inverse problem, we want to give consumer
principals access to all the normal consumer URLs except this one. In
the case above we want to give access to just one Owner URL.
Something's missing here, we need a way to get more fine grained
control over the methods beyond just @Verify'ing a URL path parm and
assuming an access type via the @GET @PUT @POST @DELETE annotations.
Will think some more on this today.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca