Rollenbasierte Zugriffssteuerung (RBAC) vs. Anspruchsbasierte Zugriffssteuerung (CBAC) in ASP.NET MVC

Werde ich versuchen zu zeigen, wie Sie profitieren können von Anspruch Based Access Control in einem ASP.NET MVC Kontext.

Wenn Sie mit Rollen-basierte Authentifizierung wenn Sie eine Aktion für das erstellen von Kunden-und Sie wollen, dass die Menschen, die in den 'Sale' - Rolle sollte in der Lage sein, das zu tun, dann schreiben Sie code wie diesen:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Später, Sie erkannte, dass, manchmal, die Leute von 'Marketing' Rolle sollte in der Lage sein, um Kunden. Dann aktualisieren Sie Ihre Action-Methode wie

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Nun, Sie erkannte, dass einige der die marketing-Leute müssen nicht in der Lage sein, die Erstellung von Kunden -, aber es ist nicht möglich, weisen Sie eine unterschiedliche Rolle für die Menschen, die in Marketing. Also, sind Sie gezwungen, um zu ermöglichen, dass alle marketing-Menschen zu erstellen, die Kunden.

machtest du ein anderes problem, wenn Sie entscheiden, dass Marketing-Menschen erlaubt sein sollte, erstellen Sie Kunden, Sie haben sich das update von MVC Action-Methoden Autorisieren Attribut, Ihre Anwendung kompilieren, testen und bereitstellen. Einige Tage später, Sie beschlossen, keine marketing-sondern eine andere Rolle, erlaubt sein sollte, die Aufgabe zu tun, so suchen Sie in Ihrer Codebasis und löschen Sie alle 'Marketing' von der Genehmigen-Attribut und fügen Sie Ihre neue Rolle Namen Ermächtigen, Attribut... Keine gesunde Lösung. An diesem Punkt, würden Sie feststellen, eine Notwendigkeit für die Erlaubnis-Basierte Zugriffskontrolle.

Permission-Based access control ist eine Möglichkeit der Zuweisung verschiedener Berechtigungen für die verschiedenen Benutzer und die überprüfung, ob ein Benutzer die Berechtigung zum ausführen einer Aktion mit dem code in der Laufzeit. Weisen Sie, nachdem Sie verschiedene Berechtigungen für die verschiedenen Benutzer, die Sie erkennen, dass Sie brauchen, um zu ermöglichen, dass einige Benutzer zum ausführen von code, wenn der Benutzer irgendeine Eigenschaft wie "Facebook Nutzer", "Langzeit-User" etc. Lassen Sie mich ein Beispiel geben. Sagen Sie, dass Sie möchten, um Zugriff zu einer bestimmten Seite, wenn der Benutzer angemeldet ist mit Facebook. Nun würde erstellen Sie eine Berechtigung, 'Facebook' für die Benutzer ? Nein, 'Facebook' klingt nicht nach einer Berechtigung. Tut es das ? Eher klingt es wie eine Behauptung. Zur gleichen Zeit, Berechtigungen klingen kann, wie der Anspruch zu !! Also, es ist besser, zu prüfen, für die Ansprüche und erlauben den Zugriff.

Jetzt, lets go zurück zu dem konkreten Beispiel der Anspruch based access control.

Können Sie definieren einen Satz von Behauptungen wie dieser :

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer".. etc..

Jetzt können Sie dekorieren Sie Ihre Action-Methode wie diese:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(bitte beachten, [ClaimAuthorize(Permission="CanCreateCustomer")] kann nicht gebaut werden, in MVC-Klassenbibliothek, ich bin gerade zeigen, als ein Beispiel, können Sie eine Bibliothek-Klasse, die hat solches Attribut class definition)

Nun, Sie können sehen, dass, CreateCustomer action-Methode muss immer die Erlaubnis 'CanCreateCustomer' und es wird sich niemals ändern oder sich kaum ändern. So, in Ihrer Datenbank erstellen Sie eine Tabelle von Berechtigungen (claims) und Benutzer-Berechtigung-relation. Aus Ihrem admin-panel, können Sie Berechtigungen festlegen (Anspruch) für jeden Benutzer, der das tun kann, was. Sie können zuweisen 'CanCreateCustomer' Erlaubnis (sich behaupten) zu jedermann, das Sie mögen und nur zugelassenen Benutzer werden in der Lage sein, um Kunden und zugelassenen Benutzer werden in der Lage sein zu erstellen, die nur der Kunde und sonst nichts (es sei denn, Sie weisen andere Berechtigungen für den gleichen Benutzer).

Dieses Sicherheitsmodell bietet Ihnen saubere code die Praxis. Außerdem, wenn Sie schreiben Sie Ihre Action-Methode, die Sie nicht zu denken haben, können diese Methode verwenden, sondern können Sie immer sicher sein, dass, wer ist mit dieser Methode wird über die entsprechende Genehmigung (Anspruch) gegeben durch den Admin. Dann kann der Admin entscheiden, wer wird in der Lage sein, das zu tun, was. Nicht Sie als Entwickler. Das ist, wie Sie Ihre business-Logik getrennt von Sicherheits-Logik.

