We want to be able to craft policies by an expression instead of creating loaders or tons of reference groups based on cartesian products of basis/ref groups.
Individual groups can be configured to automatically have their membership managed with individual subject or other basis groups.
Why do we need this feature?
- Reduces pre-loaded rollups that might not be used
- You don't need a loader job for each one of these groups
- Any Grouper user could edit the policies if they can READ underlying groups. The expressions are secure
- The memberships of the ABAC groups are real time based on an intelligent change log consumer
- You can have a UI to help build it and give good error messages
- Could visualize the policies. Perhaps could be integrated into existing visualization
- This solved the issue of composites with any number of factors
The expression can only be written by people who can READ groups in the abac group/subject tables.
Boolean logic and wildcards are required
|org:whatever:app:somePolicy||ref/basis groups as members||(group.campus =~ ['palmer', southern'] and group.termStart - 7 > sysdate and group.termEnd + 7 < sysdate)||Give me groups as members where campus and term match|
|org:whatever2:app2:somePolicy2||subjects as members||person.primaryAffiliation =~ ['faculty', 'staff'] and person.dept =~ ['physics', 'math']||Subjects in a role and dept|
|org:whatever3:app3:somePolicy3||could have some groups and subjects|
(group.campus =~ ['palmer', southern'] and group.termStart - 7 > sysdate and group.termEnd + 7 < sysdate)
or (person.primaryAffiliation =~ ['faculty', 'staff'] and person.dept =~ ['physics', 'math'])
|Take some group populations and some subjects|
Requirements for expressions
Needs to be parsed so we can
|Library in Grouper already||Nice to have||Avoid library bloat||Yes||Soon perhaps||No (there are|
Java SQL parsers)
|Supports boolean logic||Required||and, or, not, etc||Clunky||Yes||Yes||Yes|
|Needs wildcards||Required||Some way to have wildcards for values||Yes||Yes||Yes||Not built in but we can use =^ for "like"|
Seems like JEXL is a good place to start
Expression 1: Campus not in palmer or southern, and term start more than 7 days ago
Two Grouper tables will be constructed for performance reasons (getting relationships and point-in-time)
|grouper_abac_group_attributes||Rows for groups and attribute names and values|
|grouper_abac_subject_attributes||Row for subjects and attribute names and values|
These tables are managed by grouper based on configuration.
Group attribute table
The group attribute values come from the attribute framework which could be automatically fed from external systems of record. For now, an OtherJob could do this on a schedule.
|Group name||Attribute name||Attribute value||Active||Next start time||Last end time|
|ref:course:term:cis124||termStart||8/1/2020 (note, this is actually integer seconds since 1970)|
Loading attributes to groups
This can use a similar format to the marker / name-value pair convention for attributes, or can just be attributes on groups. i.e. the marker attribute column is optional. Types will be converted (e.g. the varchar "24" will be converted to 24 if the attribute is integer based). Note: dates can be converted to the appropriate type (e.g. from date column to integer seconds from 1970)
|SQL query with columns, eventually a loader job|
|Group name||Attribute marker name||Attribute name||Attribute value||Active||Next start time|
Subject attribute table
The individual attribute values are fed from basis/ref groups and the values can be transformed from the group name to something that has institutional meaning. This can happen from attribute or from text manipulation
|Subject id||Source id||Attribute name||Attribute value||Active||Next start time||Last end time|
Parse expression with JEXL
Feed the expression through this simple program
Grouper can take that object model and see which group and subject attributes are related, print out a nice analysis of the policy, and know which policies are affected by real time changes
Expression 2: campus is palmer or southern, or the term is current with some overlap
Expression 3: campus is palmer or southern, or the term is current with some overlap
To confirm a policy is correct, a long form translation of the policy can be displayed along with group names and group counts
A nightly full sync will occur. The incremental sync should stop. Make sure everything in the attribute tables is up to date. Make sure all the policy groups are up to date.
An incremental change log consumer can
- If group attributes change, see if it affects group attributes
- See which memberships change, if these are related to subject attributes, then update the attribute tables
- If attributes change, see which policies those refer to, and incrementally adjust the membership of those groups
- Policy changes should change the population
Loading groups that are used
We could have another table which links up expressions (policies) with the groups used in those policies. Loader jobs which only load groups which are used (if a fraction of course groups are used) could key off that table to know that a group is used in a policy and needs to be populated.