rollenbasierten Zugriff auf Methoden

Question

Ich bin die Umsetzung System der Rolle in Klassen basierten Zugriff auf verschiedene Methoden verwendet. Zum Beispiel eine Aktion ausführen muss ich prüfen, ob Benutzer, die sie verwendet es tun können.

Ich kann in jeder Methode schreiben:

if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}

Ich dachte über diesen Prozess beispielsweise die Automatisierung von Attributen dieser Methoden hinzufügen oder vielleicht eine andere Lösung?

Answer 1

Werfen Sie einen Blick auf 'Aspect Oriented Programming' (AOP) Bibliotheken - und die Antworten auf diese Frage Stackoverflow . Sie können AOP verwenden, um die Rolle Prüfcodes automatisch hinzuzufügen.

Answer 2

Solange Sie Principals Dinge verwenden, sind schon da ...

[PrincipalPermission(SecurityAction.Demand, Role = "A role available on your principal")]
public void Foo()
{
  // Will throw an exception if the principal does not have the required role
  // Otherwise the method will execute normally
}

Answer 3

Do Check einmal Bauzeit und Wurf (oder Rückkehr NULL aus der Fabrik), wenn die Sicherheitsbedingung nicht erfüllt ist. Danach ist ein Verweis auf ein bestimmtes Modell Objekthalte genug Beweis dafür, dass Sie die Sicherheitsüberprüfung zu einem früheren Punkt passiert. Wenn Sie besorgt sind, dass dies könnte dazu führen, TOCTTOU Fragen, stellen Sie sicher, dass diese Objekte am Ende eines anwendungsdefinierten Konzepts der „Spielrunde“ (in der Regel der Datenbanktransaktion) unbrauchbar werden; Dies ist eine gute Praxis sowieso.

Dieser Ansatz der Sicherheit Fähigkeit Disziplin genannt. Denken Sie an Ihre Objekte wie Kisten, die eine gewisse Autorität in sich haben (in ihren privaten Variablen). Durch Drücken der Tasten auf der Box, können Sie nur ausüben, einen maßgeschneiderten unten Bruchteil dieser Behörde in der Art und Weise, dass der Programmierer des Objekts ermöglicht es Sie.

Zum Beispiel, sagen Sie eine Kalender-Anwendung mit einem SQL-Backend schreiben. Es besteht die SQLTransaction Objekt, das die Transaktion nicht (nach oben) überleben, aber noch hat es alle Rechte an allen Tabellen, die die Anwendung verwendet. Das ist eine viel Kraft, dass Sie nicht möchten, dass die Nutzer von Ihrer API, das um sein (explizit oder durch Fehler, denken SQL-Injection). Stattdessen Hand Sie User Objekte dieses Modell die Behörde aus nur die an diesen Benutzer Zeile in der Tabelle Benutzer zu schreiben; auch ein User kann erstellen, lesen, aktualisieren, löschen Appointment Objekte, die in ähnlicher Weise begrenzt Autorität in der Termin Tabelle darstellen.

RBAC Zur Aufrechterhaltung der gesamten API, Sie müssen sicherstellen, dass die folgenden halten:

1. Nur berechtigte Benutzer können den Zugriff auf das User Objekt erhalten, die sie darstellt. Hier können Sie das Authentifizierungssystem in den User Konstruktor verdrahten;
2. Die User Objekte nicht Leck Behörde , dh Sie müssen prüfen Sie Ihre API, um sicherzustellen, dass Methodenaufrufe auf einem User durch die Ausübung (oder einem ähnlichen Objekt sie zurückkehren, rekursiv) Sie keine Ressourcen lesen oder ändern können, die dies nicht tun, gehören in diesen Benutzer. Hier können Sie die Facette Muster - zB User.GetAppointments() kehrt echte Appointment Instanzen für Termine erstellt dieser Benutzer, aber schreibgeschützten Wrapper für die von jemandem erstellt sonst.