Immer, wenn jemand sich anmeldet, kann Ihre Anwendung überprüfen, was sind die Berechtigungen für diesen Benutzer und Berechtigung (Anspruch) gesetzt werden als zusätzliche Eigenschaften des aktuell angemeldeten Benutzers (in der Regel die Forderung set gespeichert ist, als cookie für den eingeloggten Benutzer), so dass Sie nicht haben, um zu überprüfen Berechtigungssatz, der die ganze Zeit aus der Datenbank. Die bottom line ist, erhalten Sie mehr Kontrolle über Ihre Sicherheit Logik in Ihrer Anwendung, wenn Sie sich bewerben Anspruch based access eher als role based access. In der Tat, eine Rolle kann auch als ein Anspruch zu.

Wenn Ihre Anwendung ist eine sehr kleine Anwendung, wo es nur 2 Rollen : Kunde und Admin und es gibt keine chance, dass der Kunde in der Lage sein, zu tun nichts anderes als was Sie gemeint sind zu tun, in Ihrer Anwendung haben, dann vielleicht, Role based access control wird dem Zweck dienen, aber Ihre Anwendung wächst, werden Sie beginnen zu fühlen, die Notwendigkeit des claim-based access control, irgendwann.

InformationsquelleAutor der Antwort Emran Hussain

Akzeptiert die Antwort scheint zu position Rollen als bloßes Objekt und Behauptet, als ein flexibles Werkzeug, aber sonst macht Sie scheinen fast identisch. Leider ist diese Positionierung macht einen Bärendienst, um das Konzept der Forderungen und kann grundsätzlich reflektieren einen leichten Missverständnis von Ihren Zweck.

Rollen existieren und Sinn machen nur in einem impliziten scope. In der Regel ist das eine Anwendungs-oder organisatorischen Bereichs (d.h. Role=Administrator). Ansprüche, auf der anderen Seite, können 'gemacht' von jemand. Zum Beispiel, Google-Authentifizierung möglicherweise produzieren Ansprüchen, einschließlich eines Benutzers "E-Mail", so anbringen, dass die E-Mail an eine Identität. Google macht die Behauptung, die Anwendung entscheidet, ob Sie verstehen und akzeptieren, dass Anspruch. Die Anwendung selbst kann anschließend befestigen Sie einen Anspruch als "authenticationmethod" (als ASP.NET MVC-Kern-Identität bedeutet) mit einem Wert von "Google". Jeder Anspruch beinhaltet einen Rahmen, so dass es möglich zu identifizieren, ob ein Antrag Sinn hat, extern, lokal, oder beide (oder mehr feinkörnigen, wie gebraucht.)

Die wichtigsten Punkte sind, dass alle Ansprüche werden ausdrücklich beigefügt, um eine Identität und eine explizite scope. Diese Forderungen können natürlich für die Autorisierung verwendet werden - und ASP.NET MVC bietet Unterstützung für die, die über " aktivieren Attribut, aber das ist nicht die einzige oder zwangsläufig sogar primäre Zweck, für Ansprüche. Es ist sicherlich nicht die Unterscheidung von Rollen, die verwendet werden können, in genau der gleichen Weise für die lokal gültigen Genehmigung.

So kann man wählen, die Sie verwenden Rollen, oder Ansprüche, oder beide für den Zweck der Bewilligung und wahrscheinlich finden die keine inhärente Vorteil oder Nachteil entweder, so lange, wie die Rollen und die Ansprüche sind lokal beschränkt. Aber wenn, zum Beispiel, Genehmigung hängt von externen Identität behauptet, dann Rollen unzureichend. Sie würden akzeptieren müssen, die externe Forderung und übersetzen es in ein lokal gültigen Rolle. Es ist nicht unbedingt etwas falsch mit, dass, aber es bringt eine Schicht der Dereferenzierung und verwirft Kontext.

InformationsquelleAutor der Antwort hemp

Den grundlegenden zwischen RBAC und CBAC ist, dass:

RBAC: ein Benutzer muss einer Rolle zugeordnet sein, die Berechtigung zum ausführen einer Aktion.

CBAC : Benutzer muss einen Anspruch mit dem richtigen Wert, wie erwartet, von der Anwendung autorisiert sein. Claims-based access control ist elegant zu schreiben und einfacher zu verwalten.

Neben die Ansprüche, die ausgegeben werden, um die Anwendung von einer ausstellenden autorisieren, Dienste (Security Token Service, STS), der man vertraut, durch Ihre Anwendung (Relying Party)

InformationsquelleAutor der Antwort Benjamin Nguyen

