Best Practices für Rollen im Vergleich zu Ansprüchen in ASP.NET Identity

Ich bin völlig neu in der Verwendung von claimsin ASP.NETIdentityund möchte eine Vorstellung von Best Practices bei der Verwendung von in bekommen Roles and/or Claims.

Nach all dem Lesen habe ich immer noch Fragen wie ...

F: Verwenden wir keine Rollen mehr?
F: Wenn ja, warum werden noch Rollen angeboten?
F: Sollten wir nur Ansprüche verwenden?
F: Sollten wir Rollen und Ansprüche zusammen verwenden?

Mein erster Gedanke ist, dass wir sie zusammen "verwenden" sollten. Ich sehe Claimsals Unterkategorien die Rolessie unterstützen.

BEISPIEL:
Role: Accounting
Ansprüche : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

F: Sollen sie sich gegenseitig ausschließen?
F: Oder ist es besser, NUR Ansprüche geltend zu machen und Ihre Ansprüche "vollständig zu qualifizieren"?
F: Was sind hier die besten Praktiken?

BEISPIEL: Rollen und Ansprüche zusammen verwenden
Natürlich müssten Sie dafür Ihre eigene Attributlogik schreiben ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

BEISPIEL: Vollständige Qualifizierung Ihrer Ansprüche

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

Eine Rolle ist eine symbolische Kategorie, in der Benutzer mit denselben Sicherheitsberechtigungen zusammengefasst werden. Die rollenbasierte Autorisierung erfordert zunächst die Identifizierung des Benutzers, die Ermittlung der Rollen, denen der Benutzer zugewiesen ist, und den Vergleich dieser Rollen mit den Rollen, die zum Zugriff auf eine Ressource berechtigt sind.

Im Gegensatz dazu basiert ein Anspruch nicht auf einer Gruppe, sondern auf einer Identität.

aus der Microsoft-Dokumentation :

Wenn eine Identität erstellt wird, können ihr ein oder mehrere Ansprüche zugewiesen werden, die von einer vertrauenswürdigen Partei ausgestellt wurden. Ein Anspruch ist ein Name-Wert-Paar, das darstellt, was das Subjekt ist, nicht was das Subjekt tun kann.

Eine Sicherheitsüberprüfung kann später das Recht auf Zugriff auf eine Ressource basierend auf dem Wert eines oder mehrerer Ansprüche bestimmen.

Sie können beide gemeinsam verwenden oder einen Typ in bestimmten Situationen und den anderen in anderen Situationen verwenden. Dies hängt hauptsächlich von der Interaktion mit anderen Systemen und Ihrer Managementstrategie ab. Beispielsweise kann es für einen Manager einfacher sein, eine Liste von Benutzern zu verwalten, die einer Rolle zugewiesen sind, als zu verwalten, wem ein bestimmter Anspruch zugewiesen ist. Ansprüche können in einem RESTful-Szenario sehr nützlich sein, in dem Sie einem Kunden einen Anspruch zuweisen können und der Kunde dann den Anspruch auf Autorisierung vorlegen kann, anstatt den Benutzernamen und das Kennwort für jede Anforderung zu übergeben.

Wie @Claies perfekt erklärt hat, könnten Behauptungen aussagekräftiger sein und spielen eine tiefe Rolle. Ich betrachte sie als Ihre Rollen-IDs. Ich habe einen Fitness-Ausweis, daher gehöre ich zur Rolle des Mitglieds. Ich bin auch im Kickboxunterricht, daher habe ich einen Kickbox-Ausweis für sie. Mein Antrag würde die Erklärung einer neuen Rolle benötigen, um meinen Mitgliedschaftsrechten zu entsprechen. Stattdessen habe ich IDs für jede Gruppenklasse, zu der ich gehöre, anstatt vieler neuer Mitgliedschaftstypen. Deshalb passen Ansprüche besser zu mir.

Es gibt ein großartiges Erklärungsvideo von Barry Dorrans, in dem über den Vorteil der Verwendung von Ansprüchen gegenüber Rollen gesprochen wird. Er gibt auch an, dass sich Rollen aus Gründen der Abwärtskompatibilität noch in .NET befinden. Das Video ist sehr informativ über die Funktionsweise von Ansprüchen, Rollen, Richtlinien, Autorisierung und Authentifizierung.

