So gehen Sie am besten mit Berechtigungen (nicht Rollen) in der asp.net-Mitgliedschaft um, insbesondere in ASP.NET MVC

Question

Es gibt viele Fragen (und Informationen) zum Einrichten der asp.net-Mitgliedschaft, zu Rollenanbietern und dergleichen.Unabhängig davon, ob Sie die von Microsoft bereitgestellte integrierte Plattform verwenden oder die Basisklassen erweitern und Ihre eigene Rolle erstellen sollten.

Ich habe beschlossen, die Standardanbieter zu erweitern und meine eigenen Mitgliedschafts- und Rollenanbieter zu implementieren.Meine Frage betrifft nun speziell die Rollenauthentifizierung.

Traditionell würden Sie Rollen erstellen, etwa „Manager, Administrator, Mitarbeiter, Superuser“ oder was auch immer Sie haben.Aber was würden/sollten Sie in Bezug auf Berechtigungen tun, die meiner Meinung nach ein feineres Maß an Kontrolle darstellen?Lassen Sie mich näher darauf eingehen...

Auf meiner asp.net MVC-Site habe ich verschiedene Bereiche wie Verwaltung, Management, Messaging, Reporting usw.Ich würde für jede dieser Rollen Rollen erstellen, z. B. „Administrator“, „Manager“, „Reporter“ usw.Ohne die entsprechende Rolle können Sie keinen Zugriff auf diesen Bereich der Website erhalten.Daher würde ich damit die gesamten Controller auf Klassenebene sperren.

Aber nehmen wir nun einen Bereich als Beispiel;Messaging und sagen, ich wollte detailliertere Berechtigungen für CRUD haben;Eine Nachricht erstellen, Nachrichten anzeigen/lesen, Nachrichten bearbeiten, Nachrichten löschen usw.

Abschließend meine Frage.Wie ließe sich diese feinere Kontrolle am besten umsetzen?Ein Ansatz, den ich sehe (ich bin mir nicht sicher, ob er gut ist), besteht darin, einfach asp.net-Mitgliedschaftsrollen für alles zu erstellen.Also hätte ich vielleicht....

Messenger (breite Ebene), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

Einerseits möchte ich, dass einige Benutzer Nachrichten lesen/ansehen können.Aber nicht unbedingt erstellen oder löschen.Auf einzelne Controller-Aktionen könnten die spezifischen Rollen angewendet werden.

Sehen Sie Probleme mit diesem Ansatz?Haben Sie eine bessere Idee?

Bisherige Lösung

Ich habe beschlossen, mein eigenes Schema zu erstellen und benutzerdefinierte Mitgliedschafts- und Rollenanbieter zu implementieren.Mein Schema umfasst;

• Benutzer
• Benutzerprofil
• Erlaubnis
• Berechtigungszuweisung
• Rolle
• Rollenzuweisung

Ich werde in den nächsten ein oder zwei Tagen abwesend sein, werde aber bei Gelegenheit weitere Informationen liefern.

Answer 1

Ich denke, Sie sollten Rollen im Autorisierungsmechanismus vergessen und stattdessen nach Berechtigungen fragen (am Ende ist eine Rolle eine Gruppe von Berechtigungen). Wenn Sie es also so sehen, sind Sie es Authorize Das Attribut sollte nach einer Entität und Aktion fragen, nicht nach einer bestimmten Rolle.Etwas wie:

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

Auf diese Weise tun Ihre Rollen das, was sie am besten können: die Sammlung von Berechtigungen zu abstrahieren, anstatt eine unflexible Art der Zugriffsebene festzulegen.

BEARBEITEN: Um bestimmte Regeln wie die von David Robbins zu handhaben, ist es Manager A nicht gestattet, von Manager B erstellte Nachrichten zu löschen. Vorausgesetzt, dass beide über die erforderliche Berechtigung für den Zugriff auf diese Controller-Aktion verfügen, ist die Autorisierung nicht dafür verantwortlich, diese Art von Regeln zu überprüfen. und selbst wenn Sie versuchen, dies auf Aktionsfilterebene zu überprüfen, wird es mühsam sein. Sie können also die Authorize-Validierung auf das ActionResult erweitern (indem Sie einen Aktionsparameter einfügen, der das Validierungsergebnis enthält) und das ActionResult die logische Entscheidung treffen lassen Da sind alle Argumente vorhanden.

Das ist eine ähnliche Frage, ist nicht genau der Fall, auf den hier hingewiesen wird, aber es ist ein guter Ausgangspunkt für die Erweiterung der Authorize-Validierung mit Aktionsparametern.

Answer 2

In Bezug auf Ihr CruD-Beispiel sprechen Sie nicht wirklich von der Ermächtigung, und würde die Genehmigung zwischen dem Mitgliedschaftsprogramm "Manager" und "Reporter" variieren?Ich denke, Sie müssen einen separaten Mechanismus für alle feineren körnigen Aktivitäten erstellen, wenn die Rollen nicht zwischen einer Lese- und Schreibautorisierung zwischen Nachrichten unterscheiden.

Wenn Sie für jede Aktion eine Rolle erstellen sollten - EditMessage, deletemessage - Was werden Sie tun, wenn Manager A Meldungen für Manager B löschen kann?

Answer 3

sowie das Hinzufügen von generationspoDicetagcode usw. über Ihrem Controller.Sie können auch dieses Attribut auf die individuellen Aktionen auch

setzen