Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Authentifizierung ist der Prozess der Identifizierung, wer der Client ist, in der Regel, um festzustellen, ob der Client berechtigt ist, auf eine Ressource zuzugreifen. Das HTTP-Protokoll unterstützt die Authentifizierung als Mittel zum Aushandeln des Zugriffs auf eine sichere Ressource.
Die ursprüngliche Anforderung eines Clients ist in der Regel eine anonyme Anforderung, die keine Authentifizierungsinformationen enthält. HTTP-Server-Apps können die anonyme Anforderung verweigern und angeben, dass die Authentifizierung erforderlich ist. Die Server-App sendet WWW-Authentication Header, um die unterstützten Authentifizierungsschemas anzugeben. In diesem Artikel werden mehrere Authentifizierungsschemas für HTTP beschrieben und deren Unterstützung in Windows Communication Foundation (WCF) erläutert.
HTTP-Authentifizierungsschemas
Der Server kann mehrere Authentifizierungsschemas angeben, aus denen der Client auswählen kann. In der folgenden Tabelle werden einige der Authentifizierungsschemas beschrieben, die häufig in Windows-Anwendungen zu finden sind:
| Authentifizierungsschema | BESCHREIBUNG |
|---|---|
| Anonym | Eine anonyme Anforderung enthält keine Authentifizierungsinformationen. Anonym ist gleichbedeutend mit der Gewährung des Zugriffs aller Personen auf die Ressource. |
| Grundlegend | Die Standardauthentifizierung sendet eine Base64-codierte Zeichenfolge, die einen Benutzernamen und ein Kennwort für den Client enthält. Base64 ist keine Form der Verschlüsselung und sollte als das Senden des Benutzernamens und des Kennworts im Klartext betrachtet werden. Wenn eine Ressource geschützt werden muss, sollten Sie ein anderes Authentifizierungsschema als die Standardauthentifizierung verwenden. |
| Zusammenfassung | Die Digestauthentifizierung ist ein Abfrageantwortschema, das die Standardauthentifizierung ersetzen soll. Der Server sendet eine Zeichenfolge von zufälligen Daten, die als Nonce bezeichnet werden, als Herausforderung an den Client. Der Client antwortet mit einem Hash, der den Benutzernamen, das Kennwort, die Nonce und andere Informationen enthält. Die Komplexität, die dieser Austausch einführt, und das Daten-Hashing erschweren es, die Anmeldeinformationen des Benutzers mit diesem Authentifizierungsschema zu stehlen und wiederzuverwenden. Die Digestauthentifizierung erfordert die Verwendung von Windows-Domänenkonten. Der Digest-Bereich ist der Windows-Domänenname. Daher können Sie keinen Server verwenden, der auf einem Betriebssystem ausgeführt wird, das Keine Windows-Domänen unterstützt, z. B. Windows XP Home Edition, mit Digestauthentifizierung. Wenn der Client hingegen auf einem Betriebssystem ausgeführt wird, das keine Windows-Domänen unterstützt, muss ein Domänenkonto während der Authentifizierung explizit angegeben werden. |
| NTLM | Die NT LAN Manager(NTLM)-Authentifizierung ist ein Abfrageantwortschema, das eine sicherere Variante der Digestauthentifizierung darstellt. NTLM verwendet Windows-Anmeldeinformationen, um die Abfragedaten anstelle des nicht codierten Benutzernamens und Kennworts zu transformieren. Für die NTLM-Authentifizierung ist ein mehrfacher Austausch zwischen Client und Server erforderlich. Der Server und alle dazwischen liegenden Proxys müssen dauerhafte Verbindungen unterstützen, um die Authentifizierung erfolgreich abzuschließen. |
| Verhandeln | Negotiate-Authentifizierung wählt automatisch zwischen dem Kerberos-Protokoll und der NTLM-Authentifizierung, je nach Verfügbarkeit. Das Kerberos-Protokoll wird verwendet, wenn es verfügbar ist; andernfalls wird NTLM versucht. Die Kerberos-Authentifizierung verbessert sich erheblich bei NTLM. Die Kerberos-Authentifizierung ist sowohl schneller als NTLM und ermöglicht die Verwendung gegenseitiger Authentifizierung und Delegierung von Anmeldeinformationen an Remotecomputer. |
| Windows Live ID | Der zugrunde liegende Windows-HTTP-Dienst enthält die Authentifizierung mithilfe von Verbundprotokollen. Die standardmäßigen HTTP-Transporte in WCF unterstützen jedoch nicht die Verwendung von Verbundauthentifizierungsschemas, z. B. Microsoft Windows Live ID. Die Unterstützung für dieses Feature steht derzeit mithilfe der Nachrichtensicherheit zur Verfügung. Weitere Informationen finden Sie unter "Partnerverbund" und "Ausgestellte Token". |
Auswählen eines Authentifizierungsschemas
Wenn Sie die potenziellen Authentifizierungsschemas für einen HTTP-Server auswählen, sollten Sie folgendes berücksichtigen:
Überlegen Sie, ob die Ressource geschützt werden muss. Die Verwendung der HTTP-Authentifizierung erfordert die Übertragung weiterer Daten und kann die Interoperabilität mit Clients einschränken. Anonymen Zugriff auf Ressourcen zulassen, die nicht geschützt werden müssen.
Wenn die Ressource geschützt werden muss, überlegen Sie, welche Authentifizierungsschemas die erforderliche Sicherheitsstufe bieten. Das schwächste Standardauthentifizierungsschema, das hier beschrieben wird, ist die Standardauthentifizierung. Die Standardauthentifizierung schützt die Anmeldeinformationen des Benutzers nicht. Das stärkste Standardauthentifizierungsschema ist die Negotiate-Authentifizierung, das zum Kerberos-Protokoll führt.
Ein Server sollte z.B. in den WWW-Authentication-Headern kein Schema präsentieren, das er nicht annehmen kann oder das die geschützte Ressource nicht ausreichend sichert. Clients können zwischen einem der vom Server präsentierten Authentifizierungsschemas wählen. Einige Clients verwenden standardmäßig ein schwaches Authentifizierungsschema oder das erste Authentifizierungsschema in der Liste des Servers.