tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== TPSR Rechtedefinition ======
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((and)) 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.
\\ \\
===== Why define privileges in the application =====
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.
===== Read Operations =====

^ Operation ^ Details ^ Required Privileges((Alles ODER-Rechte -NEIN. NICHT unbedingt. Können auch UND-Rechte sein!!!. Sie unterscheiden sich lediglich im Kontext der Autorisierung, der von der Applikation vorgegeben ist!)) ^ Privilege Context((Es handelt sich hierbei um einen Kontext. Wenn das Recht vom Klienten abhängt, wird es dem Klienten gegeben. Der Kontext, in dem das Recht vergeben wird, ist aber dem Autorisierer überlassen. Es kann auf Ebene des Klienten vergeben werden, für alle Klienten eines Teams, der Einrichtung, oder irgend einer anderen Gruppierung.)) ^ Implied Privileges((By the Required Privilege, not the Operation)) ^ Implied by Privilege ^
^ Read Client head data | Id values, ClientKey, Active, Allocated to Team  | ClientHeadDataReadPriv | Client | TeamHeadDataReaPriv  | ReadCustodianRolesOfStaffMember |
^ Read Client detail data | Id values, ClientKey, Active, Allocated to Team  | ClientDetailsReadPriv | Client | ClientHeadDataReadPriv \\ TeamHeadDataReaPriv for Team of Client | ReadCustodianRolesOfStaffMember |
^ Read assigned custodian roles | Id values of Client, StaffMember and CustodianRole | ReadCustodianRolesOfClient | Client| Read StaffMember head data | |
^ ::: | ::: | ::: | ::: | Read CustodianRole head data | |
^ ::: | ::: |  or  ||||
^ ::: | ::: | ReadCustodianRolesOfStaffMember | StaffMember | Read Client head data | |
^ ::: | ::: |  ::: | ::: | Read CustodianRole head data | |
^ 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 ||||||

===== Write Operations =====

^ Befehl ^ Information ^ Dimensionen ^ Detailinformation ^ Recht in TPSRPrivilege((Alles ODER-Rechte. Sie unterscheiden sich lediglich im Kontext der Autorisierung, der von der Applikation vorgegeben ist!)) ^ Implizierte Rechte ^ Recht hängt ab von((Es handelt sich hierbei um einen Kontext. Wenn das Recht vom Klienten abhängt, wird es dem Klienten gegeben. Der Kontext, in dem das Recht vergeben wird, ist aber dem Autorisierer überlassen. Es kann auf Ebene des Klienten vergeben werden, für alle Klienten eines Teams, der Einrichtung, oder irgend einer anderen Gruppierung.)) ^
^ Hinweis: Ein Befehl kann mehrere Informationen beinhalten, für die Rechte vergeben werden. Pro Information kann es mehrere Oder-Rechte geben. Pro Befehl gibt es aber  ^^^^^^^
tawiki

User Tools

Site Tools

Page Tools