Sie finden es hier: ASP.NET Core Authorization mit Barr Dorrans

Nachdem ich über Jahrzehnte verschiedene Authentifizierungs- und Autorisierungstechniken verwendet habe, verwendet meine aktuelle MVC-Anwendung die folgende Methodik.

Ansprüche werden für alle Autorisierungen verwendet. Benutzern wird eine Rolle zugewiesen (mehrere Rollen sind möglich, aber ich brauche diese nicht) - mehr unten.

Wie allgemein üblich wird eine ClaimsAuthorize-Attributklasse verwendet. Da die meisten Controller-Aktionen CRUD sind, habe ich eine Routine in der Code-First-Datenbankgenerierung, die alle Controller-Aktionen iteriert und Anspruchstypen für jedes Controller-Aktionsattribut von Lesen / Bearbeiten / Erstellen / Löschen erstellt. ZB aus,

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

Zur Verwendung in einer MVC-Ansicht präsentiert eine Basis-Controller-Klasse Ansichtsbeutelelemente

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Für Website-Menüs und andere Nicht-Controller-Aktionen habe ich andere Ansprüche. ZB ob ein Benutzer ein bestimmtes Geldfeld anzeigen kann.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Wo passen also Rollen hin?

Ich habe eine Tabelle, die eine Rolle mit einem (Standard-) Satz von Ansprüchen verknüpft. Beim Festlegen der Benutzerberechtigung wird dem Benutzer standardmäßig die Ansprüche seiner Rolle mitgeteilt. Jeder Benutzer kann mehr oder weniger Ansprüche als die Standardansprüche haben. Um die Bearbeitung zu vereinfachen, wird die Anspruchsliste nach Controller und Aktionen (in einer Reihe) angezeigt, wobei andere Ansprüche aufgelistet werden. Schaltflächen werden mit etwas Javascript verwendet, um eine Reihe von Aktionen auszuwählen, um das "Klicken" zu minimieren, das zum Auswählen von Ansprüchen erforderlich ist. Beim Speichern werden die Ansprüche des Benutzers gelöscht und alle ausgewählten Ansprüche hinzugefügt. Die Webanwendung lädt Ansprüche nur einmal, sodass Änderungen zu einem erneuten Laden dieser statischen Daten führen müssen.

Manager können daher auswählen, welche Ansprüche in jeder Rolle enthalten sind und welche Ansprüche ein Benutzer hat, nachdem er sie auf eine Rolle und diese Standardansprüche festgelegt hat. Das System hat nur eine geringe Anzahl von Benutzern, sodass die Verwaltung dieser Daten unkompliziert ist

Um den Unterschied zwischen Rollen und Ansprüchen zu verstehen, müssen Sie sich mit der Einschränkung von Rollen auseinandersetzen und fühlen, wie Ansprüche über diese Probleme kommen. Ich möchte Ihnen zwei Szenarien geben, um die Macht von Ansprüchen zu erkennen, bei denen Rollen diese Probleme nicht lösen können:

1- Ihre Site muss aus zwei Modulen (Seiten, Service usw.) bestehen. Das erste Modul für Kinder (unter 18 Jahren) und das andere für Erwachsene (über 18 Jahre). Ihre Benutzeridentität hat einen Geburtstagsanspruch

Sie müssen eine Richtlinie für diesen Anspruch erstellen, damit die Berechtigung für jedes Modul für diesen Wert erteilt wird. Wenn das Alter des Benutzers die 18 Jahre überschreitet, kann er zum Erwachsenenmodul wechseln und nicht vor diesem Alter

Die Rolle ist ein boolescher Datentyp, den Sie haben können oder nicht. Die Rollenrolle hatte keine Malzwerte

2- Ihre Site hat einen Rollenbenutzer und Sie möchten den Zugriff von Benutzern nicht verhindern, um Wartungsarbeiten durchzuführen, ohne den Code zu ändern

In Ansprüchen können Sie eine UnderConstrain-Richtlinie erstellen, die, wenn der wahre Benutzer die Seite nicht anzeigen kann, die Eigenschaftsberechtigung für den Rollenbenutzer erteilt.