Grouper 2.0 adds and above allow/deny to permissions.  This means that permission assignments have a true/false flag which indicates if the assignment is an allow or deny. 

...

Note: one requirement is to be able to determine the result with only one DB query.  There is probably a better way to do this if more queries are available, but we need performance to be fast.

Algorithm

1. Note: assignments of permissions directly to subjects are only in the context of a role.  So if the user loses that role, they lose the individual permission assignments.  This can be used for deprovisioning (e.g. the role assignment is based on a composite group or rule that the subject must be in the employee group)
2. Permissions can be computed flattened across all roles in the application, or for a certain role (the user would "actAs" a certain role as they use the application, sometimes needing to elevate their permissions).  If the permissions are flattened, then any ALLOW will cause the overall results to be an ALLOW
3. If there is no relevant assignment, then the result is default DENY
4. Assignments to as individual subject will trump assignments to a role that the subject is assigned to
5. Assignments to a role the subject is assigned to will trump assignment to a role the subject's role inherits from.  Lower depth role assignments trump higher depth assignments.
6. If there are only assignments to inherited roles of equal depth, then if any of those assignments is an ALLOW, then the result will be a ALLOW.  If all are NOT_ALLOW, then the result will be NOT_ALLOW
7. If there are two assignments that conflict based on role, then look at the resources:
   1. If the resource has a direct assignment (not possible to have two conflicting assignments to the same resource, action, role, subject), then use it, it trumps an inherited assignment.  Lower depth inherited assignments trump higher depth inherited assignments.
   2. If there are inherited permissions of the same depth, then if any is a ALLOW, then the result is ALLOW.  If all are NOT_ALLOW, then result is NOT_ALLOW
   3. If there are two direct assignments to the same resource (not inherited) with different ACTIONS:
      1. If the ACTION has a DIRECT assignment, then if it is ALLOW, then result is ALLOW, else DENY.  Lower depth action assignments trump higher depth assignments.
      2. If there are inherited ACTIONS of the same depth, then if any is an ALLOW, then the result is ALLOW.  If all are NOT_ALLOW, then result is NOT_ALLOW

...

adminRole.getPermissionRoleDelegate().assignRolePermission("read", artsAndSciences, PermissionAllowed.ALLOWED);
user.getPermissionRoleDelegate().assignRolePermission("read", artsAndSciences, PermissionAllowed.DISALLOWED);

adminRole.addMember(subj0, false);
user.addMember(subj0, false);

PermissionFinder.hasPermission(subj0, english, "read");
PermissionFinder.hasPermission(subj0, adminRole, english, "read");
PermissionFinder.hasPermission(subj0, user, english, "read");

Role inheritance

Assignments:

Role<Admin> denies: Action<Read> of Resource<Arts and sciences>

Role<Senior admin> allows: Action<Read> of Resource<All>

User jsmith is assigned Role<Senior admin>

Result:

Overall, jsmith is allowed Action<Read> of Resource<Arts and sciences> since the subject is assigned directly to Senior admin, it will trump inherited role assignments

...

Role assignment vs individual assignment up the hierarchy

Assignments:

Role<Admin> denies: Action<Read> of Resource<Arts and sciences>

User jsmith is assigned Role<Admin>

User jsmith is assigned permission Allow, Action<Read>, Resource<All>, in the context of Role<Admin>

Result:

jsmith is allowed to Read Resource<Math> (overall, or role specific) since an individual assignment, even up the resource graph, trumps a generic role assignment.  The user can read all resources.

...

Role assignment vs individual assignment up the hierarchy example 2

Assignments:

Role<Admin> allows: Action<Read> of Resource<Arts and sciences>

User jsmith is assigned Role<Admin>

User jsmith is assigned permission Deny, Action<Read>, Resource<All>, in the context of Role<Admin>

Result:

jsmith is not allowed to Read Resource<Math> (overall, or role specific) since an individual assignment, even up the resource graph, trumps a generic role assignment.  The user cannot read any resources.

...

User jsmith is assigned Role<Admin>

Result:

User jsmith is denied Action<Read> of Resource<English> and Resource<Math> since there are only inherited assignments and the ones with lower depth have priority

...