HTTP-Sicherheit und ASP.NET-Webdienste

Veröffentlicht: 13. Okt 2002 | Aktualisiert: 21. Jun 2004
Von Scott Seely

HTTP-basierte Mechanismen bieten gegenwärtig die beste Sicherheitsmöglichkeit für Ihre Webdienste. Sie erfahren in diesem Artikel, wie Sie Ihre Webdienste durch die Verwendung einer Kombination der Features von Microsoft IIS und Microsoft ASP.NET sichern.

Auf dieser Seite

Einführung Einführung
Verschlüsselung und Signierung mit SSL Verschlüsselung und Signierung mit SSL
Authentifizierung Authentifizierung
Verwenden von Codezugriffssicherheit Verwenden von Codezugriffssicherheit
Interoperabilität Interoperabilität
Zusammenfassung Zusammenfassung
Ressourcen Ressourcen

Betrifft:
Microsoft ASP.NET
Microsoft Internet-Informationsdienste (IIS)
HTTP-Sicherheit
Webdienste

Anmerkung Dieser Artikel setzt voraus, dass Sie mit der Verwendung von SSL in IIS vertraut sind.

Einführung

Eine Angelegenheit scheint die Entwickler von Web Services in den Wahnsinn zu treiben: herauszufinden, wie sie die IIS und ASP.NET Web Services einsetzen, um für Sicherheit zu sorgen. Derzeit sorgen die IIS für Sicherheit, während ASP.NET diese wirksam einsetzt.
ASP.NET verwendet die IIS-Informationen, um denAufrufenden zu bestimmen oder um die Codezugriffsicherheit für spezifische Vorgänge des Webdienstes zu verwenden. Der schwierige Teil ist für viele, die Anwendung so zu programmieren, dass sie die Vorteile der in IIS enthaltenen Sicherheitsfunktionen nutzt. Eine noch bessere Möglichkeit bietet in naher Zukunft die WS-Security. Bis dahin werden viele von uns Sicherheitsfunktionen auf HTTP-Ebene einsetzen, um das Messaging sicher zu machen.
Folgende Punkte müssen berücksichtigt werden, um eine Webmethode auf sichere Weise auszuführen:

  • Vertraulichkeit sorgt dafür, dass die Daten von Dritten nicht mitgehört werden können.

  • Integrität bietet den Empfängern die Möglichkeit, Veränderungen in der SOAP-Nachricht aufzudecken.

  • Authentifizierung beantwortet die Frage "wer ist der Aufrufer?".

  • Autorisierung beantwortet die Frage, ob der Aufrufer berechtigt ist, auf diese Webmethode zuzugreifen.

  • Unleugbarkeit stellt sicher, dass eine Aktion ausgeführt wurde, um den Client davor zu schützen, dass eine Transaktion fälschlicherweise nicht eingehalten wird.

Viele dieser Sicherheitsfunktionen arbeiten zusammen. Die Authentifizierung ermöglicht die Autorisierung und die Unleugbarkeit. Die Vertraulichkeitsmaßnahmen, die von SSL zur Verfügung gestellt werden, enthalten auch Integritäts- und Authentifizierungsmechanismen. Dieser Artikel setzt voraus, dass Sie mit der Verwendung von SSL in IIS vertraut sind. Wenn Sie hierüber noch keine Kenntnisse haben, finden Sie Ressourcen zu diesem Thema am Ende dieses Artikels. Ich möchte Ihnen außerdem empfehlen, einen Microsoft Windows Server mit installiertem Certificate Server zur Verfügung zu haben (oder Certificate Server auf einem verfügbaren Windows-Server-Computer zu installieren). Dies ist hilfreich, um den Abschnitten im Artikel zu folgen, die von SSL handeln.

Verschlüsselung und Signierung mit SSL

