Shwan, Here are the new methods I've added to the manager. I added documentation for each (https://github.com/PennState/directory-fortress-core-1/tree/feature/addPermAttrAndUserRoleConstraints). I started adding new unit tests, but they are not complete yet and I have some validation checks to add, but basic functionality is working.
AdminManager - RoleConstraint addRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException; - void removeRoleConstraint( UserRole uRole, RoleConstraint roleConstraint ) throws SecurityException; - PermissionAttributeSet addPermissionAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException; - void deletePermissionAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException; - PermissionAttribute addPermissionAttributeToSet( PermissionAttribute permAttribute, String attributeSetName ) throws SecurityException; - void removePermissionAttributeFromSet( PermissionAttribute permAttribute, String attributeSetName ) throws SecurityException; ReviewManager - PermissionAttributeSet readPermAttributeSet( PermissionAttributeSet permAttributeSet ) throws SecurityException; Additionally, reading permissions will populate the attributeSetName (just name, does not load ftAttributeSet object) and reading roles will populate the roleConstraints (from ftRCs). Let me know if you have any issue or concerns. Thanks! ~Chris ----- Original Message ----- From: "Chris Pike" <[email protected]> To: [email protected] Sent: Thursday, January 28, 2016 2:49:55 PM Subject: Re: Fortress Constraints Maybe, there are many places where we still need to add ability to down select what data is returned, which ties into the ARBAC discussions. That method will be called when managing user / role assignments, so what PermissionAttributes get returned might be driven by the users current ARBAC role. ----- Original Message ----- From: "SHAWN E SMITH" <[email protected]> To: [email protected] Sent: Thursday, January 28, 2016 12:11:34 PM Subject: Re: Fortress Constraints Would it be beneficial to indicate application in the permission attribute? We've talked about roles being cross application, can we do something like Set<PermissionAttribute> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException; and for the non-qualified (as below) Map<String, Set<PermissionAttribute>> rolePermissionAttributes( Role role, boolean noInhertiance, String application) throws SecurityException; where the map key is application the attribute(s) applies to. I think there are administrative reasons why we would want to see cross app ftPA's, but as a single client app it would be nice to be able to just grab what's relevant to me. Just a thought.... "The programmer … works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." — Fred Brooks Shawn Smith Director of Software Engineering Administrative Information Services Penn State University 814-321-5227 [email protected] ----- Original Message ----- From: "CHRISTOPHER PIKE" <[email protected]> To: [email protected] Sent: Thursday, January 28, 2016 10:29:15 AM Subject: Re: Fortress Constraints 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
