Need a permou -> role mapping?
That way when createSession is called (#2) a list of ‘candidate' roles may be
passed in.
Req’s adding the list of candidate roles to your application's cache which
would be the list of all roles valid for that ou. The easiest answer is if you
already have that list available, perhaps it’s needed elsewhere.
If that list cannot be maintained by you we could consider adding a new api to
the review mgr:
List<String> permissionRoles( OrgUnit permOu )
throws SecurityException;
This new api req’s that the ou is ‘pushed’ down from its parent, permobj.
Need to think about the implications of that. First, the perm entity now
carries an ou attribute. Perhaps that can be accomplished during the create by
reading the parent’s ou value. But if the parent ever changes its ou, possible
on updates, it would have to push the new ou down to its children.
Not too bad, but there may be other hidden difficulties.
Another idea is to move the ou from permobj to the perm entity altogether, but
that would impact other arbac funcs. Maybe for the good, but need to kick that
idea around some more.
Shawn
> On Oct 9, 2016, at 7:58 AM, Chris Pike <[email protected]> wrote:
>
> With the addition of the ABAC / Role Constraint, this is the plan for how
> each of our applications will check permissions
>
> 1. Application starts up and registers all of it's permissions into an
> application specific Perm-OU
> 2. When a user makes a request, the application gets all the session user
> roles (AccessMgr.sessionRoles). Because of role constraints, can't use
> sessionPermissions.
> 3. For each role found, it finds the permissions (ReviewMgr.rolePermissions).
> 4. If necessary, it find the permission attribute sets for each permission
> (ReviewMgr.readPermAttributeSet)
> 5. The permissions are part of the application's request context, so every
> check can be done internally, don't need to make a call to fortress.
>
> There will be caching, so this flow doesn't need done on every request. We
> will have many applications, so in Step #2, lots of roles will be returned,
> most of which are not relevant to the application since they don't contain
> any permissions in the application's Perm-OU. My questions was directed at
> seeing if there was a way to make this process more efficient.
>
>
>
> ----- Original Message -----
> From: "Shawn McKinney" <[email protected]>
> To: [email protected]
> Sent: Sunday, October 9, 2016 8:16:02 AM
> Subject: Re: Access Manager Role Filtering
>
> Chris, not exactly sure what you mean. Please elaborate with a sample use
> case and data. If it worked the way you wanted, what would the API be?
>
>
>> On Oct 8, 2016, at 11:22 AM, Chris Pike <[email protected]> wrote:
>>
>> Shawn,
>>
>> Would there be any way to efficiently get all session roles that only
>> contain permissions in a specified permission OU?
>>
>> Thanks,
>>
>> ~Chris
>>
