asp.net SSO und SAML von WebApi, einfach weil das alles der Klient ist

Question

Ich habe das geerbt und bin mit diesem Ansatz fest. Ich versuche nur herauszufinden, ob es tatsächlich funktioniert.

Das Projekt umfasst Ihre Standard-ASP.net Web-API-Anwendung mit Android und IOS-Clients. Der Trick ist mit der Authentifizierung. Die Anwendung ist für einen Drittanbieter und die einzige Möglichkeit, dass der Benutzer von der Außenwelt authentifiziert werden kann, ist die Verwendung seines IDP. Es ist dem Drittanbieter egal, was passiert, nachdem der Benutzer authentifiziert wurde. Alles, was ich zu tun habe, ist das Architekturdiagramm, das die ehemaligen Teammitglieder erstellt haben. Das Diagramm hat 3 Ebenen. Benutzer/mobiles Gerät, SAML SP Web APP und Client IDP. Der wichtige Teil des Ablaufs lautet wie folgt:

1. Mobile App ruft die SAML SP Web App mit dem IDP-Benutzernamen und dem Kennwort auf.
2. SAML Web App ruft die IDP-Anmeldung mit den Anmeldeinformationen des Benutzers auf
3. Benutzer Authentifiziert? Reagiert auf SAML SP Web App mit Erfolg und SAML Assertion/Token
4. SAML SP Web App reagiert auf mobile App mit genehmigten Nachricht

Sobald der Benutzer durch die IDP authentifiziert ist, war der Plan dann einen Träger zur Ausgabe von Token zum mobilen Gerät.

Es sei denn, die Dinge haben sich sehr verändert, seit ich zuletzt mit SAML (2011) gespielt habe, fehlt mir ein Client-Browser, um vom SP zum IDP umzuleiten und dann zurück zum SP bei einer gültigen SAMl-Assertion geschaffen.

Vermisse ich etwas hier, wie zum Beispiel eine Möglichkeit, einen Browser zu emulieren, um diese Weiterleitungen zu ermöglichen und den richtigen Benutzernamen und das Passwort einstecken, oder gibt es eine Möglichkeit, die IDP direkt aus dem SP aufrufen und es Problem haben eine Antwort direkt zurück zum SP? Oder lese ich gerade das Diagramm falsch oder vererbe einige sehr schlechte Annahmen? Ich bin in der unbeholfenen Position, in der ich nicht zum Kunden zurückkehren und einen Prozess, der Anfang des Jahres beschlossen wurde, wieder aufsuchen sollte, es sei denn, ich muss es unbedingt tun.

Answer 1

Mit SAML ändert sich nicht viel, so dass Ihr Wissen aus 2011 immer noch gültig ist.

Ich vermisse auch den Browser Redirect Schritt. Es ist ein häufiges Missverständnis, dass der SP Benutzernamen/Passwort an den Idp senden kann und eine Bestätigung zurückbekommt, aber dies wird nicht vom SAML WebSSO-Profil unterstützt (welches das tatsächlich verwendete ist).

Die Verwendung von SAML2 für eine mobile Anwendung ist schwierig, es gibt keine gute Unterstützung im SAML2-Protokoll für die Weiterleitung zurück zum Client. Eine gängige Methode zur Umgehung ist die Verwendung von OpenID Connect. Ich war an Setups beteiligt, bei denen sich der mobile Client über OpenID Connect bei IdentityServer3 authentifiziert. Dann fungiert IdentityServer3 als SAML2 SP (über die Middleware Kentor.AuthServices) für den Upstream-SAML2-Idp.

Ich verstehe, dass Sie in einer heiklen Situation sind, aber ich denke, dass Sie zurückgehen und fragen müssen, wie es funktionieren soll. Insbesondere sollten Sie fragen, wo der Benutzer Anmeldeinformationen eingeben soll und wie die Kommunikation zwischen SP und Idp funktionieren soll.