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
