Policies

Es soll sichergestellt werden, dass nur Aktionen von berechtigten Personen (Subjekt) ausgeführt (bzw. Daten abgefragt) werden können. Da die Entscheidung nicht nur von der Rolle des Subjekts und der Aktion abhängt, sondern auch vom Objekt (CourseStaffMembership), wird eine policybasierte Zugriffskontrolle (Attribute based access control) eingesetzt. CourseUpdatePolicy ist z.B. eine Policy, die korrekt umgesetzt ist.

Die Durchsetzung einer Policy erfolgt bei Aufruf eines REST-Endpunkts im Backend. Dafür werden verschiedene Möglichkeiten genutzt:

1. PreAuthorize Annotation: Vor Ausführung der Methode zum Endpunkt wird geprüft, siehe TaskController#getOne für ein Beispiel. Die Prüfung wird durch die PolicyPermissionEvaluator Implementierung umgesetzt.
2. Manuell in der der Methode: Vor Ausführung der Methode stehen nicht im- mer alle Informationen bereit, die bei der Autorisierung benötigt werden. Damit Objekte nicht doppelt aus der Datenbank geladen werden, kann die Prüfung durch den PolicyEvaluator manuell erfolgen (einfach injizieren). Siehe CourseController#update für ein Beispiel.
3. Über Services: Für den Einsatz von Paging in Controllern ist es notwendig, dass die Policy in SQL Statements übersetzt wird. Dies verletzt zwar den Design-Grundsatz, dass Autorisierungslogik über aspektorientierte Programmierung umgesetzt werden sollte, ist jedoch nicht anders möglich wenn Filter/Paging verwendet werden. In diesem Fall gibt der Controller dem Service mit, welche Aktion mit den angeforderten Datensätzen einhergeht. Die zuständige Policy erzeugt daraufhin eine Specification-Objekt, welches die Berechtigung als Filter in einer SQL-Abfrage durchsetzt. Der Service nutzt dann diese Specification in Kombination mit anderen Filtern, um nur die Datensätze zurückzugeben, für die der Benutzer Zugriff hat. Siehe SolutionController#getAll für ein Beispiel.