Wann immer Sie Informationen in einer HTTP-basierten SOAP-Nachricht vor den Augen Dritter schützen müssen, sollten Sie den Dienst immer über SSL ausführen. Auf diese Weise sind die Daten des Webdienstes anderen nicht zugänglich, die die Datenübertragung verfolgen.
Sie müssen bereits ein X.509-Zertifikat im Stammverzeichnis Ihres Webservers eingerichtet haben, um die Informationen in diesem Abschnitt verwenden zu können. Informationen über die Vorgehensweise hierfür finden Sie in dem Artikel HOWTO: Configure SSL in a Windows 2000 IIS 5.0 Test Environment Using Certificate Server 2.0 (Q290625)Hier verlassen Sie die Website von Microsoft Deutschland (in Englisch). Mit dem richtig installierten Zertifikat können Sie die SSL-Authentifizierung für ein virtuelles Verzeichnis oder eine spezifische Datei erzwingen.

So öffnen Sie die IIS Management Console

  1. Klicken Sie im Menü Start auf Ausführen.

  2. Geben Sie im Bearbeitungsfeld Öffnen Folgendes ein: inetmgr.

  3. Klicken Sie auf OK.

Die IIS Management Console wird geöffnet.

Die SSL-Anforderung für ein virtuelles Verzeichnis oder eine bestimmte Datei wird durch die Auswahl der richtigen Optionen in IIS erreicht. Wechseln Sie in der IIS Management Console zum virtuellen Verzeichnis, um die "richtigen Optionen" auszuwählen. Wenn SSL für alle Webdienste in einem gegebenen virtuellen Verzeichnis eingesetzt werden soll, klicken Sie mit der rechten Maustaste auf das virtuelle Verzeichnis, danach auf Eigenschaften und dann auf die Registerkarte Verzeichnisssicherheit.

Wenn Sie nur einen bestimmten Webdienst sichern möchten, klicken Sie mit der rechten Maustaste auf die .asmx-Datei, die mit diesem Webdienst verbunden ist, danach auf Eigenschaften und dann auf die Registerkarte Dateisicherheit. Bei beiden Vorgängen wird ein Dialogfeld geöffnet, das dem in Abbildung 1 gleicht. Klicken Sie unter Sichere Kommunikation auf Bearbeiten. Das Dialogfeld Sichere Kommunikation wird geöffnet, siehe Abbildung 2.

Bild01

Abbildung 1. Die Registerkarte "Verzeichnissicherheit" in der IIS Management Console

Bild02

Abbildung 2. Das Dialogfeld "Sichere Kommunikation"

Das Kontrollkästchen Sicheren Kanal verlangen (SSL) ist standardmäßig deaktiviert. Aktivieren Sie es, um SSL zu verlangen. SSL unterstützt sowohl 40-Bit- als auch 128-Bit-Verschlüsselung. Je mehr Bits bei der Verschlüsselung verwendet werden, desto schwieriger ist es, die Originaldaten unbefugt zu entschlüsseln.

Mehr brauchen Sie nicht zu tun, um SSL für eine bestimmte .asmx-Datei oder einen kompletten Webdienst zu aktivieren. Die Kommunikation zwischen einem beliebigen Webdienstclient und dem Webdienst selbst wird hierdurch sicher, solange das Webserverzertifikat intakt ist. SSL verwendet X.509-Zertifikate, die einen öffentlichen Schlüssel enthalten und auch einen privaten Schlüssel enthalten können. Wenn der private Schlüssel Dritten bekannt wird, ist die mit dem öffentlichen Schlüssel verschlüsselte Kommunikation nicht länger sicher vor diesen Dritten.
Haben Sie die Ressource einmal so eingerichtet, dass SSL zur Kommunikation verlangt wird, wird jede zwischen Absender und Empfänger übermittelte Nachricht verschlüsselt und signiert. Die Inhalte der Nachrichten können nicht von Dritten gelesen werden. Wenn ein Dritter die Bytes in der Nachricht ändert, kann der Nachrichtenempfänger dies herausfinden.

Authentifizierung

