it-swarm.com.de

Sollte es ein Anspruch, eine Rolle oder eine Politik sein?

Der Unterschied zwischen Rollen und Ansprüchen besteht darin, dass Rollen eine Gruppe von Benutzern beschreiben und Ansprüche eine Eigenschaft eines Benutzers beschreiben. Es kann also eine Rolle "Administrator" geben, aber es kann auch eine Behauptung "HasElevatedPrivilegeBadge" geben. Beide können dieselbe Aktion zulassen. Welches soll ich jetzt auswählen, wenn ich nur bestimmten Personen erlauben möchte, bestimmte Dinge zu tun, zum Beispiel:

CanAddItem, CanUpdateItem, CanDeleteItem,
CanAddProduct, CanUpdateProduct, CanDeleteProduct

Ich könnte die Rolle "Administrator" erstellen und die Ansprüche "CanAddItem", "CanUpdateItem" usw. hinzufügen, aber "CanAddItem" beschreibt keine Eigenschaft eines Benutzers. Es heißt, was der Benutzer tun kann, was ein Anspruch nicht tun sollte, oder?

Ein anderer Ansatz besteht darin, Richtlinien zu erstellen, z.

policy.AddPolicy("CanAddItem", policy => {
    policy.RequireAuthenticatedUser()
          .RequireRole("Administrator");
});

Aber für mehr als 20 Richtlinien wird ein guter Teil meiner Startup Klasse benötigt. Gibt es eine andere Möglichkeit, oder ist eine davon die bevorzugte?

Ich möchte darauf hinweisen, dass ich speziell nach einer Lösung für .Net Core Identity suche. Ich frage nach einer Lösung, wie ich meine Anforderungen in die vom Framework bereitgestellten Identitätstabellen einfügen kann.

5
FCin

Im Wesentlichen beschreiben Sie eine Zuordnung von Rolle zu Berechtigung.

Ich denke, dies wird weitgehend durch den Standard [Authorize (Role = xxx)] für Ihre Controller-Aktionen abgedeckt, bei dem die implizite Berechtigung CanExecuteThisAction lautet. Es sind keine zusätzlichen Richtlinien erforderlich, da diese lediglich als Zuordnung dienen, das Problem möglicherweise verwirren und, wie Sie sagen, viel Code für das Boilerplate hinzufügen.

Die Richtlinien scheinen auf kompliziertere Berechtigungen ausgerichtet zu sein, bei denen Sie eine Logik für die Ansprüche oder andere Eigenschaften des Benutzers ausführen müssen. Das Beispiel ist die AtLeast21-Richtlinie, bei der der Anspruch des Benutzers ein Geburtsdatum ist.

Sie würden vermutlich benutzerdefinierte AuthorizeAttribute-Klassen ersetzen.

Ich würde sie nicht verwenden, wenn das Standardattribut "Autorisieren" alleine damit umgehen kann, z. B. bei der Rollenprüfung.

4
Ewan

Ich könnte die Rolle "Administrator" erstellen und die Ansprüche "CanAddItem", "CanUpdateItem" usw. hinzufügen, aber "CanAddItem" beschreibt keine Eigenschaft eines Benutzers.

Abhängig von Ihrer Sichtweise ist Ihr Beispiel möglicherweise etwas zu pragmatisch.

Unter einem anderen Gesichtspunkt ist eine Person, die 21 Jahre alt ist, ebenfalls volljährig zum Trinken, aber sie ist nicht kann Alkohol trinken richtig?

Zurück zu Ihrem Beispiel, was ist der Unterschied zwischen `Product Creator, Product Changer und Ihren Beispielen? Für mich ist es nur der Standpunkt, wobei einer genauer beschreibt, was sie sind und was sie tun können ... obwohl es wirklich dasselbe ist wenn es um Ihren Anspruch geht.

1
Erik Philips

Ich entscheide mich im Allgemeinen für Richtlinien, da diese eine detaillierte und ausdrückliche Kontrolle über die Autorisierung ermöglichen. Um die Bedenken auszuräumen, dass sie Speicherplatz in der Startup-Klasse belegen, können Sie die Richtlinien in eine statische Klasse aufteilen.

internal static class Policies
{
  public static void CanAddItem(AuthorizationPolicyBuilder policy)
  {
    policy.RequireAuthenticatedUser()
      .RequireRole("Administrator");
  }
}

Und dann ist in Startup.cs die Registrierung jeder Richtlinie ein Einzeiler

services.AddAuthorization(options =>
{
  options.AddPolicy(nameof(Policies.CanAddItem), Policies.CanAddItem);
});

Wenn Sie noch mehr Kontrolle benötigen, können Sie einen benutzerdefinierten IAuthorizationPolicyProvider hinzufügen, mit dem Sie Richtlinien programmgesteuert auflösen können.

https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/iauthorizationpolicyprovider?view=aspnetcore-2.1

1
Eric Damtoft

Haftungsausschluss: Ich habe noch nie Richtlinien verwendet. Ich denke, die Antwort auf Ihr Problem hängt auch von dem Identitätsanbieter ab, den Sie verwenden. Wenn der Identitätsanbieter nicht Ihre eigene Anwendung ist, sondern ein Identitätsanbieter eines Drittanbieters OR ein standardisiertes Produkt wie Identitätsserver 4, wäre die Verwendung von Rollen und Ansprüchen besser, da OAUTH/openidconnect funktionieren kann mit Rollen/Ansprüchen nativley.

Wir verwenden ein Schema wie Ihr Schema, aber leichte Wendungen: 1. Wir haben mehrere Rollen, z. ein Administrator, itemManager und ein Benutzer. 2. Wir haben Ansprüche wie "item.add", "item.delete", "item.create". 3. Jede Rolle kann N Ansprüche haben. 4. Jeder Benutzer kann N Rollen haben. Dies ermöglicht eine Menge Kompositionsfähigkeit, z. Ein Benutzer kann den Anspruch "item.delete" erhalten, weil er ein Administrator ist oder weil er ein itemManager ist.

Es ist wichtig, dass die Anspruchsnamen etwas standardisiert sind und dass ihre Granularität für Ihre Anwendung geeignet ist. Wenn beispielsweise das Recht zum Erstellen und Aktualisieren eines Elements logisch verbunden ist, erstellen Sie nur einen Anspruch, nicht zwei.

Darüber hinaus können Sie Rollen verwenden, um ein wenig Geschäftslogik einzufügen, z. B. product.maxnumber.200 => Der Benutzer kann nur bis zu 200 Produkte haben, die von Ihrer Geschäftslogik validiert werden müssen.

Schließlich haben mehrere Sicherheitspapiere, die ich in den letzten Monaten gelesen habe (OWASP), empfohlen, die Autorisierung neben Ihre Geschäftslogik zu stellen, da häufig die Frage "Kann der Benutzer das tun?" muss im Kontext der Geschäftslogik beantwortet werden: "Hat der Benutzer die Rollen product.add UND hat er weniger als product.maxnumber Produkte?" -> Ein solcher Kontext ist in einer bestimmten Anfrage leicht zu erhalten, aber im Allgemeinen schwer zu beantworten, wie in Richtlinien.

0
Christian Sauer