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
