[In hindsight. This README was written in under 5 minutes, please contact sapanb@cs.princeton.edu if you have questions.]
Afterthought is mechanism for deploying access control policies based on data gathered via multiple data sources. A predecessor to Afterthought, sfatables, assumed that all such state was available in XML format. Afterthought is more pragmatic in that it does not require the data to be serialized unless absolutely necessary.
The result of using Afterthought is a program (in Python) that applies the desired access control policies efficiently.
An Afterthought program, just like its Python counterpart is a decision tree whose general form is:
PROGRAM ::= Access Granted | Access Denied | if () then PROGRAM else PROGRAM
...where is specified using XPath. Ignoring details involving the database schema and the involvement of multiple data sources, here's an example of an afterthought program:
---
/Slices[$filter] -> {
/caller[@roles!="admin"] -> {
/caller[@roles="pi" or @roles="tech"] -> {
/Slices[@site=/caller/@site] -> { true }
}
| /caller[@roles="user"] -> {
/Slices[@slice_id = /caller/@slice_ids] -> { true }
}
}
}
--
- $filter is a free variable provided by the environment.
- /Slices is a database table backed up by SQL (data source 1)
- caller is an in-memory python dict that stores the caller's authentication state (data source 2)
---
Afterthought can handle multiple access control policies naturally. In general,
Program 1 + Program 2 = '|'
...making it a possible to extend policies.
---
The goal of the Aft compiler is to "partially evaluate" the policy incrementally till it has been reduced to a verdict. E.g. in the above program, we first evaluate the predicates on 'caller' followed by those on Slices. Rather than by extracting the whole slice table, the latter can be deferred to SQL, which can use its indexing to evaluate the predicate efficiently.
Future work-->
* Specify optimization constraints at a finer grain
* Profile-driven optimization