Differences

This shows you the differences between two versions of the page.

--- applications:tpsr_privileges [2016/09/17 11:42]
rtavassoli [Leserechte]
+++ applications:tpsr_privileges [2017/01/10 11:39] (current)
rtavassoli
@@ Line 1: / Line 1: @@
-====== TPSR Rechtedefinition ======
+====== TPSR Rechte ======
-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//.
+Die Aufteilung in Lese- und Schreibrechte ist nicht zwingend korrekt. Ein Recht ((privilege)) kann auch als Lese- und Schreibrecht verwendet werden. Es ist aber übersichtlicher, wenn man die Rechte entsprechend aufteilt. Rechte, die eine doppelte Rolle spielen, werden entsprechend zugeordnet, bzw. gekennzeichnet.
+===== Rechte und Autorisierung =====
+Es ist auch wichtig zwischen Rechten und der Autorisierung der Rechte zu differenzieren. Die **Anwendung** definiert die Rechte indem man für die Anwendung sinnvollerweise bestimmt, welche Rechte für welche Lese- und Schreib-Aktionen notwendig sind. Der **Autorisierer** bestimmt, wie diese Rechte genehmigt werden.
 \\ \\
-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//.
+Teamrollen eines Mitarbeiters lesen zu dürfen hängt dabei z.B. sinnvollerweise vom Mitarbeiter ab, nicht von der Rolle. Wenn ich mir dann die Mitarbeiter zu einer Rolle angucken möchte, sehe ich auch nur die Mitarbeiter, für die ich das Recht habe, die Teamrollen zu sehen.
 \\ \\
-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.
+Eine Teamrolle für einen Mitarbeiter anlegen ((schreiben)) zu können hängt aber vom Mitarbeiter **und** der Rolle ab. Ein Betreuer soll keinen Einrichtungsleiter anlegen dürfen. Anders herum aber doch. Es könnte auch nur von der Rolle abhängen, und nicht vom Mitarbeiter, also komplett umgekehrt als bei den Leserechten.
 \\ \\
-===== Why define privileges in the application =====
+Die Rechte zu bestimmen ist also eher eine //Kunst// als ein rein logischer, bzw. technischer Vorgang.
-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.
+Zu unterscheiden ist die Autorisierung von der Bestimmung der Rechte. Die Autorisierung wird auf vorhanden Rechte gemacht. Die Rechtebestimmung wird in der **Anwendung** vorgenommen, die Autorisierung der Rechte in dem **Autorisierer**. Der Autorisierer ist dabei abhängig von der Anwendung, aber nicht anders herum.
 \\ \\
