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.
Websicherheit stützt sich auf die Internetstandards für verschlüsselte Kommunikation und Authentifizierung. Die HttpChannel-Klasse verwendet zur Gewährleistung der Websicherheit auf der Senderseite ein verwaltetes Netzwerk und auf der Empfängerseite Internet-Informationsdienste (IIS) mit ASP.NET. Die Anmeldeinformationen (Benutzername, Kennwort, optional auch die Domäne) können in den HttpChannel-Eigenschaften festgelegt werden. Die Remotinginfrastruktur übergibt die Anmeldeinformationen an System.Net, von wo aus sie an den Server gesendet werden. Die Eigenschaften des Channelnachrichtenempfängers umfassen eine PreAuthenticate-Eigenschaft, die standardmäßig die Anmeldeinformationen zusammen mit der ersten Nachricht sendet.
Authentifizierung
In ASP.NET gehostete Anwendungen können für die Authentifizierung mit einer Kombination von IIS und ASP.NET-Sicherheit konfiguriert werden. Das virtuelle Verzeichnis der ASP.NET-Anwendung wird in IIS und ASP.NET für die Sicherheit konfiguriert. Weitere Informationen über das Konfigurieren von IIS und ASP.NET für die Authentifizierung finden Sie in der Dokumentation zu IIS ** und unter Sicherheit für ASP.NET-Webanwendungen.
Sichere Kommunikation in ASP.NET
Der in IIS mit ASP.NET gehostete HttpChannel unterstützt das Senden und Empfangen verschlüsselter Kommunikation unter Verwendung von SSL (Secure Sockets Layer). Informationen zum Konfigurieren von SSL finden Sie in der Dokumentation zu IIS. Schließen Sie den Text https und den entsprechenden URL am Anfang von Aufrufen von Activator.CreateInstance, Activator.GetObject, Elementen in der .NET Remoting-Konfigurationsdatei oder an beliebiger anderer Stelle ein, an denen mit Hilfe eines URLs ein Remoteobjekt, ein Remote-XML-Webdienst oder eine Remoteanwendung angegeben wird.
Um zu ermitteln, ob die HTTP-Verbindung verschlüsselt ist, rufen Sie die HttpContext.Request-Eigenschaft auf, um das HttpRequest-Objekt abzurufen, und rufen Sie anschließend HttpRequest.IsSecureConnection auf.
Anonymous
Ermöglichen Sie mit dieser Option Benutzern das Herstellen einer anonymen Verbindung. In diesem Fall kann sich der Benutzer mit einem anonymen bzw. Gastkonto am Server anmelden.
**Hinweis **Wenn Sie die Standard-, Digest- oder integrierte Windows-Authentifizerung verwenden möchten, müssen Sie Anonym deaktivieren.
Standardauthentifizierung
Bei der Standardauthentifizierung handelt es sich um einen Sicherheitsmechanismus, in dem ein HTTP-Standardmechanismus zum Einsatz kommt, bei dem Benutzerinformationen als klar lesbare Textzeichen gesendet und empfangen werden, und nicht als binärer Datenstream. Die Standardauthentifizierung verwendet eine Base64-codierte Zeichenfolge, die den Benutzernamen und das Kennwort enthält. Bei dieser Art der Authentifizierung werden Kennwörter und Benutzernamen codiert, aber nicht verschlüsselt. Sie müssen sich darüber im Klaren sein, dass bei der Standardauthentifizierung Kennwörter unverschlüsselt über das Netzwerk übertragen werden. So können Unbefugte, sofern sie entschlossen genug sind und über ein Tool zur Netzwerküberwachung verfügen, Benutzernamen und Kennwörter abfangen.
Die Standardauthentifizierung kann nützlich sein, wenn die Anwendung lediglich einen Bezeichner für die aufrufende Anwendung benötigt.
Digestauthentifizierung
Bei der Digestauthentifizierung wird nicht das Kennwort, sondern ein Hashwert über das Netzwerk gesendet. Diese Methode funktioniert über Proxyserver oder andere Firewalls hinweg.
Es handelt sich bei der Digestauthentizierung um ein Abfrage/Rückmeldung-Schema, das für die Abfrage einen nonce-Wert verwendet (d. h. eine vom Server festgelegte Datenzeichenfolge). Eine gültige Antwort enthält eine Prüfsumme für den Benutzernamen, das Kennwort, den betreffenden nonce-Wert, die HTTP-Methode und den angeforderten URI (Uniform Resource Identifier).
Bei der Digestauthentifizierung sind viele der Schwachpunkte der Standardauthentifizierung nicht gegeben. Besonders wichtig ist dabei, dass das Kennwort bei der Digestauthentifizierung nicht in Klartext übertragen wird. Darüber hinaus kann die Digestauthentifizierung im Gegensatz zur integrierten Windows-Authentifizierung auch über Proxyserver ausgeführt werden.
Die Digestauthentifizierung ist nützlich, wenn für die Anwendung eine strengere Authentifizierung als die Standardauthentifizierung erforderlich ist.
Cookieauthentifizierung
Der Begriff Cookieauthentifizierung bezieht sich im Allgemeinen auf ein System, bei dem nicht authentifizierte Anforderungen unter Verwendung der clientseitigen HTTP-Umleitung an ein HTTP-Formular umgeleitet werden. Der Benutzer stellt Anmeldeinformationen bereit und sendet das Formular. Wenn die Anwendung die Anforderung authentifiziert, gibt das System ein Cookie aus, das in einem bestimmten Format die Anmeldeinformationen enthält oder einen Schlüssel zur Wiedererlangung der Identität bereitstellt. Nachfolgende Anforderungen werden mit dem Cookie in den Anforderungsheadern ausgegeben und von einem ASP.NET-Handler nach der jeweils von der Anwendung geforderten Überprüfungsmethode authentifiziert und autorisiert.
Die Cookieauthentifizierung wird oft für die Personalisierung, d. h. zum Anpassen von Inhalten für einen bekannten Benutzer verwendet. In einigen derartigen Fällen ist statt der Identifizierung die Authentifizierung das Problem, so dass es genügt, nur den Benutzernamen in einem permanenten Cookie zu speichern und den Namen für den Zugriff auf die Personalisierungsinformationen zu verwenden.
Integrierte Windows-Authentifizierung
Bei der integrierten Windows-Authentifizierung erfolgt ein kryptographischer Austausch mit Microsoft Internet Explorer auf dem Benutzercomputer.
Die integrierte Windows-Authentifizierung, die früher sowohl als NT LAN Manager bzw. NTLM als auch als Windows NT-Abfrage/Rückmeldung-Authentifizierung bezeichnet wurde, ist sicherer als die Standardauthentifizierung. Dieses Authentifizierungsschema ist besonders gut für Intranetumgebungen geeignet, in denen Benutzer über Windows-Domänenkonten verfügen.
Bei der integrierten Windows-Authentifizierung versucht der Browser, die Anmeldeinformationen des aktuellen Benutzers von der Domänenanmeldung zu verwenden. Wenn diese Anmeldeinformationen ungültig sind, fordert die integrierte Windows-Authentifizierung den Benutzer in einem entsprechenden Dialogfeld zur Eingabe eines Benutzernamens und Kennworts auf. Bei Verwendung der integrierten Windows-Authentifizierung wird das Kennwort des Benutzers nicht vom Client an den Server übergeben. Wenn sich ein Benutzer an einem lokalen Computer als Domänenbenutzer angemeldet hat, muss er beim Zugriff auf einen Netzwerkcomputer in derselben Domäne nicht erneut authentifiziert werden.
Der Benutzer wird nicht bei jeder HTTP-Anforderung zur Eingabe seines Benutzernamens und Kennworts aufgefordert, sondern das Dialogfeld wird nur dann angezeigt, wenn die zwischengespeicherten Anmeldeinformationen nicht mit ausreichenden Berechtigungen für den Zugriff auf eine bestimmte Seite oder Datei verknüpft sind.
Siehe auch
Sicherheit | Rollenbasierte Sicherheit in verwalteten Anwendungen