Sie müssen die Datei Web.config, die zu Ihrem Webdienst gehört, bearbeiten, um die Authentifizierung durch IIS zu nutzen. Setzen Sie das Attribut /configuration/system.web/authentication/@mode auf Windows, um die Benutzeridentität im HttpContext verfügbar zu machen. Das Mode-Attribut muss immer gesetzt werden, wenn IIS eine der folgenden Authentifizierungsoptionen verwendet: Standard, Digest, Integrierte Windows-Authentifizierung (NTLM/Kerberos) oder X.509-Zertifikate. Die Benutzeranmeldeinformationen der jeweiligen Authentifizierungsoption müssen einem Benutzer entsprechen, der entweder auf dem lokalen Computer oder innerhalb des Active Directory existiert.

Durch die Kombination von IIS und den richtigen Web.config-Einstellungen kann der Webdienst die Identität des Aufrufers feststellen. Zusätzlich wird die Identität des Aufrufers durch den Anforderungskontext vermutet. Wenn Sie die Windows-Authentifizierung verwenden wollen, muss die Web.config-Datei folgendermaßen aussehen:

<configuration>
    <system.web>
        <authentication mode="Windows" />
        <!-- Platz für weitere Elemente -->
    </system.web>
</configuration>

Die Windows-Authentifizierung muss für die Autorisierung, Überwachung und Unleugbarkeit unbedingt aktiviert sein. Hierdurch wird die Ausführung Ihrer Webmethode als Aufrufer ermöglicht. Alle Protokollierungen, Zugriffsüberprüfungen usw. werden auf der Basis von Benutzerberechtigungen ausgeführt.

Sie müssen den anonymen Zugriff ausschalten, damit IIS die Identität des Aufrufers zeigt. Das ist schon alles. Dazu gehen Sie zurück und öffnen inetmgr (klicken Sie auf Start, danach auf Ausführen und geben Sie dann inetmgr ein). Wechseln Sie zum entsprechenden virtuellen Verzeichnis.

Je nachdem, ob Sie die Identität für alle Dateien im virtuellen Verzeichnis oder nur für einen Webdienst erzwingen möchten, klicken Sie mit der rechten Maustaste auf das Verzeichnis oder die .asmx-Datei und dann auf Eigenschaften. Klicken Sie auf die Registerkarte Verzeichnissicherheit (wie in Abbildung 1 gezeigt). Klicken Sie unter Steuerung des anonymen Zugriffs und der Authentifizierung auf Bearbeiten. Das Dialogfeld Authentifizierungsmethoden wird geöffnet, wie in Abbildung 3 gezeigt.

Bild03

Abbildung 3. Das Dialogfeld "Authentifizierungsmethoden" mit deaktiviertem Kontrollkästchen "Anonymer Zugriff"

Im Dialogfeld Authentifizierungsmethoden können Sie die Art des Benutzerzugriffs auf das virtuelle Verzeichnis oder die Datei konfigurieren. Sie können Standard- oder Digestauthentifizierung verwenden, um die Benutzer-Anmeldeinformationen über die HTTP-Header zu übermitteln. Weder Standard- noch Digestauthentifizierung verfügen über Mechanismen, um die Nachricht zu sichern.
Der Mechanismus zur Übermittlung der Benutzeranmeldeinformationen ist in RFC 2617: HTTP Authentication: Basic and Digest Access AuthenticationHier verlassen Sie die Website von Microsoft Deutschland (in Englisch) definiert. Im Wesentlichen wird eine Autorisierung benannter HTTP-Header verwendet, um den Benutzernamen und das Kennwort zu übertragen. Bei der Standardauthentifizierung wird die Benutzername/Kennwort-Kombination in Klartext gesendet.

