Wir haben ein recht kompliziertes System zur Berechtigungsbearbeitung in unserer (ASP.NET web) Anwendung. Benutzer können bestimmte Berechtigungen für verschiedene Arten von Objekten haben, einige Berechtigungen werden sogar in Gruppen / Rollen gepackt, die Benutzern zugewiesen sind. Alles in allem endet dies in einem ziemlich komplizierten Durcheinander, bei dem zur Bestimmung, ob ein Benutzer etwas tun / sehen kann, viele verschiedene Quellen von Berechtigungen ausgewertet werden müssen, und dies geschieht irgendwie auf Anforderung und basierend auf bestimmten Situationen.
Meine Frage ist (von einem hohen Standpunkt aus betrachtet), ob es einige Vorschläge / allgemeine Entwurfsmuster gibt, um mit dem Berechtigungskonzept im Allgemeinen umzugehen, und wahrscheinlich auch, wie Sie mit Ihrer Architektur umgehen.
Benutzer und Gruppen mit der Möglichkeit, bool UserHasPermission( SOME_PERMISSION ) für eine atomare Berechtigung zu testen, die einer Gruppe zugeordnet ist, ist der Standardansatz für die Autorisierung. basiert:
Es ist jedoch nicht ideal für alle Situationen.
Für das alte Modell finde ich, dass die Leistung durch die Verwendung von Memoization während der Berechtigungsprüfung erhöht werden kann. Auf diese Weise gehe ich nicht n mal pro Sitzung zur Datenbank, um die Zugriffskontrolle zu überprüfen. Memoization speichert das Ergebnis eines Aufrufs mit den gleichen Parametern in einem Cache, so dass alle Aufrufe eines bestimmten Benutzers zur Überprüfung der XYZ-Berechtigung das gleiche Ergebnis liefern. Natürlich würden Sie sicherstellen, dass Sie die Memo-Berechtigungen für den Benutzer in der Sitzung für jeden Benutzer gespeichert haben. Wenn Sie die Berechtigungen bei der Anmeldung laden, müssen Sie sie nicht zwischenspeichern, aber in großen Systemen mit vielen Berechtigungen ist es manchmal am besten, sie nur bei Bedarf zu bekommen.
Ich habe mehrere komplizierte Berechtigungsschemata gesehen. Es gab immer eine Rechtfertigung dafür, aber unglücklicherweise wurden sie alle zu kompliziert und auf etwas Einfacheres reduziert.
Meine persönliche Schlussfolgerung lautet nun: Bleiben Sie bei Zugriffssteuerung für die Rollenbasis ( RBAC ) ) Dies ist der einzig vernünftige, den jeder versteht. Es ist irgendwie begrenzt, aber für die meisten Fälle ausreichend.
Verwenden Sie auch die deny-Regel , dh Sie gewähren nur Rechte. Auch hier habe ich System mit der gegenteiligen (standardmäßig zulassen) oder sogar konfigurierbaren Standardrichtlinie (!) Gesehen und finde es nicht sinnvoll.
Ich habe dies vom Gesichtspunkt der Anwendungsentwicklung aus nicht behandelt, aber oft ist es beim Umgang mit Berechtigungen eine gute Praxis, Berechtigungen für Objekte zu setzen, die Rollen verwenden, anstatt Benutzern direkt die Berechtigung für das Objekt zu geben. Wenn ein Benutzer Zugriff auf eine bestimmte Gruppe von Objekten benötigt, geben Sie ihnen keinen direkten Zugriff, stattdessen geben Sie ihnen eine Rolle, die wiederum den erforderlichen Zugriff hat. Dies "wiederverwendet" in gewisser Weise die Arbeit, die für die Schaffung der Rolle geleistet wurde.
Der Umgang damit im Code kann jedoch kompliziert werden, da Sie jede Rolle eines Benutzers durchlaufen müssen und feststellen müssen, ob die Rolle dem Benutzer die Berechtigung für das Objekt erteilt. Ich kenne keine spezifischen Vorschläge im Umgang mit diesem anderen als dem offensichtlichen Versuch, diese Art von Code in seinen eigenen Rahmen einzubeziehen.
Tags und Links .net c# asp.net design-patterns permissions