Ich habe ein paar Websites für die Arbeit, die außerhalb des Unternehmens-LAN - und daher außerhalb der direkten Kommunikation Bereich von Active Directory (A/D) - aber für die ich möchte in der Lage sein, Benutzer zu authentifizieren gegen die A/D-Server des Unternehmens sowie ein sekundäres Repository von Benutzern/Rollen ***. Der Pseudocode für diese Aktivität lautet wie folgt:Wie authentifiziere ich mich über ASP.NET-Webdienstcode bei Active Directory?
- Der Benutzer gibt Benutzername/Passwort in das Anmeldeformular der externen Website ein.
- Externe Website ruft einen Webservice im LAN auf, der mit A/D kommunizieren kann.
- Der Webservice überprüft, ob der Benutzername/das Passwort authentifiziert werden kann und einem Benutzer in A/D zugeordnet ist. Wenn ja, geben Sie die Liste der A/D-Rollen zurück, deren Mitglied der Benutzer ist.
- Wenn der Benutzername/das Kennwort nicht für A/D gefunden/authentifiziert werden kann, überprüfen Sie eine Datenbank/einen Dienst, der das sekundäre Repository der Benutzer-/Rolleninformationen ist. Gibt alle Rollen zurück, bei denen sie verwendet werden, wenn sie sich beim sekundären Authentifizierungsserver authentifizieren.
- Geben Sie die Liste der Rollen zurück, in der sich der Benutzer befindet, auf der aufrufenden Website.
*** Die Idee ist, dass wir nicht Dutzende - möglicherweise Hunderte - von Auftragnehmern und Affiliates in Active Directory einfügen wollen, wenn sie sich nur auf unseren externen Webservern einloggen. Daher das sekundäre Auth-Schema.
Die "externen" Webserver sind in der DMZ und können nicht direkt auf die A/D-Server zugreifen. Es gibt jedoch eine Firewallregel, die Port 80/443-Datenverkehr von den spezifischen DMZ-IP-Adressen der externen Webserver an die spezifische Port-/IP-Adresse des internen (asp.net) App-Servers zulässt. Zukünftig können wir die Server vollständig extern lagern, aber die Firewall-Ausnahme nach Port und IP würde den externen Webservern weiterhin ermöglichen, Webdienstaufrufe auf dem internen App-Server aufzurufen. –