Lösung Double-Hop vom Client> Webservice> SQL Server zu vermeiden

Question

Mein Projekt invoves einen Benutzer von Client Webdienst, und dann Web-Service zu SQL Server. Die Web-Services und SQL Server sind auf separaten Maschinen. Aufgrund der Sicherheitsanforderungen, können wir nicht gemischten Modus in SQL Server verwendet wird, nur die Windows-Authentifizierung.

Wir erleben die "Double-Hop" -Ausgabe zwischen Web-Service und SQL Server. Wir verwenden die NTLM-Authentifizierung und tun nicht wollen Kerberos konfigurieren, da der Overhead und Lernkurve. Wir wollen auch nicht den Web-Service und SQL Server auf der gleichen Maschine haben.

Von dem, was ich verstehe, alle unsere Anforderungen machen dieses Szenario unmöglich zu lösen. Allerdings kam ein Entwickler mit diesem Vorschlag auf:

1) Senden Sie die Windows-Benutzername und das Passwort vom Client an den Web-Service unter SSL-Verschlüsselung

2) Irgendwie wandelt die Windows-Benutzername und das Passwort in eine Sicherheits-Token, die von SQL Server authentifiziert werden könnten

Um eine Analogie zu machen, es klingt wie wir eine RUNAS in der C # -Code würde tun, wenn zu SQL Server zu verbinden. Es gäbe keine Authentifizierung für den Web-Service sein, nur durch SQL Server.

Meine Fragen:

1) Ist die vorgeschlagene Lösung möglich?

2) Wenn ja, wie wäre es getan werden?

3) Die Web-Ressourcen, mir helfen zu verstehen, wie es getan werden könnte?

Answer 1

Nein, das ist nicht möglich. Der Client-Prozess hat nicht Zugriff auf das Benutzerkennwort haben, und daher kann es nicht an den Web-Service-Tier senden. Der Kunde müßte explizit den Benutzer nach seinem Passwort fragen. Wenn der Client-Prozess das Passwort hat und bereit ist, es an den Webdienst zu senden, dann in der Theorie kann die WebService ein Token für den Benutzer / Passwort erstellen (mit Logonuser ) und dann mit dem SQL-Server, dass Token verbinden. Diese so genannte Lösung wird so mit mehreren Sicherheitsproblemen gespickt, die nicht der Rede wert sind. Wenn Ihr Team darauf besteht, macht einen Web-Service, die das tut, einem Teammitglied bitten, um eine Verbindung herzustellen, und wenn Sie halten sein Beglaubigungs bekommen (wird er Ihr Service sein senden Passwort , schon vergessen? ) mit dem Exchange-Server verbinden und eine E-Mail an den CEO mit dem Text ‚Fire mich, ich bin ein Idiot‘ senden. Oder seine direkte Einzahlung Bank ändern und Konto in HR. Verwenden Sie Ihre Phantasie ... Ich hoffe, dass jetzt etwas klarer ist, warum gehen auf dem Weg Sie vorschlagen, ist eine sehr schlechte Idee .

Nur Kerberos verwenden.

Übrigens, wenn Sie an das hintere Ende authentifizieren müssen wegen der staatlichen Regulierung, tragen dann daran, dass die Authentifizierung und Audit immer werden mit einer "Nicht-Nachweisbarkeit Anforderung und Senden Sie das Kennwort zu der Web-Dienst so authentifiziert es auf Ihrem eklatant widerspricht diese Anforderung, da der Web-Dienst eine Operation tun kann, als der Benutzer getarnt. Dies ist, was die Kerberos-Delegation ist erzwungener Delegation.

Answer 2

Das ist nicht getan werden könnte. Denken Sie darüber nach, wenn Anwendungen einfach Sicherheitstoken auf diese Weise erzeugen könnte, was würde es sein? Sie werden Kerberos müssen dieses Problem zu überwinden.

Edit:. Auch die runas Analogie gilt nicht im Falle eines Kunden authentifiziert, die versuchen in zwei Systeme nacheinander, da runas erfordert nur einen einzigen Hop, auch wenn Sie den Benutzer wechseln