On Tue, Jun 14, 2011 at 4:21 PM, James Bowes <jbowes(a)redhat.com> 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?
We use that class to figure out how to look up the entity in question,
so we'd have to tokenize it to split the parts, map the string to a
class somewhere else, probably makes more sense to just keep them both
separate.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca