Zentrale Rechte Verwaltung von Endpoints für User

[jonathangpk]

Ziel

• ein zentraler Punkt für die Rechtevergabe von Institutuionen und deren User
• Sync zwischen client und server

Aktuelle Lage

Server

• Rechte Management über antMatcher auf Route level
• Jeder controller/service benutzt annotator um bestimmten institutionen zugriff zu geben
• User role abfragen werden in der controller/service funktion abgewickelt
• Wenn ein endpunkt für InstitutionX für alle User und für InstitutionY nur für den Admin user zugänglich sein soll wird es sehr unübersichtlich.
• Wenn in der Zukunft mehr Nutzer gruppen hinzukommen wird es noch unübersichtlicher.

Client

• Der client bekommt vom server die Institution und die User Role des authentifizierten Users
• Die Logic wer welche Seiten und welche Aktionen ausführen darf ist hardgecoded im Frontend
• Auf einem reinen "wer kann welche seiten sehen" ist das ganze vlt noch maintainable aber sobald man aktionen mit permissions hat wird es eine katastrophe. Bsp:
  • Im Patienten Detail View wird es einem Nutzer möglich sein Aktionen auszuführen wie bspw. in quarantäne schicken, test anordenen, krankenhaus zuweisen etc.
  • Für jede aktion muss abgefragt werden ob der user der richtigen aktion angehöhrt und er die richtige user rolle hat. Das für jede aktionen zu tun ist eine menge logik.

Problem

• Sehr fehleranfällig
• Ein feature kann im client freigeben sein beim server nicht und andersherum
• unnötige doppelte arbeit

Lösung

• Der Client holt sich eine object mit einem Permissions object
• Damit ist der client immer in sync mit der server und es gibt deutlich weniger logik und damit weniger bugs im frontend
• Es macht Sinn die Ground Truth logik im Backend zu haben. Das ist der Sicherheittechnisch relevate bereich und mögliche Fehler fallen schon im Entwicklungsprozess auf da die Lücke direkt im Client sichtbar ist.

Mein grober Ansatz

Man kann hier sicherlich einiges auch anders Stukturieren. Wichtig ist nur das das AccessRights object serialisierbar ist und and den client gesendet werden kann.

Es gibt eine abstrakte Permissions Klasse, hier werden die default werte zu gewiesen. In der regel immer false außer zum Beispiel für canAccessUsers(). Die User Role ist eine member variable und kann fuer die permission entscheidung genutzt werden.

@Getter
public abstract class AccessRights {
    private UserRole userRole;

    private boolean canViewPatients = false;
    private boolean canRegisterTest = false;
    private boolean canSubmitTestResult = false;

    boolean canAccessUsers() {
        return userRole == UserRole.USER_ROLE_ADMIN;
    }
}

Jede Institution erstellt dann seine [Institution]AccessRights klasse, erbt von AccessRights und überschreibt die nötigen Rechte.

@Getter
public class DoctorAccessRights extends AccessRights {
    private boolean canViewPatients = true;
    private boolean canRegisterTest = true;
}

Vorteile

• Zentrale und übersichtliche rechtevergabe
• der client hat keine redundante logik mehr
• Die Permission logic ist nicht mehr direkt in services/controllern sondern an einem zentralen ort
• weniger mögliche bugs

Drawbacks diese Ansatzes

• Man muss aufpassen das es nicht zu einer Godclass wird wenn zu viele verschieden Permissions kommen, codesplitting nach bereichen machts ein bischen besser.
• kann in der ausführung nur boolean rechte abbilden

Other Thoughts

• Für genauere Zugriffsrechte wird mit Spring Security ACL gearbeitet. Ob es damit im Zusammenspiel probelme geben sollte muss geklärt werden. ACL ist aber nicht relevant wirklich relevant für den client.

Freu mich über euer Feedback :)

[jogueber]

Aktuelle Rollen:

• Labor

• Klink

• Test Site

• Doctor

• Health Department

endpoints: -doctor

• create-appointment/ (nicht verwendet)
  • institutions
• create/update: aktuell offen (JWT erforderlich)
  • labtest
  • createForPatient -> Doctor,Klink,Test_site (“owner von patient”)
  • updateStatus -> Labor (“owner von labtest”->festlegung bei create )
  • getLabTestsForPatient -> Doctor,Klink, Health department (“owner von patient”)
  • queryLabTestById->Doctor,Klink,Health department,Labor (“owner von patient”)
  • patients
  • getAll-> Doctor,Klink,Health department,Test Site alle die ihnen zugeordnet sind
  • addPatient -> Doctor,Klink,Test Site,Health Department -> automatische Zuordnung muss gewährleistet werden d.h. zum beispiel Gesundheitsamt muss gesetzt werden
    • getPatientForId -> Doctor, Klink,Test Site,Health Department wenn zugeordnet
  • count-> auch wieder eingeschränkt auf owner
  • stats -> health department auch wieder nur für zugeordnete
  • users
• getUsersForInstituions -> nur admin Rollen für die jeweilige Institution
• updateUsers -> user selbst oder admin
• deleteUser -> admin für institution