The separation of Operations and Privileges is important, even though they seem to be one and the same. If the opertion is to assign a staff member as a custodian to a client, the required privileges can be the right to assign the staff member to a client, together with¹⁾ the right to assign a custodian to the client with the given role.

Im many cases, especially when reading data, it seems twice the neccessary work to define operations and privileges for one and the same set of dimensions. That will be fixed by introducing an operation-privilge duality.

Also note that both operations and privileges are defined by the application. Privileges could be defined by an orthogonal authorization layer, but that would introduce so much complexity that it does not ever seem sensible to do so. So the authorizatin layer only decides how to authorize the privileges defined by the application. Only being relative, because that is already a huge improvement, away from authorization being muddled up everywhere, in each and every query and action.

If the application were to only define the operation to assign a staff member to a client with a role, then separating this into two privileges, one based on the staff member, one on the client and role combination, is possible, even inside the autorization layer. Let's say an operation has 3 dimensions, A, B and C. One authorizer could authorize A|B, and require authorization of C. Another could authorize B|C and require A. Now, if the first entirely authorizes the context for A|B, the second for B|C, then the entire privilege is authorized! If not, simply join the authorization Sql statements, which will ultimately join over B, and thus give the correct set of authorized contexts.

While this is possible, the UI would now have to query the authorization in order to see which dimensions depend on one another, so that it can build sensibly cascading inputs. Wizards will be difficult, because the order of the pages may not fit the dependency of the authorized dimensions.

Thus, the only sensible decision is to have both operations and privileges defined inside the application layer, knowing that it is possible to separate out the privileges into a new layer - actually, we would get rid of privileges and have authorizers

• authorize a (sub)set of the dimensions of the operation
• optionally require authorization of a further subset of the dimensions of the operation. If it does not, then the authorizer allows the entire operation based on the subset it itself authorizes.

While this is a real academic challenge and could potentially be really great, I will leave it until (much) later, possibly not ever going that path, because I see no real use case for it now.

I could imagine a pluggable identity-based validation layer which does just this, extending the existing authorization schema selectively.