Nun, nicht ganz. Tatsächlich werden Benutzername und Kennwort in Base64 codiert, was einfach Klartext ist. Für diejenigen unter Ihnen, denen die Base64-Codierung nicht bekannt ist: Es ist ein Weg, Binärdaten als Text zu zeigen und zu übermitteln. Beim Codieren der Daten werden keine Kennwörter/Schlüssel verwendet. Wenn Sie Standardauthentifizierung verwenden, sollten Sie solche Anmeldeinformationen nur über SSL akzeptieren. Hierdurch werden der Webdienst und der Aufrufer vor dem Versuch Dritter geschützt, den Kanal auszuspionieren, um gültige Anmeldeinformationen zu erhalten.

Eine weitere Möglichkeit ist die Verwendung der Digestauthentifizierung. Wenn Sie diese Möglichkeit wählen, müssen Sie beachten, dass viele SOAP-Toolkits keine Digestauthentifizierung unterstützen. Sie begrenzen damit also die Anzahl der Toolkits, die den Webdienst verwenden können. Verwenden Sie Digestauthentifizierung, wenn Sie die Identität des Aufrufers wissen möchten, die Ziel-SOAP-Toolkits die Digestauthentifizierung unterstützen und die Inhalte der SOAP-Nachrichten nicht besonders wichtig sind. Digestauthentifizierung verschlüsselt die Anmeldeinformationen des Aufrufers durch einen gemeinsamen Schlüssel, ein so genannter Nonce.

Sowohl Standard- also auch Digestauthentifizierung verwenden Abfrage/Antwort-Mechanismen. Daher werden mehrere Abfragen und Antworten zwischen dem Client und dem Empfänger ausgetauscht, bevor überhaupt eine Webmethode aufgerufen wird. Abfrage und Antwort können bei der Standardauthentifizierung recht schnell vor sich gehen. Ein Client kann sogar die Standardanmeldeinformationen im Voraus bereitstellen, wenn er weiß, dass die Standardauthentifizierung verlangt wird.

Diese Beschleunigung kann bei einer SSL-basierten Verbindung, bei der das Serverzertifikat überprüft wird und ein Sitzungsschlüssel eingerichtet wird, von geringem Wert sein. Bei Digestauthentifizierung muss der Nonce ausgetauscht werden, bevor die Anmeldeinformationen verschlüsselt werden. Auch hier ist ein Handshaking erforderlich, bevor ein Webdienstcode ausgeführt wird.

Um die Aktivierung dieser Elemente für Ihren Webdienst zu erzwingen, markieren Sie einfach die entsprechenden Kontrollkästchen im Dialogfeld Authentifizierungsmethoden. Wenn Sie nur authentifizierte Benutzer den Zugang ermöglichen möchten, stellen Sie sicher, dass das Kontrollkästchen Anonymer Zugriff deaktiviert ist. Danach können Sie serverseitig Folgendes ausführen:

  • Feststellen, wer der Aufrufer ist.

  • Codezugriffssicherheit verwenden, um einzuschränken, wer welche Methoden aufruft.

Der folgende Webdienst gibt die aktuelle Information über den Aufrufer zurück:

[WebMethod]
public string WhoAmI() {
    return "Als Benutzer ausführen : " +
        Thread.CurrentPrincipal.Identity.Name;
}

Wir verändern eine einfache Konsolenanwendung, die diesen Webdienst aufruft. Der Client sieht anfänglich so aus:

static void Main(string[] args) {
    localhost.Sample svc = new localhost.Sample();
    try {
        Console.WriteLine( svc.WhoAmI() );
    } catch ( Exception ex ) {
        Console.WriteLine( ex.ToString() );
    } finally {
        svc.Dispose();
    }
}

Wenn bei dem Webdienst/der Anwendung keine Sicherheit angewendet wird, gibt die Main-Funktion die folgende Information aus:

Bild04

Abbildung 4. Ausführung ohne Sicherheit, daher keine Identität

Wenn Sie, wie in Abbildung 3 gezeigt, den anonymen Zugriff ausgeschaltet haben, kann der Client nicht auf den Webdienst zugreifen. Stattdessen wird die folgende Meldung angezeigt:

System.Net.WebException: Die Anforderung ist mit
 HTTP-Statuscode 401 fehlgeschlagen: Zugriff verweigert.

