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

Question

Ich bin fast herauszufinden, wie die verschiedenen Teile einer Authentifizierung und Autorisierung Server-Architektur arbeiten. 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 - wie im OpenID Connect-Protokoll angegeben - mithilfe von OAuth 2.0-Flows an Clients angefordert. Ein Flow für jeden Kunden.
3. Während des Flow-Beginns fordert der Client eine Sammlung von Bereichen an (mindestens "openid", da er angeben muss, dass ein OpenID Connect-Flow aktiviert wurde)
4. Ein Client kann alle Bereiche fragen, ob er berechtigt ist 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, sofern er autorisiert wurde, in einem Claim 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 richtig ist, hier sind meine Fragen:

1. wie sind Ansprüche auf asp.net Identität Tabellen definiert (dh AspNetUserClaims) mit den IdentityServer diejenigen . 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. Bezug nehmend 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 fehlt mir?

3. nehmen wir an, dass in meinem Ressource-Server ich eine Aktion haben wie diese mit einem ResourceAuthorize Attribut geschützt:

   [ResourceAuthorize ("Read", "Orders")]

   In meinem AuthorizationManager ich prüfen Vorhandensein eines Anspruchs "order_read" oder eines Anspruchs "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 tun sollte. 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: Wenn meine Anwendung den Access Token präsentiert, wie wird die ClaimsIdentity generiert? 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

Answer 1

Ja, Sie haben das Wesentliche davon. Wie für Ihre Fragen:

wie definiert sind Ansprüche auf asp.net Identität Tabellen

Das liegt an dir. IdentityServer fordert keine Identitätsverwaltungsbibliothek an. Der Erweiterbarkeitspunkt IUserService ist der Ort, an dem Sie diese Lücke überbrücken. Wir haben eine Starter-Version von IUserService, aber es ist ein Code-basiertes NuGet, so dass Sie es ändern können, um wirklich zu tun, was Sie brauchen.

Ich kann nicht verstehen, was mein Mandant mit dem id_token tun sollte

Es wird hauptsächlich verwendet, zurück zu IdentityServer bei signout Zeit zu vertreiben (die signout Anforderung zu authentifizieren).

wenn meine Anwendung des Access Token präsentiert, wie der ClaimsIdentity wird

erzeugt

Es gibt Middleware (AccessTokenValidation) das Zugriffstoken zu validieren. Das Ergebnis sind die Ansprüche aus dem Token, die dann in eine ClaimsIdentity umgewandelt werden und dann für jede nachgeschaltete Verarbeitung (wie Ihren Web-API-Code) verfügbar gemacht werden.

, was die Bedeutung der „ClientClaims“ Tabelle ist

Die Client Konfiguration hat eine Claims Eigenschaft, wenn Sie, im Namen des Kunden erteilen mögen. Überprüfen Sie die Dokumentation: https://identityserver.github.io/Documentation/docsv2/configuration/clients.html

nehmen wir an, dass in meinem Ressource-Server ich eine Aktion habe mit einem ResourceAuthorize Attribut geschützt wie dieses

Dies ist in keinem Zusammenhang mit IdentityServer, und ist Teil der IdentityModel Bibliothek. ResourceAuthorize ist ein Framework für die Verwendung des Benutzers, der Ressource und der Aktion, die bei der Entscheidung über das Autorisierungsergebnis berücksichtigt werden.