Global

# Authorization architecture, design and implementation

It's 2023. Trump may become President of God's Own Country next year. We have moved from bespoke authentication and authorization design and implementation to Keycloak and IDshield. With all this comes a new view about the architecture of authorization data, and its implementation.

## Authorisation information

This information specifies what a user can and cannot do. It has four dimensions:

* **Capability**: this specifies if the user can perform a specific operation. In implementation, it maps on to a web service call (WSC). Can user X call WSC Y?

* **Visibility constraints**: this specifies whether the user can see all data in a specific table or for a specific call (*e.g.* all sales data) and if not, then which subsets can he see? This is equivalent to doing a `SELECT` on a table and using the visibility constraints for a `WHERE` clause. For instance, user X can see all sales data and user Y can see only North Zone data.

* **Attribute constraints**: this specifies whether the user can see/edit all the attributes (or columns, in DB parlance) of a class of entities, or can only see a subset. For instance, some privileged users can see the full employee list with all attributes, but most users are not allowed to see the salary data. So, there are restrictions on certain restricted attributes. We can then divide the list of attributes into a general-access set and a privileged set.

* **Value constraints**: this specifies whether a user's access is restricted to certain value limits of certain quantitative fields. For instance, a junior manager is permitted to approve an invoice with a total value less than a million dollars, whereas a vice president can approve invoices of up to ten million.

Combining all these, we can make a sample statement like this: Mister Joe Pesci can do voucher edits (he has the `voucheredit` **capability**) for vouchers of only retail sales (**visibility constraint** based on voucher type) whose value is less than $20,000 (**value constraint**). And while he does so, he is not permitted to change the date of the voucher (**attribute constraint**).

Expressing this in a tight notation, we can specify this tuple:

```

joe.pesci:   (voucheredit, vis=retailsales, val=(amt,le,20000), attr=!date)

```

Mr Pesci may have multiple such authorization tuples, for various combinations of these four elements.

```

joe.pesci:   (voucherview, vis=ALL, val={}, attr={})

joe.pesci:   (voucheredit, vis=retailsales, val=(amt,le,20000), attr=!date)

joe.pesci:   (vouchernew, vis=retailsales, val=(amt,le,20000), attr={})

```

With this set of records, Mr Pesci can see all vouchers, create vouchers only in retail sales of value less than $20,000 and enter all details (no attribute constraints) but when editing these vouchers, he is not allowed to edit the date.

We can collapse the semantics of the fourth term (attribute constraints) if we expand the set of values for the first term. So, instead of having a generic `voucheredit`, we have two capabilities: `vouchereditfull` and `vouchereditnondate`. With this refinement, we can express the previous set of rules in the following way:

```

joe.pesci:   (voucherview, vis=ALL, val={})

joe.pesci:   (vouchereditnondate, vis=retailsales, val=(amt,le,20000))

joe.pesci:   (vouchernewfull, vis=retailsales, val=(amt,le,20000))

```

Thus, the fourth member of the tuple can be eliminated everywhere by applying this trick of defining a more fine-grained set of capabilities.