This is good. Now can you describe the sequence of events during usage? For example:
1. createSession does these ops: a. readUser b. bind 2. sessionPermissions a. searchPermissions what changes within these sequences? No changes to accessmgr other than these two methods? Shawn > On Jan 28, 2016, at 9:29 AM, Chris Pike <[email protected]> wrote: > > Yes, it is easy to get lost, I'm on the IRC chat if you want to jump on, here > are basics of what I am proposing... > > > AdminManager - I have this coded on my branch minus the ftAttributeSet change > > + PermissionAttribute addPermissionAttribute( PermissionAttribute > permAttribute ) throws SecurityException; > - Create a new object "ftAttributeSet" object and add a the "ftPA" entry > to permission which would just have the name of the ftAttributeSet object > (i.e. ftPA=ATTRIBUTE_SET_NAME) > - Still need to add remove and update methods > + RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint > roleConstraint ) throws SecurityException; > - Adds a role constraint ftRC, to a User (i.e. > ftRC=ROLE_NAME$type$filter$ATTRIBUTE_SET_NAME$value) > - Still need to add remove and update methods > > Review Manager - I have the first method coded, not the second > > + Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean > noInhertiance ) throws SecurityException; > - Inspects all permissions for a given role and returns a set of > PermissionAttribute applicable to the role > + PermissionAttribute readPermissionAttribute( Permission permission ) > throws SecurityException; > - Returns the permission attribute for a given permission > > UserRole - I have this coded on my branch > > + private Set<RoleConstraint> roleConstraints; > - Any unloading of a role would populate this using the ftRC entries that > weren't temporal > > Permission - This is not coded yet > > + private String attributeSet; > - Any unloading of a permission would read the ftPA entry and populate > this field > > > > > > ----- Original Message ----- > From: "Shawn McKinney" <[email protected]> > To: [email protected] > Sent: Thursday, January 28, 2016 10:01:54 AM > Subject: Re: Fortress Constraints > >> On Jan 28, 2016, at 8:50 AM, Chris Pike <[email protected]> wrote: >> >> Every application could define several permission attributes, and since we >> plan on using this for many applications, it could become a large list. >> >> Our paradigm of use might be a slightly different than yours, so please >> correct me if I'm wrong, but is it fair to say we are mostly worried about >> adding extra read operations on the access manager operations not to the >> review and admin manager calls? Regardless of where the ftPA information is >> stored, it shouldn't affect access manager other than access manager reading >> the additional ftRC and ftPA attribute values. I don't think the >> sessionPermissions check would need to read the ftPA reference object. >> >> Also, couldn't the ftPAs be cached regardless of where they are stored? > > Correct, we must avoid adding extra ldap ops to the accessmgr apis. But we > also must be careful, reviewmgr methods are sometimes called during policy > enforcement too. > > Caching the entry is an option. But I may have lost the forest from the > trees. Can you (re)outline the approach, which apis to change, and how they > must be changed according to where you are right now? > > (If this gets tedious we can hop on IRC channel to discuss.) > > Shawn
