This is another way to solver the permissions allow/deny problem. Instead of Deny being a Deny, it is a NotAllow, where you filter the allows. The difference from the first pass is that an equal inherited allow and deny will result in an allow, and the depth of the inheritance is a factor.
Right now Grouper has permissions for external applications.
i.e. msmith can READ org MATH101 for application payrollUser
or
payrollUser can access the studentSearch screen of the payroll application, and msirota is assigned the payrollUser role.
There are inheritance directed graphs of the resources (MATH101), actions (READ), and roles (payrollUser). And for Penn to use this it needs to be able to DENY as well as ALLOW a permission. Currently Grouper can only allow. So if we add DENY, then a payroll ADMIN could get ALLOW on the entire university, and DENY exec_pay, and DENY their own org.
Grouper 2.0 will add allow/deny to permissions. This means that permission assignments will have a true/false flag which indicates if the assignment is an allow or deny.
An issue is depending on the directed graph assignments if the overall result of a permission query 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.
Assignments:
Role<Admin> allows: Action<Read> of Resource<Arts and sciences>
Role<User> denies: Action<Read> of Resource<Arts and sciences>
User jsmith is assigned Role<Admin> and Role<User>
Result:
Overall, jsmith is allowed Arts and sciences since if a user is allowed in any role, they are allowed.
If the application supports users acting as a certain role instead of flattening all permissions into one permissions set (i.e. ability to elevate permissions), then as a User, jsmith cannot Read Arts and Sciences, but as an Admin, jsmith can Read Arts and Sciences
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
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<Arts and sciences>, in the context of Role<Admin>
Result:
jsmith is not allowed to Read Arts and sciences (overall, or role specific) since an individual assignment trumps a generic role assignment
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.
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.
Assignments:
Role<Admin> allows Action<Read> of Resource<All>
Role<Admin> denies Action<Read> of Resource<Arts and sciences>
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
Assignments:
Role<Admin> allows Action<Read> of Resource<Engineering>
Role<Admin> denies Action<Read> of Resource<Arts and sciences>
User jsmith is assigned Role<Admin>
Result:
User jsmith is allowed Action<Read> of Resource<Math> since there are only inherited assignments with the same depth and one is ALLOW
Assignments:
Role<Admin> allows Action<Read / write> of Resource<Engineering>
Role<Admin> denies Action<Admin> of Resource<Arts and sciences>
User jsmith is assigned Role<Admin>
Result:
User jsmith is allowed Action<Read> of Resource<Math> since there are only inherited assignments and the one with the lower depth (tie in resource, Read/Write is lower than Action<Admin>)
Assignments:
Role<Admin> allows Action<Admin> of Resource<All>
Role<Admin> denies Action<Read / write> of Resource<All>
User jsmith is assigned Role<Admin>
Result:
User jsmith is denied from Action<Read> and Action<Write> of Resource<Math> since there are only inherited assignments and the one with the lower depth (tie in resource, Read/Write is lower than Action<Admin>)