asp.net 5 und IdentityServer4

Question

Ich arbeite an einem Prototyp für eine Website Re-Architektur mit ASP.NET 5 und debattiere mit IdentityServer4 für meine Authentifizierung und Autorisierung. Ich habe eine Menge Beispiele und Artikel über die Einrichtung von IdentityServer3 und 4 gelesen und versuche, mich einzukapseln, wenn es die Anforderungen meines Kunden richtig erfüllt. Hier sind meine Anforderungen.

Ich habe 3 Websites, die eine Genehmigung benötigen. Site 1 (abc.com) erfordert eine Windows-Authentifizierung und ist eine Kombination aus mvc- und webapi-Aufrufen, die Rollen (oder Rollen, die in Ansprüche konvertiert wurden) für die Autorisierung darstellen. Site 2 (def.com) ist eine vertrauenswürdige Site, die ein Login-Widget mit einem Benutzernamen/Passwort/Rememberme-Textfeld auf ihrer Site haben möchte, das den Benutzer bei der Übermittlung authentifizieren und an Site 3 (xyz.com) umleiten wird. Seite 3 wird auch eine eigene Anmeldeseite haben und eine Kombination aus mvc- und webapi-Anrufen unter Verwendung von Ansprüchen sein. Site 2 und 3 verwenden keine Windows-Authentifizierung und der Client möchte nicht, dass sie zum Anmeldebildschirm des Identitätsservers umleiten, sondern ihren eigenen Anmeldebildschirm haben und den Identitätsserver aus Code mit den Anmeldeinformationen zum Anmelden aufrufen.

Hier sind meine Fragen zu diesem Szenario und IdentityServer4.

1. Kann Idsvr4 einen Client mit Windows-Authentifizierung und einen anderen mit Benutzername/Passwort-Authentifizierung behandeln?
   • Wenn ja, gibt es einen Grund Fenster Auth in idsvr4 zu haben oder sollte es verwendet nur Standard Fenster Auth in der Webapp?

2. Kann idsvr4 eingerichtet werden, der Kunde hat die Benutzername/Passwort/rememberme Werte und geben sie durch den Code zu bekommen die richtigen jwt Token für beide mvc und WebAPI sammeln?

   • Wenn ja, kann es sie beide log in die mvc und WebAPI Anwendungen, die auf einem anderen Standort?

   • Wenn ja, ist dies eine Umgehung der eigentliche Zweck von identityserver4 und ist daher eine schlechte Idee?

3. Wenn dieses Szenario umgehen kann und ist eine gute Idee, wie würden ich Setup des Client, Bereiche und Code, um die Login über Code zu behandeln umzuleiten?

Beispiele sind groß und sehr willkommen, aber ich bin nicht einmal sicher, welche Wortschwall für dieses Szenario in die richtige Richtung mich so suchen, um zu verwenden, auch eine große Hilfe sein würde.

Answer 1

Nicht sicher, ob diese Frage noch aktiv ist. Aber ja, ich glaube, du kannst das alles machen.

1) Sie können Setup die LDP für jeden Kunden zur Verfügung steht durch IdentityProviderRestrictions auf dem Client-Einstellung (docs)

1,1) - Nicht sicher, was du meinst, ich glaube einer der Punkte, der mit idsrv ist sentralize Sie Authentifizierung, und es macht es für zukünftige Websites einfacher, mit dem gleichen Dienst zu integrieren.

2) Wenn Sie sich mit einem Client (Anwendung) anmelden, geben Sie auch an, auf welche apiResource der Client zugreifen kann - und die Anwendung muss diese bei der Anmeldung zu den angeforderten Bereichen hinzufügen. Wenn Ihr Client die mvc-Anwendung ist , fügen Sie einfach die ApiResource in die AllowedScopes - und setzen Sie die request_type auf id_token code - dies würde dann dem Benutzer eine access_token geben, die mit jeder Anfrage an die Backend-API übergeben wird. (docs)

2.1) - Dies würde den Benutzer grundsätzlich auf beiden Seiten anmelden - mit einem Zugriffstoken, das besagt, dass der Benutzer berechtigt ist, die Backend-API zu verwenden.

2.2) - Meiner Meinung nach ist dieser Fluss eines der Dinge, die idsrv großartig machen - und sie erwähnen dies sogar als ein großartiges Feature von idsrv selbst. Sie benötigen nur einen Trip zum Authserver, um Zugang zu allen Systemen zu erhalten.

wie für pt. 3 - Sehen Sie sich die Dokumentation an und versuchen Sie, nach den Schnellstarts ein leeres Projekt einzurichten.

Um sich von Ihrer eigenen Login-Seite einzuloggen, müssen Sie den Grant-Typ Resource Owner password verwenden - obwohl sie dies aus Sicherheitsgründen nicht empfehlen (Übertragung von Passwörtern über die Leitung) - wird unterstützt.