This is an old revision of the document!
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 with1) 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
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.
Operation | Dimensions | Details | Required Privileges2) | Privilege Context3) | Implied Privileges of Priv4) | Implied by Privilege |
---|---|---|---|---|---|---|
Read assigned custodian roles | - Clients - StaffMembers - CustodianRoles | ReadCustodianRolesOfClient | Client | Read privilege of StaffMember head data | ||
Leserechte der Kopfdaten der Rollen | ||||||
or | ||||||
ReadCustodianRolesOfStaffMember | StaffMember | Leserecht der Klienten Kopfdaten | ||||
Leserechte der Kopfdaten der Rollen | ||||||
Implied privileges are not modelled explicitly. The callers of the privileges must decide if they want to use the implied privileges, and set them accordingly. Authorizers will not authorized implied privileges. It is up to the developer to use them correctly. Maybe later implied privileges can be made explicit, but then the developer will not have the chance to use them or not, so the decision to leave it up to the developer means a little more work for the develeper when authorizing queries and commands, but it is the most flexible solution too |