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?
Devan
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?
Devan _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-James
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?
-- bk
On Tue, Jun 14, 2011 at 4:34 PM, Bryan Kearney bkearney@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.
On Tue, Jun 14, 2011 at 4:21 PM, James Bowes jbowes@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.
candlepin@lists.fedorahosted.org
-
Bryan Kearney -
Devan Goodwin -
James Bowes