Grundlagen der HTTP-Authentifizierung
Bei der Authentifizierung wird ermittelt, wer der Client ist, in der Regel, um festzustellen, ob der Client für den Zugriff auf eine Ressource berechtigt ist. Das HTTP-Protokoll unterstützt die Authentifizierung zum Aushandeln des Zugriffs auf eine sichere Ressource.
Die anfängliche Anforderung von einem Client ist normalerweise eine anonyme Anforderung, die keine Authentifizierungsinformationen enthält. Die HTTP-Server-Apps können die anonyme Anforderung ablehnen, während angegeben wird, dass eine Authentifizierung erforderlich ist. Die Server-App sendet WWW-Authentifizierungsheader, um die unterstützten Authentifizierungsschemen anzugeben. In diesem Artikel werden mehrere Authentifizierungsschemas für HTTP beschrieben und deren Unterstützung in Windows Communication Foundation (WCF) erläutert.
HTTP-Authentifizierungsschemen
Der Server kann mehrere Authentifizierungsschemen für den Client zur Auswahl angeben. Die folgende Tabelle beschreibt einige der Authentifizierungsschemas, die häufig in Windows-Anwendungen gefunden werden:
Authentifizierungsschema | Beschreibung |
---|---|
Anonym | Eine anonyme Anforderung enthält keine Authentifizierungsinformationen. „Anonym“ entspricht der Freigabe des Zugriffs auf die Ressource für alle Benutzer. |
Basic | Die Basic-Authentifizierung sendet eine Base64-codierte Zeichenfolge mit einem Benutzernamen und einem Kennwort für den Client. „Base64“ ist keine Form der Verschlüsselung und sollte wie der Versand des Benutzernamens und des Kennworts im Klartext verstanden werden. Wenn eine Ressource geschützt werden muss, sollten Sie möglicherweise ein anderes Authentifizierungsschema als die Basic-Authentifizierung verwenden. |
Digest | Die Hashwertauthentifizierung ist ein Abfrage/Rückmeldungsschema, das die Basic-Authentifizierung ersetzen soll. Der Server sendet eine Zeichenfolge zufälliger Daten, auch Nonce genannt, als Herausforderung an den Client. Der Client reagiert mit einem Hash, das neben anderen Informationen den Benutzernamen, das Kennwort und die Nonce enthält. Die Komplexität dieses Austauschs und der Datenhash erschweren die Wiederverwendung der Benutzeranmeldeinformationen mit diesem Authentifizierungsschema. Für die Hashwertauthentifizierung ist die Verwendung von Windows-Domänenkonten erforderlich. Der Digest-Bereich ist der Windows-Domänenname. Sie können daher keinen Server verwenden, der unter einem Betriebssystem ausgeführt wird, das keine Windows-Domänen mit der Digestauthentifizierung unterstützt, z. B. Windows XP Home Edition. Umgekehrt muss ein Domänenkonto explizit während der Authentifizierung angegeben werden, wenn der Client unter einem Betriebssystem ausgeführt wird, das keine Windows-Domänen unterstützt. |
NTLM | Die NT LAN Manager (NTLM)-Authentifizierung ist ein Abfrage/Rückmeldungsschema, das eine Variante der Digestauthentifizierung mit höherer Sicherheit darstellt. NTLM verwendet die Windows-Anmeldeinformationen, um die Abfragedaten anstelle des unverschlüsselten Benutzernamens und Kennworts zu transformieren. Die NTLM-Authentifizierung erfordert mehrere Austausche zwischen dem Client und dem Server. Der Server sowie dazwischen liegende Proxys müssen beständige Verbindungen unterstützen, um die Authentifizierung erfolgreich abzuschließen. |
Aushandeln | Beim Aushandeln der Authentifizierung wird automatisch, je nach Verfügbarkeit, zwischen dem Kerberos-Protokoll und der NTLM-Authentifizierung gewählt. Das Kerberos-Protokoll wird verwendet, wenn es verfügbar ist, anderenfalls wird versucht, NTML zu verwenden. Die Kerberos-Authentifizierung stellt eine wesentliche Verbesserung der NTLM-Authentifizierung dar. Die Kerberos-Authentifizierung ist schneller als NTLM und ermöglicht den Einsatz einer gegenseitigen Authentifizierung und die Weiterleitung der Anmeldeinformationen an Remote-Computer. |
Windows Live ID | Der zugrunde liegende Windows-HTTP-Dienst umfasst die Authentifizierung mit Verbundprotokollen. Die Standard-HTTP-Transporte in WCF unterstützen jedoch keine Verwendung von Verbundauthentifizierungsschemas wie Microsoft Windows Live ID. Unterstützung für diese Funktion steht derzeit durch die Verwendung der Nachrichtensicherheit zur Verfügung. Weitere Informationen finden Sie unter Verbund und ausgestellte Token. |
Auswählen eines Authentifizierungsschemas
Bei potenziellen Authentifizierungsschemen für einen HTTP-Server müssen u. a. die folgenden Aspekte beachtet werden:
Überprüfen Sie, ob die Ressourcen geschützt werden müssen. Für die HTTP-Authentifizierung müssen mehr Daten übertragen werden, zudem kann die Interoperabilität mit Clients eingeschränkt werden. Lassen Sie den anonymen Zugriff auf Ressourcen zu, die nicht geschützt werden müssen.
Wenn die Ressource geschützt werden muss, überlegen Sie, welche Authentifizierungsschemen die gewünschte Sicherheitsstufe bieten. Das „schwächste“ hier besprochene Standardauthentifizierungsschema ist die Standardauthentifizierung (Basic). Die Standardauthentifizierung schützt die Anmeldeinformationen des Benutzers nicht. Das "stärkste" Standardauthentifizierungsschema ist die Negotiate-Authentifizierung, die zum Kerberos-Protokoll führt.
Ein Server sollte kein Schema enthalten (beispielsweise in den WWW-Authentifizierungsheadern), das nicht darauf vorbereitet ist, die geschützte Ressource zu akzeptieren bzw. diese angemessen zu schützen. Clients können aus den unterschiedlichen Authentifizierungsschemen des Servers wählen. Einige Clients wählen standardmäßig ein schwaches Authentifizierungsschema oder das erste Authentifizierungsschema in der Liste des Servers.