...
- 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
Expressions
The expression can only be written by people who can READ groups in the abac group/subject tables.
Boolean logic and wildcards are required
| Group | Type | Expression | Description |
|---|---|---|---|
| org:whatever:app:somePolicy | ref/basis groups as members | (group.campus =~ ['palmer', southern'] and termStart - 7 > sysdate and 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 termStart - 7 > sysdate and termEnd + 7 < sysdate) or (person.primaryAffiliation =~ ['faculty', 'staff'] and person.dept =~ ['physics', 'math']) | Take some group populations and some subjects |
Requirements for expressions
| Name | Priority | Description | JSON | GraphQL | SQL | JEXL |
|---|---|---|---|---|---|---|
| Parsable | Required | Needs to be parsed so we can | Yes | Probably | Probably | Yes |
| Library in Grouper already | Nice to have | Avoid library bloat | Yes | Soon perhaps | No (there are Java SQL parsers) | Yes |
| Supports boolean logic | Required | and, or, not, etc | Clunky | Yes | Yes | Yes |
| Supports grouping | Required | parens | 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
| Code Block |
|---|
group.campus !~ ['palmer', 'southern'] and group.termStart - 7 > sysdate |
Tables
Two Grouper tables will be constructed for performance reasons (getting relationships and point-in-time)
| Table name | Description |
|---|---|
| grouper_abac_group_attributes | Rows for groups and attribute names and values |
| grouper_abac_subject_attributes | Row for subjects and attribute names and values |
...
| grouper_abac_subject_attributes | ||||||
| Subject id | Source id | Attribute name | Attribute value | Active | Next start time | Last end time |
|---|---|---|---|---|---|---|
| jsmith | person | affiliation | staff | T | ||
| jsmith | person | dept | math | T | ||
| jsmith | person | dept | physics | T | ||
| rjohnson | person | school | engineering | F | 11/1/2020 | |
| wturner | person | primaryAffiliation | faculty | T | ||
Expressions
The expression can only be written by people who can READ groups in the abac group/subject tables.
Boolean logic and wildcards are required
...
(group.campus =~ ['palmer', southern'] and termStart - 7 > sysdate and termEnd + 7 < sysdate)
or (person.primaryAffiliation =~ ['faculty', 'staff'] and person.dept =~ ['physics', 'math'])
...
Requirements for expressions
...
Needs to be parsed so we can
check security, do real-time
updates, and analyze policies
...
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
...
Parse expression with JEXL
Feed the expression through this simple program
...