Woran liegt das? Standardmäßig hat ein Webdienstproxy keine Informationen darüber, wer der Aufrufer ist oder welche Anmeldeinformationen übertragen werden sollen. Da der Proxy sich nicht selbst authentifizieren kann, erzeugt der Versuch, die Webmethode aufzurufen, einen Ausnahmefehler. Wenn Sie die richtigen Anmeldeinformationen für den aktuellen Benutzer übergeben wollen, ist es das Einfachste, die Standardanmeldeinformationen dieses Benutzers zu übermitteln. Der Try-Block des Clients muss folgendermaßen geändert werden:

svc.Credentials = 
    System.Net.CredentialCache.DefaultCredentials;
Console.WriteLine( svc.WhoAmI() );

Dies ermöglicht dem Proxy den Zugriff auf die Webmethode, da er die Anmeldeinformationen des aktuellen Benutzers erhält und sie auf Anforderung an die Webmethode übergeben kann. Der Webdienst gibt folgendes Ergebnis zurück:

Als Benutzer ausführen : REDMOND\sseely

Dieser Weg funktioniert sowohl mit Standard- als auch mit Digestauthentifizierung. Die Authentifizierungsinformationen sind nur für einen Webdienstaufruf verwendbar. Anders ausgedrückt kann der Webdienstcode nicht andere Webdienste aufrufen und sich als der Aufrufer ausgeben, der diese Mechanismen verwendet. Denken Sie daran, bei Standardauthentifizierung auch eine SSL-Verbindung für die Datei zu verlangen, um die Benutzeridentität vor dem Ausspionieren der Verbindung zu schützen. Manchmal werden Sie eine andere Identität als den aktuellen Benutzer verwenden wollen, um damit auf den Webdienst zuzugreifen. Damit Sie dies tun können, richten Sie Ihre Anmeldeinformationen "manuell" ein.

Auf meinem lokalen Webserver sseely2 habe ich einen Benutzer Example mit dem Kennwort Test$123 eingerichtet. Um die Anmeldeinformationen manuell einzugeben, muss ein CredentialCache angelegt werden. Der Code, der den CredentialCache verwendet, muss den Cache mit NetworkCredential-Objekten füllen. Wenn dem Cache ein NetworkCredential hinzugefügt wird, muss der Code angeben, welche Kombination von URL und Authentifizierungsart bei der Rückgabe der gegebenen Anmeldeinformationen verwendet werden soll.

Der Cache kann mit Identitätsinformationen für eine Reihe von Sites gefüllt werden und für jede Site intelligent die richtige Anmeldeinformation und Authentifizierungsart zurückgeben. Verwenden Sie den folgenden Code, um den Cache so einzurichten, dass er die richtigen Anmeldeinformationen für eine Standardauthentifizierungsanforderung eines Webdienstes sendet:

localhost.Sample svc = new localhost.Sample();
try {
    CredentialCache credCache = new CredentialCache();
    NetworkCredential netCred = 
        new NetworkCredential( "Example", "Test$123", "sseely2" );
    credCache.Add( new Uri(svc.Url), "Basic", netCred );
    svc.Credentials = credCache;
    Console.WriteLine( svc.WhoAmI() );

Beim Einlesen des URL, der in der Zeile mit credCache.Add verwendet wird, werden Sie feststellen, dass der URL vom Webdienst stammt, also nicht fest codiert ist oder aus einer anderen Quelle stammt. Ich codiere Aufrufe der Add-Methode gern auf diese Weise, da es so am einfachsten ist, sicherzustellen, dass der Endpunkt vom Webdienst und der vom Add-Aufruf identisch sind.

Wenn Sie die gleichen Anmeldeinformationen für Digestauthentifizierung verwenden möchten, lautet die Zeile, die dem Cache die Informationen hinzufügt, so:

credCache.Add( new Uri(svc.Url), "Digest", netCred );

Standardauthentifizierung funktioniert bei Benutzern, die auf einem lokalen Computer oder im Verzeichnis registriert sind. Digestauthentifizierung akzeptiert nur Benutzer, die in einer vertrauenswürdigen Windows-Domäne registriert sind.

Ein weiterer Weg, Aufrufer von Webdiensten zu authentifizieren, ist die gegenseitige Authentifizierung über SSL. Absender und Empfänger der SOAP-Nachrichten können dabei Zertifikate austauschen und sich gegenseitig überprüfen. Der Server hat ein Zertifikat, wenn er über SSL verfügt.

Der Client verfügt dann über ein Zertifikat, wenn es in irgendeiner Form für ihn ausgegeben wurde. Wenn Sie über ein Serverzertifikat verfügen, müssen Sie ein Zertifikat für sich selbst ausstellen und dann das Zertifikat Ihrem Benutzerkonto über das Dialogfeld in Abbildung 2 zuordnen. Mehr Informationen über die Zuordnung finden Sie unter Mapping Client Certificates to User AccountsHier verlassen Sie die Website von Microsoft Deutschland (in Englisch).

Wenn Sie über Zertifikate verfügen, können Sie in der Systemsteuerung über die Internetoptionen auf diese zugreifen. Am einfachsten greifen Sie mit dem Microsoft® Internet Explorer auf diese Optionen zu. Installieren Sie jetzt ein Zertifikat, falls Sie noch nicht über eines verfügen. Starten Sie den Internet Explorer, und wechseln Sie zu einem Windows-Server mit installiertem Certificate Server. Geben Sie den URL http://machine_name/certsrv ein. Folgen Sie den Bildschirmanweisungen, um ein Clientzertifikat anzufordern und zu installieren. Klicken Sie dann im Internet Explorer im Menü Extras auf Internetoptionen, danach auf die Registerkarte Inhalte und anschließend auf Zertifikate. Ein Dialogfeld ähnlich dem in Abbildung 5 wird angezeigt.

Bild05

Abbildung 5. Das Dialogfeld "Zertifikate"

Sie müssen ein Zertifikat exportieren, damit es für die Webdienst-Proxyauthentifizierung verwendet werden kann. Klicken Sie hierfür auf Exportieren, um den Zertifikatsexport-Assistenten aufzurufen. Klicken Sie im Assistenten jeweils auf Weiter, um alle Standardeinstellungen zu akzeptieren, und geben Sie einen Dateinamen ein, in den das Zertifikat geschrieben wird. In meinem Beispiel habe ich das Zertifikat unter c:\temp\secSample.cer gespeichert. Klicken Sie auf Weiter und anschließend auf Fertig stellen. Dieses Zertifikat müssen wir jetzt mit einem bestimmten Benutzer verbinden.

  1. Wiederholen Sie den Vorgang, den Sie verwendet haben, um entweder einen oder alle Webdienste durch SSL zu sichern. (Siehe hierzu den Abschnitt unter "Verschlüsselung und Signierung mit SSL", der mit dem Öffnen der IIS Management Console beginnt.)

  2. Aktivieren Sie das Kontrollkästchen Zuordnung von Clientzertifikaten aktivieren und klicken Sie auf Bearbeiten.

  3. Klicken Sie auf der Registerkarte für 1:1-Zuordnung auf Hinzufügen.

  4. Wählen Sie c:\temp\secSample.cer aus.

  5. Geben Sie im Dialogfeld Kontozuordnung die folgenden Optionen ein:

    • Zuordnungsname: HTTP Sample Mapping

    • Konto: Wählen Sie ein Konto aus. In meinem Fall habe ich sseely2\Example ausgewählt.

    • Kennwort: Entsprechend dem Kennwort des Kontos. Ich habe hier Test$123 angegeben.

    Es ist nicht falsch, wenn die Zertifikatsidentität und die mit dem Zertifikat verbundene Identität nicht übereinstimmen. Wenn der Server ein Zertifikat mit einer Identität abgleicht, sucht er einfach im Speicher nach einem weiteren Zertifikat, das genau mit dem empfangenen übereinstimmt. Warum? Es ist möglich, dass jemand ein Clientzertifikat hat, das von einer öffentlichen Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Bei Verwendung der SSL-Clientauthentifizierung kann der Server dieses Zertifikat einer Identität auf dem Hostcomputer zuordnen, ohne mit dem Aussteller des Zertifikats in irgendeiner Weise verbunden zu sein.

  6. Bestätigen Sie das Kennwort durch Klicken, und klicken Sie drei weitere Male auf OK, um das Dialogfeld zu schließen.

Sie müssen jetzt die anderen Optionen in IIS einrichten. Deaktivieren Sie zuerst alle verfügbaren Authentifizierungsmethoden, so dass für die geschützte Ressource (.asmx-Datei oder virtuelles Verzeichnis) die Berechtigungen so eingerichtet sind, wie in Abbildung 6 gezeigt wird.

Bild06

Abbildung 6. Alle Authentifizierungsmethoden sind deaktiviert

Fordern Sie danach Clientzertifikate an, wie in Abbildung 7 gezeigt.

Bild07

Abbildung 7. Anfordern von SSL und Clientzertifikaten

Zum Schluss muss der Client so eingerichtet werden, dass er ein Zertifikat aus einer Datei lädt und es dem Webserver zur Verfügung stellt. Die System.Security.Cryptography.X509Certificates.X509Certificate-Klasse kann ein X.509-Zertifikat lesen. Lesen Sie das Zertifikat ein, und fügen Sie es der Proxyauflistung von Clientzertifikaten hinzu.

static void Main(string[] args) {
    localhost.Sample svc = new localhost.Sample();
    try {
        X509Certificate x509 = X509Certificate.CreateFromCertFile(
            @"c:\temp\secSample.cer");
        svc.ClientCertificates.Add( x509 );
        Console.WriteLine( svc.WhoAmI() );
    } catch ( Exception ex ) {
        Console.WriteLine( ex.ToString() );
    } finally {
        svc.Dispose();
    }
}

Das Ergebnis lautet wie erwartet:

Als Benutzer ausführen : SSEELY2\example

Bei Verwendung von Standard-/Digestauthentifizierung oder X.509 können Sie auch ACL-Zugriffssteuerungslisten einsetzen, um zu definieren, welche Benutzer Zugriff auf das Verzeichnis haben. Sie können den Windows-Explorer verwenden, um die ACL für eine Datei oder ein Verzeichnis anzuzeigen. Klicken Sie mit der rechten Maustaste auf die Datei und dann auf Eigenschaften. Auf der Registerkarte Sicherheitseinstellungen können Sie Benutzer und Benutzergruppen hinzufügen oder entfernen und die Dateiberechtigungen festlegen.
Die Benutzer des Webdienstes sollen nicht immer dem Active Directory hinzugefügt werden. Stattdessen kann es vorteilhaft sein, diese Informationen an anderer Stelle zu speichern. Es gibt zwei übliche Vorgehensweisen, um dieses Problem zu lösen. Die eine ist, jedem Benutzer einen Benutzernamen und ein Kennwort zu geben. Für sichere Webseiten ist diese Methode üblich.

Die Anmeldeinformationen werden über SOAP-Header und andere Mechanismen übermittelt. Das Codebeispiel Cold StorageHier verlassen Sie die Website von Microsoft Deutschland (in Englisch) verwendet benutzerdefinierte SOAP-Header und ein HTTP-Modul für die Authentifizierung. Eine weitere Lösung beinhaltet das Erstellen eines benutzerdefinierten Anmeldewebdienstes. Hierbei meldet sich der Benutzer über einen sicheren Kanal wie SSL an und erhält ein Token, das beim Aufruf anderer Methoden des Webdienstes verwendet wird. Diese Methode wurde für den Webdienst Favorites ServiceHier verlassen Sie die Website von Microsoft Deutschland (in Englisch) verwendet.

Verwenden von Codezugriffssicherheit

Bisher haben wir nur Wege zur Identifizierung des Benutzers aufgezeigt. Wenn wir wissen, wer der Benutzer ist, können wir diese Information verwenden, um den Benutzer für den Zugriff auf eine oder mehrere Methoden des Webdienstes zu autorisieren. Der Benutzer im Beispiel ist Mitglied der Gruppe sseely2\SampleGroup. Wenn ich den Zugriff auf die WhoAmI-Webmethode auf die Mitglieder dieser Gruppe beschränken möchte, kann ich das System.Security.Permissions.PrincipalPermissionAttribute-Attribut anwenden. Ich würde folgenden Code verwenden:

[WebMethod]
[PrincipalPermissionAttribute(SecurityAction.Demand, 
        Authenticated=true,
        Name=@"sseely2\Example",
        Role=@"sseely2\SampleGroup")]
public string WhoAmI() {
    return "Als Benutzer ausführen : " + 
        Thread.CurrentPrincipal.Identity.Name;
}

Der obige Code ist etwas ungewöhnlich. Er verlangt, dass die Identität des Aufrufers bekannt ist, dass der Aufrufer zur Gruppe sseely2\SampleGroup gehört und dass der Name des Aufrufer sseely2\Example ist. Es ist üblicher, die Zugehörigkeit zu einer bestimmten Gruppe zu verlangen. Diese Vorgehensweise stellt einen einfachen Weg dar, den Zugriff auf bestimmte Webmethoden zu gewähren oder zu verweigern. Verwenden Sie Codezugriffssicherheit - wenn Sie den Zugriff auf .asmx-Ebene schützen, reichen Zugriffssteuerungslisten nicht aus.

Interoperabilität

Ich würde meine Pflichten vernachlässigen, wenn ich nicht etwas zur Interoperabilität der oben angeführten Sicherheitsmechanismen sagte. Wenn Sie Zugriffe von Nicht-Microsoft-Toolkits auf Ihren Webdienst erwarten, besteht der bewährteste Sicherheitsmechanismus mit der größten Interoperabilität darin, Standardauthentifizierung zur Identifizierung des Aufrufers und SSL zur Verschlüsselung des Kanals zu verwenden. Wenn dieser Mechanismus mit der Integrierten Windows-Authentifizierung verwendet wird, müssen Sie die Benutzernamen und Kennwörter entweder den Benutzern des Webservers oder dem entsprechenden Windows-Domänencontroller hinzufügen. Hierfür gibt es einen einfachen Grund: Viele Webdienststapel beinhalten keinen HTTP-Teil, der die Digestauthentifizierung verarbeiten kann. In vielen Fällen unterstützt die SSL/SOAP-Kombination möglicherweise nicht das Senden eines clientseitigen X.509-Zertifikats.

Zusammenfassung

Sie können einen Webdienst mithilfe einer Kombination von IIS- und ASP.NET-Features sichern. ASP.NET-Webdienste verwenden einen Anmeldungsinformationscache, um auf Anforderungen für verschiedene Authentifizierungsarten zu antworten.

Standard- und Digestauthentifizierung sowie SSL haben alle den gleichen Nachteil: Es müssen Nachrichten zwischen dem Sender und dem Empfänger der SOAP-Nachricht ausgetauscht werden, bevor die Nachricht sicher übermittelt werden kann. Dieses Handshaking kann die Übertragungsgeschwindigkeit der SOAP-Nachrichten beeinträchtigen.

Beschleunigung ist eines der Motive hinter der WS-Security-SpezifikationHier verlassen Sie die Website von Microsoft Deutschland- (in Englisch). WS-Security verwirft die Transportprotokolltechniken zugunsten eines nachrichtenzentrierten Sicherheitsmodells. Bis WS-Security in weitem Umfang verstanden und angewendet wird, bieten HTTP-basierte Sicherheitsmechanismen die beste Sicherheitsmöglichkeit für Ihre Webdienste.

Ressourcen


Anzeigen: