Authentifizierung (HTTP-Server-API)

Einige Serveranwendungen erfordern die Clientauthentifizierung für den Zugriff auf Ressourcen und Dienst-HTTP-Anforderungen. Ab Version 2.0 führt die HTTP-Server-API die serverseitige Authentifizierung für die Anwendung aus. In der HTTP-Server-API, Version 1.0, musste die Serveranwendung eine eigene Authentifizierung implementieren. Zu den Vorteilen der Authentifizierung, die von der HTTP-Server-API ausgeführt wird, gehören:

• Anwendungen können unter geringen Berechtigungen ausgeführt werden, wodurch Sicherheitsrisiken reduziert werden.
• Die Authentifizierung erfolgt im Kernelmodus, wodurch die Übergänge vom Benutzermodus zum Kernelmodus während der Authentifizierung reduziert werden.
• Die im Kernelmodus ausgeführte Authentifizierung ermöglicht die Ausführung von Serveranwendungen auf verschiedenen Benutzerkonten. In Version 1.0 müssen alle Anwendungen auf dem Computer unter demselben Benutzerkonto ausgeführt werden, um sich beim Dienstprinzipnamen (Service Principle Name, SPN) zu authentifizieren.
• Der NTLM-Authentifizierungs-Handshake wird nicht zurückgesetzt, wenn ein Arbeitsprozess wiederverwendet wird, während der Handshake verarbeitet wird.

Um die Version 2.0-Authentifizierung zu nutzen, ermöglicht die Anwendung die Authentifizierungsschemas, die die HTTP-Server-API für die URLs anwendet, für die die Anwendung registriert wurde. Die Authentifizierung kann in der Serversitzung oder URL-Gruppe aktiviert werden. Die URL-Gruppe erbt die von der Serversitzung aktivierten Authentifizierungsschemas, wenn keines für die URL-Gruppe festgelegt ist. Die HTTP-Server-API unterstützt die folgenden Schemas:

• Verhandeln
• NTLM
• Verdauen
• Grundlegend

Die Serveranwendung kann auch Authentifizierungsschemas implementieren, die von der HTTP-Server-API nicht unterstützt werden. Die HTTP-Server-API sendet Anforderungen an die Anwendung für Authentifizierungsschemas, die nicht unterstützt werden, oder für Schemas, die von der Anwendung nicht aktiviert wurden.

Aktivieren der Authentifizierung

Die Serveranwendung aktiviert und konfiguriert die Authentifizierung in der Serversitzung oder URL-Gruppe mit der HttpSetServerSessionProperty oder HttpSetUrlGroupProperty- funktionen wie folgt:

1. Die Anwendung ermöglicht die Authentifizierung, indem HttpServerAuthenticationProperty- im parameter Property von HttpSetServerSessionProperty oder HttpSetUrlGroupPropertyangegeben wird.
2. Die Anwendung gibt die Konfigurationsparameter in der HTTP_SERVER_AUTHENTICATION_INFO Struktur im pPropertyInformation Parameter von HttpSetServerSessionProperty oder HttpSetUrlGroupPropertyan. Die Anwendung gibt die aktivierten Authentifizierungsschemas an, ob die Zwischenspeicherung von NTLM-Anmeldeinformationen deaktiviert ist, und stellt die Parameter "Basic" und "Digest" in der HTTP_SERVER_AUTHENTICATION_INFO-Struktur bereit.

Authentifizierungsverfahren

Um die HTTP-Serverauthentifizierung zu initiieren, aktiviert die Anwendung die Authentifizierungseigenschaft, bevor die erste Anforderung in der Anforderungswarteschlange eingeht. Die folgenden Schritte sind der allgemeine Verarbeitungsfluss für die Authentifizierung einer Anforderung.

