IdentityServer 3 + Asp.net Identity: Bereiche, Ansprüche und Kunden - Erläuterungen

Ich habe fast herausgefunden, wie die verschiedenen Teile einer Authentifizierungs- und Autorisierungsserver-Architektur funktionieren. Ich denke wirklich, dass IdentityServer eine großartige Software ist.

Ich versuche meine Entdeckungen zusammenzufassen, um eine Basis für meine Fragen zu finden.

1. IdentityServer gibt Token mit OpenID Connect aus. Ausgegebene Token sind ID-Token und Access-Token.
2. Tokens werden gemäß dem OpenID Connect-Protokoll mithilfe von OAuth 2.0-Flows an Clients angefordert. Ein Flow für jeden Client.
3. Während des Flow-Beginns fordert der Client eine Sammlung von Bereichen an (mindestens "openid", das heißt, er muss angeben, dass ein OpenID Connect-Flow aktiviert wurde)
4. Ein Kunde kann alle Bereiche fragen, zu denen er berechtigt ist zu fragen. Mit dem Entity Framework-Plugin für IdentityServer sind diese Informationen in der ClientScope-Tabelle enthalten. Wenn der Client einen Bereich anfordert, den er nicht anfordern darf, wird der Ablauf unterbrochen.
5. Bereiche können Ansprüche enthalten. Dies bedeutet, dass, wenn ein Bereich eine Gruppe von Ansprüchen enthält, dieser Token bei jeder Ausgabe eines Tokens durch den Client auch alle entsprechenden Ansprüche des Benutzers enthält. Zum Beispiel: Lassen Sie "Rollen" einen Bereich aufrufen, der den Anspruch "Rolle" enthält. Sobald der Client autorisiert ist, enthält das empfangene Token alle Benutzerrollen (als Ansprüche).
6. Jeder angeforderte Bereich wird, falls er genehmigt wurde, in einem Anspruch mit dem Namen "scope" "übersetzt". Dies bedeutet, dass, wenn ein Client beispielsweise einen definierten "api" -Bereich anfordert, die generierte Identität mindestens einen Anspruch namens "scope" mit dem Wert "api" haben wird.

Wenn alles, was ich geschrieben habe, mehr und weniger korrekt ist, hier sind meine Fragen:

1. Wie werden Ansprüche in ASP.net-Identitätstabellen (d. h. AspNetUserClaims) definiert, die mit den IdentityServern verbunden sind. Für das, was ich gesehen habe, wird der Abgleich auf den Namen gemacht. Ist diese Schlussfolgerung richtig? Mit anderen Worten, wenn mein Kunde eine "Rolle" Ansprüche erhalten muss (weil er nach dem Bereich "Rollen" gefragt hat), wird das "Asp.Net Identity" Plugin für IdentityServer nur die für die Authentifizierten definierten "Rolle" Ansprüche freigeben Benutzer?
2. Verweis auf die "EntityFramework" -Plugintabellen, was bedeutet die Tabelle "ClientClaims"? Ich kann nicht verstehen, wie Ansprüche direkt mit dem Kunden verbunden werden können ... Was vermisse ich?

3. Nehmen wir an, dass ich in meinem Ressourcenserver eine Aktion mit einem ResourceAuthorize-Attribut wie folgt geschützt habe:

   [ResourceAuthorize ("Lesen", "Aufträge")]

   In meinem AuthorizationManager überprüfe ich das Vorhandensein eines Claims "order_read" oder eines Claims "api". Dies sind zwei verschiedene Bereiche, die in meinem AuthorizationServer definiert sind, einer für "Order Reading" und der letzte für einen vollständigen API-Zugriff. Der erste kann von Drittkunden gestellt werden, während der zweite nicht. Ist das eine gute Übung?

4. Ich kann nicht verstehen, was mein Klient mit dem id_token machen soll. Sollte ich das Problem ignorieren, da ich den OIDC-Token-Manager der js-Bibliothek verwende? Werden die Sicherheitskontrollen von dieser Bibliothek durchgeführt?

5. Letzte Frage: Wie wird die ClaimsIdentity generiert, wenn meine Anwendung den Access Token präsentiert? Ist es richtig zu sagen, dass es nach der Validierung des Tokens auf dem Identity Server generiert wurde? Bedeutet dies, dass IdentityServer das Zugriffstoken erhält und es in eine Reihe von Ansprüchen übersetzt?

Danke für Ihre Klarstellungen!

Marco