Ist es wichtig, zunächst zu analysieren, was die Authentifizierung erforderlich ist, bevor Sie entscheidet, welche Methode am besten ist. Aus der Microsoft-Dokumentation unter, es sagt "Ein Anspruch ist nicht, was die Person tun kann. Zum Beispiel, können Sie haben einen Führerschein, ausgestellt von einem örtlichen Führerschein-Behörde. Ihr Führerschein wurde Ihr Geburtsdatum auf. In diesem Fall ist der Anspruch würde der name DateOfBirth, die behaupten, es wäre Wert Ihr Geburtsdatum ein, zum Beispiel 8. Juni 1970 und der Emittent würde die Führerschein-Behörde. Claims based authorization, im einfachsten Fall prüft der Wert der Forderung und ermöglicht den Zugriff auf eine Ressource basierend auf diesem Wert. Zum Beispiel, wenn Sie möchten, den Zugang zu einem Nachtclub, der autorisierungsvorgang werden:6"
Die Tür security officer bewerten würde den Wert des Geburtsdatums behaupten, und ob Sie Vertrauen in die Emittenten (die Führerschein-Behörde) bevor Sie Zugriff.

Aus diesem Beispiel können wir sehen, dass der Zugriff auf eine nahezu club mit einer Claims-Based Authorization beenden unterscheidet sich von der Art der Autorisierung, die erforderlich sind, das Personal, die arbeiten in der Nacht-club, in diesem Fall die Mitarbeiter der Nacht-club erfordern eine rollenbasierte Autorisierung ist nicht erforderlich für die Nacht-club-Besucher wie die Nacht-club-Besucher haben alle einen gemeinsamen Zweck in der Nacht club daher in dieser situation eine anspruchsbasierte Autorisierung ist geeignet für die Nacht-club-Besucher.

Rollenbasierte Autorisierung
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles
10/14/2016
Wenn eine Identität erschaffen, die es können, gehören zu einer oder mehreren Rollen zu. Zum Beispiel, Tracy gehört wohl zu den Administrator-und Benutzer-Rollen, während Scott kann nur angehören, um der Rolle des Benutzers. Wie werden diese Rollen angelegt und verwaltet werden, hängt von der sicherungsspeicher der Autorisierung. Rollen ausgesetzt sind, haben die Entwickler durch die IsInRole-Methode für die Klasse "claimsprincipal".

Claims-Based Authorization
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims
10/14/2016
Wenn eine Identität ist erstellt, es können beauftragt werden, einen oder mehrere Ansprüche, ausgestellt von einer vertrauenswürdigen Partei. Ein Anspruch ist name-Wert-paar, das das repräsentiert, was das Thema ist, nicht, was die Person tun kann. Zum Beispiel, können Sie haben einen Führerschein, ausgestellt von einem örtlichen Führerschein-Behörde. Ihr Führerschein wurde Ihr Geburtsdatum auf. In diesem Fall ist der Anspruch würde der name DateOfBirth, die behaupten, es wäre Wert Ihr Geburtsdatum ein, zum Beispiel 8. Juni 1970 und der Emittent würde die Führerschein-Behörde. Claims based authorization, im einfachsten Fall prüft der Wert der Forderung und ermöglicht den Zugriff auf eine Ressource basierend auf diesem Wert. Zum Beispiel, wenn Sie möchten, den Zugang zu einem Nacht-club der Autorisierungs-Prozess könnte sein:

Die Tür security officer bewerten würde den Wert des Geburtsdatums behaupten, und ob Sie Vertrauen in die Emittenten (die Führerschein-Behörde) bevor Sie Zugriff.

Einer Identität enthalten kann, die mehrere Ansprüche mit mehreren Werten und kann mit mehreren Forderungen des gleichen Typs.

InformationsquelleAutor der Antwort CodingSoft

Ist es auch möglich, verwaltet Rollen in einer Weise Ansprüche.

Erstellen, anstatt die Genehmigung Rollen, die eine business-Rolle, Rollen erstellen, reflektieren, dass action-Rollen, z.B. CreateCustomer, EditCustomer, DeleteCustomer. Kommentieren von Methoden erforderlich.

Es ist nicht eine einfache Sache zu anzeigen Individuen auf eine Reihe von action-Rollen, vor allem als die Rolle, die Liste wird größer. Daher, Sie müssen, um die Rollen auf einer niedrigeren Ebene der Granularität (z.B. Vertrieb, Marketing) und anzeigen der Benutzerrolle zu den action-Rollen erforderlich. I. e., fügen Sie einem Benutzer eine Benutzerrolle, und es ordnet Sie die erforderlichen (Maßnahmen) - Rollen in der bestehenden Ermächtigung Tisch.

Sie können auch überschreiben Sie die Benutzerrolle, und fügen Sie eine person auf eine Aktion, die Rolle direkt.

Weil Sie bauen auf, was bereits funktioniert, sind Sie nicht rückgängig machen, die bestehenden Zulassungsverfahren. Sie müssen nur ein paar mehr Tabellen, um diesen Ansatz zu implementieren

InformationsquelleAutor der Antwort pixelda