Must have forgot to attach, trying again
As far as the client is concerned, here is a simple example
1. For the ftRC constraint value, we store a JSON object like
{
"constraints": [
{
"attribute-name": "owner",
"operator": "equals",
"value": {
"value": "chris",
"type": "STRING"
}
}]
}
2. Our client reads that value and converts it into an MVEL expressions for
each permission like
perm:account.read?owner=="chris"
3. When we need to do a permission check, we have do a coarse grained check
with an annotation and a fine grained check that runs an MVEL test on the
applicable permissions to see if any pass
@RequiresPermissions("account.read")
public Account getAccount(String id) {
Account account = getAccount(id);
Map<String, Object> vars = new HashMap<String, Object>();
vars.put("owner", account.getOwner());
securityUtil.doesUserHavePermission("account.read", "account.read.paset",
vars);
}
This become more complicated when you factor in any permissions, self
permissions, default constraints, listing accounts, etc...
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Thursday, September 15, 2016 4:23:20 PM
Subject: Re: Fortress Filter Constraints Implemented
> On Sep 15, 2016, at 2:35 PM, Chris Pike <[email protected]> wrote:
>
> No README... but I attached a simple diagram. Basically, fortress stores the
> permission attribute sets, permission attributes, and role constraints that
> tie user role assignments to a permission attribute set. However, fortress
> doesn't enforce the any of these "FILTER" ftRCs, that is the responsibility
> of the client.
Chris, where did you attach the diagram?
The client is what I’m interested in. If it’s a useful policy enforcement
pattern for penn state it may be to others.
Shawn