-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
+Wie ein Recht autorisiert wird ist dem Autorisierer völlig überlassen. Er kann Rechte auf Mitarbeiterebene direkt auf dieser Ebenen autorisieren. Er kann sie aber auch für alle Mitarbeiter autorisieren die eine bestimmte Rolle in der Einrichtung, in einem Team des Mitarbeiter haben, usw.
-  * authorize a (sub)set of the dimensions of the operation
+==== Flexibilität ====
-  * 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.
+Um es sich in der Anwendung einfach zu machen, kann man Rechte immer für alle Entitäten bestimmen, die irgendwie betroffen sind. Eine Mitarbeiterrolle lesen oder schreiben zu können kann somit immer von dem Mitarbeier und der Rolle abhängen. Die Autorisierer können dann bestimmen, ob sie das Recht auf Mitarbeiterebene, auf Rollenebene, oder für eine Kombination der beiden vergeben.
-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.
+Diese Flexibilität in der Rechtevergabe macht die Rechtebestimmung in der Anwendung wesentlich leichter, weil die Anwendung sich //keine Gedanken// darüber machen muss, wie ein Recht eventuell vergeben werden kann, bzw. wovon es abhängen kann, sondern einfach alles in das Recht //rein wirft// was vorhanden ist.
-===== Read Operations =====
+\\ \\
+So wird es dann auch i.d.R. gemacht werden, weil es erstens auf Ebene der Anwendung einfacher ist, und den Autorisierern viel mehr Flexibilität bietet, wie sie das Recht letzt Enendes vergeben möchten.
+==== Implizierte Rechte ====
+Jetzt wird es richtig cool 8-). Die Anwendung, nicht die Autorisierer, kann bestimmen, welche Rechte andere implizieren. Wenn ich z.B. das Leserecht für alle Team Rollen eines Mitarbeiters habe, impliziert dieses Recht das Recht die Kopfdaten der betroffenen Teams lesen zu dürfen. Warum auch nicht? Wenn ich die Kopfdaten dieser Teams in den Mitarbeiter Stammdaten eh lesen darf, warum dann nicht auch an anderen Stellen, z.B. in der Übersicht aller Teams.
+\\ \\
+Da das Autorisierungs-Framework für jede Rechteanfrage antwortet mit //genehmigt//, //nicht genehmigt// und //bedingt genehmigt//, kann man dem Mitarbeiter in der Liste der Teamrollen anzeigen, dass die Liste u.U. unvollständig ist, weil sie nur bedingt genehmigt ist, falls nur die Teams der Mitarbeiter angezeigt werden, für die der User Leserechte auf die Teamzuordnung hat.
+\\ \\
+Dabei prüft der Autorisierer immer erst die direkt vergebenen Rechte, danach die implizierten Rechte, weil die direkt vergebenen Rechte meist, wenn nicht immer, einfacher, bzw. schneller genehmigt werden.
+===== TPSR Applikation =====
+==== Mandant: TPSRAERM.EntityTypes.Tenant ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|Fehlanzeige||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Tenant.TenantWritePriv||||
+==== Domäne: TPSRAERM.EntityTypes.TenantDomain ====
+Hinweis: Das gehört eigentlich in die Authenfizierung
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|Fehlanzeige||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.TenantDomain.TenantDomainWritePriv|TPSRAERM.EntityTypes.Tenant|||
+==== Mitarbeiter: TPSRAERM.EntityTypes.StaffMember ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.StaffMember.StaffMemberIdentifierReadPriv||||
+|TPSRPrivilege.StaffMember.StaffMemberDetailsReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität ^Implizierte Rechte^
+|TPSRPrivilege.StaffMember.NewStaffMemberPriv|TPSRAERM.EntityTypes.Tenant|||
+|TPSRPrivilege.StaffMember.StaffMemberWritePriv||||
+|TPSRPrivilege.StaffMember.DeactivatePriv||||
+==== Teams: TPSRAERM.EntityTypes.Team ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Team.TeamIdentifierReadPriv||||
+|TPSRPrivilege.Team.TeamDetailsReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Team.NewTeamPriv|TPSRAERM.EntityTypes.Tenant|||
+|TPSRPrivilege.Team.TeamWritePriv||||
+|TPSRPrivilege.Team.AdministerClientsOfTeamPriv||||
+==== Klienten: TPSRAERM.EntityTypes.Client ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Client.ClientHeadDataReadPriv||||
+|TPSRPrivilege.Client.ClientDetailsReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Client.NewClientPriv|TPSRAERM.EntityTypes.Tenant|||
+|TPSRPrivilege.Client.ClientWritePriv||||
+|TPSRPrivilege.Client.AdministerClientsOfTeamPriv||||
+==== Selbstbewertung: TPSRAERM.EntityTypes.SelfQuestionnaire ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.SelfQuestionnaire.SelfQuestionnaireHeadDataReadPriv||||
+|TPSRPrivilege.SelfQuestionnaire.SelfQuestionnaireContentReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.SelfQuestionnaire.StartSelfQuestionnairePriv|TPSRAERM.EntityTypes.Client|||
+|TPSRPrivilege.SelfQuestionnaire.SelfQuestionnaireHeadDataWritePriv||||
+|TPSRPrivilege.SelfQuestionnaire.FillOutSelfQuestionnairePriv||||
+==== Fremdbewertung: TPSRAERM.EntityTypes.ReferenceQuestionnaire ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.ReferenceQuestionnaire.ReferenceQuestionnaireHeadDataReadPriv||||
+|TPSRPrivilege.ReferenceQuestionnaire.ReferenceQuestionnaireContentReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.ReferenceQuestionnaire.StartReferenceQuestionnairePriv|TPSRAERM.EntityTypes.Client|Das Recht eine Bewertung für einen Klienten zu starten. Dabei muss man auch das Recht haben, den Mitarbeiter dazu anzugeben. Man könnte daraus 2 Rechte machen, aber Autorisierer können die Bezugsentitäten getrennt autorisieren, wenn sie möchten ||
+|:::|TPSRAERM.EntityTypes.StaffMember|:::|:::|
+|TPSRPrivilege.ReferenceQuestionnaire.ReferenceQuestionnaireHeadDataWritePriv||||
+|TPSRPrivilege.ReferenceQuestionnaire.FillOutReferenceQuestionnairePriv||||
+==== Team Rollen: TPSRAERM.EntityTypes.TeamRole ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.TeamRole.TeamRoleIdentifierReadPriv||||
+|TPSRPrivilege.TeamRole.TeamRoleDetailsReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Tenant.NewTeamRolePriv|TPSRAERM.EntityTypes.Tenant|||
+|TPSRPrivilege.TeamRole.TeamRoleWritePriv||||
+==== Betreuer Rollen: TPSRAERM.EntityTypes.CustodianRole ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.CustodianRole.CustodianRoleIdentifierReadPriv||||
+|TPSRPrivilege.CustodianRole.CustodianRoleDetailsReadPriv||||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.Tenant.NewCustodianRolePriv|TPSRAERM.EntityTypes.Tenant|||
+|TPSRPrivilege.CustodianRole.CustodianRoleWritePriv||||
+==== Mitarbeiter-Einrichtungsrollen Zuordnung: keine eigene Entität im AERM ((Authorization Entity Relationship Model)) ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.AssignedTenantRole.StaffTenantRoleReadPriv|TPSRAERM.EntityTypes.StaffMember|||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.AssignedTenantRole.StaffTenantRoleWritePriv|TPSRAERM.EntityTypes.StaffMember|||
+==== Mitarbeiter-Teamrollen Zuordnung: keine eigene Entität im AERM ((Authorization Entity Relationship Model)) ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.AssignedTeamRole.StaffTeamRoleReadPriv|TPSRAERM.EntityTypes.StaffMember|||
+|TPSRPrivilege.AssignedTeamRole.TeamStaffRoleReadPriv|TPSRAERM.EntityTypes.Team|||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.AssignedTenantRole.StaffTeamRoleWritePriv|TPSRAERM.EntityTypes.StaffMember|||
+|TPSRPrivilege.AssignedTenantRole.TeamWithTeamRoleWritePriv|TPSRAERM.EntityTypes.Team|||
+|:::|TPSRAERM.EntityTypes.TeamRole|||
+==== Mitarbeiter-Betreuer Zuordnung: keine eigene Entität im AERM ((Authorization Entity Relationship Model)) ====
+=== Leserechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.AssignedCustodianRole.ClientCustodianRoleReadPriv|TPSRAERM.EntityTypes.Client|||
+|TPSRPrivilege.AssignedCustodianRole.StaffCustodianRoleReadPriv|TPSRAERM.EntityTypes.StaffMember|||
+=== Schreibrechte ===
+^Recht^abweichende Bezugsentität^Bescheibung^Implizierte Rechte^
+|TPSRPrivilege.ClientCustodianRoleWritePriv.StaffTenantRoleWritePriv|TPSRAERM.EntityTypes.Client|||
+|:::|TPSRAERM.EntityTypes.CustodianRole|||
+|TPSRPrivilege.AssignedCustodianRole.StaffCustodianRoleWritePriv|TPSRAERM.EntityTypes.StaffMember|||
-^ Operation ^ Details ^ Available Contexts ^ 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 ^
+===== TPSR Authentifizierung =====
-^ Read Client head data | Id values, ClientKey, Active, Allocated to Team  | Client | ClientHeadDataReadPriv | Client | TeamHeadDataReaPriv  | ReadCustodianRolesOfStaffMember |
-^ Read Client detail data | Id values, ClientKey, Active, Allocated to Team  | Client | ClientHeadDataReadPriv | Client | TeamHeadDataReaPriv  | ReadCustodianRolesOfStaffMember |
-^ Read assigned custodian roles | | Client \\ StaffMember \\ 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 |||||||
-===== Schreibrechte =====
-^ 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.)) ^
+===== TPSR Autorisierung =====
-^ 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  ^^^^^^^
-===== Schreibrechte =====

tawiki

User Tools

Site Tools

Differences

Page Tools