1. Die Anwendung aktiviert die Authentifizierung. Weitere Informationen finden Sie im vorherigen Abschnitt "Aktivieren der Authentifizierung".

   Anmerkung

   Der Client sendet eine nicht authentifizierte Anforderung. Die HTTP-Server-API übergibt die Anforderung an die Serveranwendung und ermöglicht es, die anfängliche 401-Abfrage zu generieren. Die HTTP-Server-API enthält die HTTP_REQUEST_AUTH_INFO Struktur, die in die HTTP_REQUEST-Struktur eingebettet ist. Das AuthStatus-Element gibt HttpAuthStatusNotAuthenticated-

    

2. Die Anwendung untersucht das AuthStatus Mitglied der HTTP_REQUEST_AUTH_INFO Struktur, um zu ermitteln, ob die Anforderung authentifiziert wurde. Wenn die Anforderung nicht authentifiziert wurde, kann die Anwendung die Anforderung als anonym oder eine anfängliche 401-Authentifizierungsanforderung senden.

3. Wenn die Anwendung die Anforderung als anonym verarbeitet, verarbeitet sie die Anforderung und sendet die endgültige Antwort an die Clientanwendung, genau so, als ob die Authentifizierung nicht beteiligt war.

4. Wenn die Anwendung stattdessen eine Authentifizierung erfordert, sendet sie die anfängliche Abfrage 401 mit einem oder mehreren WWW-Authenticate Headern, die die verfügbaren Schemas an den Client angeben. Die Anwendung sollte die HTTP_MULTIPLE_KNOWN_HEADERS Struktur verwenden, um den erforderlichen Satz von Headern zu erstellen, wenn mehrere Authentifizierungsheader in der Antwort gesendet werden.

   Anmerkung

   Der Client sendet die Anforderung erneut mit dem Autorisierungsheader für ein Schema, das aus der Gruppe der verfügbaren Schemas ausgewählt wurde, die von der Serveranwendung in der ursprünglichen Antwort 401 angegeben wurde.

   Die HTTP-Server-API untersucht den Autorisierungsanforderungsheader, um festzustellen, ob das Schema aktiviert ist. Wenn dies der Grund ist, führt die HTTP-Server-API die Authentifizierung durch und verarbeitet alle Zwischenanforderungs-/401-Antwortaustausche, bis der Authentifizierungs-Handshake abgeschlossen ist.

   Wenn die HTTP-Server-API den Authentifizierungsversuch abgeschlossen hat, sendet sie die Anforderung an die Anwendung mit den Ergebnissen des Authentifizierungsversuchs in der HTTP_REQUEST_AUTH_INFO Struktur, die mit der Anforderung zurückgegeben wird. Wenn der Authentifizierungsversuch aus einem der folgenden Gründe fehlschlägt, übergibt die HTTP-Server-API die Anforderung nicht an die Anwendung:

   • Wenn der Authentifizierungs-Handshake aufgrund eines internen HTTP-Server-API-Fehlers fehlschlägt, z. B. ein Speicherzuweisungsfehler, generiert die HTTP-Server-API eine Antwort von 503 (Dienst nicht verfügbar) und sendet an den Client zurück.
   • Wenn ein falsch formatierter Autorisierungsheader wie z. B. ein Header ohne Schemaname oder eine falsch formatierte Base64-Codierung von Clientanmeldeinformationen aufgetreten ist, generiert die HTTP-Server-API eine Antwort von 400 (ungültige Anforderung) und sendet an den Client zurück.

    

5. Die Serveranwendung überprüft das AuthStatus- Mitglied der HTTP_REQUEST_AUTH_INFO-Struktur, um zu ermitteln, ob die Authentifizierung erfolgreich war. Wenn die Authentifizierung fehlschlägt, enthält die HTTP-Server-API den Fehler, der von AcceptSecurityContext- im SecStatus Member der HTTP_REQUEST_AUTH_INFO-Struktur zurückgegeben wird. Wenn der Authentifizierungsversuch aufgrund fehlerhafter Anmeldeinformationen fehlschlägt, kann die Anwendung eine weitere 401-Abfrage mit dem gewünschten WWW-Authenticate Header generieren oder sich für die Wartung der Anforderung als anonym entscheiden.

6. Wenn die Authentifizierung erfolgreich war, verwendet die Anwendung das in der HTTP_REQUEST_AUTH_INFO-Struktur bereitgestellte Token, um die Identität des Clients zu imitieren und auf Ressourcen zuzugreifen. Das an die Anwendung zurückgegebene Zugriffstokenhandle ist gültig, solange die Anforderungs-ID gültig ist. Dies gilt in der Regel, bis die Anwendung die Antwort auf die Anforderung abgeschlossen hat. Das Token kann jedoch während dieses Zeitraums ablaufen, und die Anwendung muss möglicherweise eine weitere 401-Abfrage an den Client senden.

7. Die Anwendung sendet die letzte 200 OK-Antwort, und sie muss das Handle mit dem Zugriffstoken schließen.

   Anmerkung

   Die HTTP-Server-API fügt die gegenseitigen Authentifizierungsdaten an die letzte 200 OK-Antwort an, wenn eine während des Authentifizierungs-Handshake generiert wurde.

    

NTLM NULL-Sitzungen

Beachten Sie, dass eine NTLM NULL-Sitzung, die im endgültigen Sicherheitskontext angegeben ist, nicht als authentifiziert behandelt wird. In diesem Fall wird die Anforderung an die Anwendung mit einem HttpAuthStatusFailure-Fehler in der HTTP_REQUEST_AUTH_INFO-Struktur gesendet, und die Anwendung kann eine weitere 401-Abfrage senden.

Präemptive Authentifizierung

Nach dem HTTP-Protokoll kann der Client nach dem Einrichten der Authentifizierung für eine Ressource den entsprechenden Autorisierungsheader vorab mit nachfolgenden aufeinander folgenden Anforderungen für die Ressource senden, ohne auf eine Abfrage von 401 vom Server zu warten. Wenn das im Autorisierungsheader angegebene Schema weiterhin von der Anwendung aktiviert und von der HTTP-Server-API unterstützt wird, versucht der HTTP-Server die Authentifizierung, ohne die Anforderung an die Anwendung zu senden. Wenn diese Art von authentifizierter Anforderung von der Anwendung empfangen wird, kann sie die Anforderung verwerfen und die anfängliche 401-Abfrage oder den Dienst der Anforderung als authentifiziert neu generieren.

Gegenseitige Authentifizierung

Gegenseitige Authentifizierungsdaten werden generiert, wenn das Aushandlungsschema während des Handshake verwendet wird und in Kerberos aufgelöst wird und der Client die gegenseitige Authentifizierung angefordert hat. Die gegenseitigen Authentifizierungsdaten werden automatisch von der HTTP-Server-API in die endgültige 200 OK-Antwort eingefügt, die von der Serveranwendung gesendet wird. Standardmäßig übergibt die HTTP-Server-API die Daten der gegenseitigen Authentifizierung nicht an die Serveranwendung, da sie das Senden automatisch verarbeitet. Wenn die Serveranwendung jedoch das ReceiveMutualAuth-Flag in der HTTP_SERVER_AUTHENTICATION_INFO Struktur in der Konfiguration aktiviert, werden die gegenseitigen Authentifizierungsdaten an die Anwendung in HTTP_REQUEST_AUTH_INFO Struktur übergeben, die mit der authentifizierten HTTP_REQUESTeingebettet ist. In diesem Fall sollte die Anwendung die gegenseitigen Authentifizierungsdaten mit der endgültigen Antwort "200 OK" senden. Wenn mehrere Websites von einem einzelnen Computer bedient werden, verwenden alle Websites auf dem Computer die Anmeldeinformationen für das lokale Computerkonto in der Domäne für die gegenseitige Authentifizierung.