HTTP-Sicherheit und ASP.NET-Webdienste

  • Artikel

 

Scott Seely
TEAM FÜR MSDN-Architekturbeispiele

August 2002

Gilt für:
   Microsoft® ASP.NET
   Microsoft® Internet Information Services (IIS)
   HTTP-Sicherheit
   Webdienste

Zusammenfassung: HTTP-basierte Sicherheitsmechanismen sind derzeit die beste Möglichkeit, Ihre Webdienste zu schützen. Erfahren Sie, wie Sie einen Webdienst mithilfe einer Kombination von Features in Microsoft IIS und Microsoft ASP.NET schützen. (14 gedruckte Seiten)

Hinweis In diesem Artikel wird davon ausgegangen, dass Sie mit der Verwendung von SSL mit IIS vertraut sind.

Inhalte

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

Einführung

Ein Punkt, der Entwickler von Webdiensten verrückt zu machen scheint, ist herauszufinden, wie IIS und ASP.NET Webdienste zusammenarbeiten, um Sicherheit zu bieten. Heute wird die Sicherheit von IIS verwaltet und von ASP.NET genutzt. ASP.NET können die von IIS bereitgestellten Identitätsinformationen verwenden, um zu wissen, wer aufgerufen hat oder um die Codezugriffssicherheit für bestimmte Vorgänge im Webdienst zu nutzen. Der schwierige Teil besteht für viele darin, dass die .NET-Anwendung die integrierten IIS-Sicherheitsfeatures nutzen kann. In nicht allzu ferner Zukunft wird WS-Security eine noch bessere Option sein. Bis zu diesem Tag wird sicherheit auf HTTP-Ebene das, was viele von uns verwenden, um Messaging sicher zu machen.

Beim sicheren Ausführen einer Webmethode müssen die folgenden Elemente behandelt werden:

  • Durch Vertraulichkeit werden die Daten für Entitäten, die die Unterhaltung lauschen, undurchsichtig.
  • Die Integrität bietet Empfängern die Möglichkeit, Änderungen an der SOAP-Nachricht zu erkennen.
  • Die Authentifizierung beantwortet die Frage "Wer ist der Anrufer?"
  • Die Autorisierung beantwortet die Frage: "Hat der Aufrufer das Recht, auf diese Webmethode zuzugreifen?"
  • Die Nichtrerepudation beweist, dass eine Aktion aufgetreten ist, um zu verhindern, dass der Client eine Transaktion betrügerisch abtrünnte.

Viele dieser Sicherheitsfeatures kommen nicht allein. Die Authentifizierung ermöglicht die Autorisierung und Nichtanweisung. Die von SSL bereitgestellten Vertraulichkeitsmaßnahmen umfassen auch Mechanismen für Integrität und Authentifizierung. In diesem Artikel wird davon ausgegangen, dass Sie bereits mit der Verwendung von SSL mit IIS vertraut sind. Andernfalls sehen Sie sich die Ressourcen am Ende dieses Artikels an. Ich würde auch empfehlen, einen Microsoft® Windows® Server zu suchen, auf dem Der Zertifikatserver installiert ist (oder den Zertifikatserver auf einem verfügbaren Windows Server-Computer zu installieren). Es ist hilfreich, wenn Sie die SSL-orientierten Abschnitte dieses Artikels befolgen.

Verschlüsselung und Signatur mit SSL

Wenn Sie die Informationen in einer HTTP-basierten SOAP-Nachricht vertraulich behandeln müssen, sollten Sie den Dienst über SSL ausführen. Dadurch bleiben die Daten im Webdienst für alle Entitäten ausgeblendet, die die Datenübertragung über das Kabel untersuchen.

Um die Informationen in diesem Abschnitt verwenden zu können, müssen Sie bereits ein X.509-Zertifikat im Stammverzeichnis Ihres Webservers eingerichtet haben. Informationen dazu finden Sie unter HowTO: Configure SSL in a Windows 2000 IIS 5.0 Test Environment Using Certificate Server 2.0 (Q290625) (HowTO: Configure SSL in a Windows 2000 IIS 5.0 Test Environment Using Certificate Server 2.0 (Q290625). Wenn ein Zertifikat ordnungsgemäß installiert ist, können Sie die SSL-Authentifizierung für das virtuelle Verzeichnis oder eine bestimmte Datei erzwingen.

So öffnen Sie die Internetinformationsdienste-Verwaltungskonsole

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

  2. Geben Sie im Feld Bearbeiten öffnenden Namen inetmgr ein.

  3. Klicken Sie auf OK.

    Die IIS-Verwaltungskonsole wird geöffnet.

Die Anforderung von SSL für das virtuelle Verzeichnis oder eine bestimmte Datei ist eine Frage der Auswahl der richtigen Optionen in IIS. Um die "richtigen Optionen" auszuwählen, navigieren Sie zum virtuellen Verzeichnis im IIS-Verwaltungskonsole. Wenn Sie SSL für alle Webdienste benötigen möchten, auf die über ein bestimmtes virtuelles Verzeichnis zugegriffen werden kann, klicken Sie mit der rechten Maustaste auf das virtuelle Verzeichnis, klicken Sie auf Eigenschaften, und klicken Sie dann auf die Registerkarte Verzeichnissicherheit .

Um nur einen bestimmten Webdienst zu schützen, klicken Sie mit der rechten Maustaste auf die asmx-Datei, die diesem Webdienst zugeordnet ist, klicken Sie auf Eigenschaften, und klicken Sie dann auf die Registerkarte Dateisicherheit . Für beide Prozeduren wird ein Dialogfeld ähnlich dem in Abbildung 1 angezeigten angezeigt. Klicken Sie unter Sichere Kommunikation auf Bearbeiten. Das Dialogfeld Sichere Kommunikation wird wie in Abbildung 2 dargestellt geöffnet.

Abbildung 1. Registerkarte Sicherheit im IIS-Verwaltungskonsole

Abbildung 2. Dialogfeld "Sichere Kommunikation"

Standardmäßig ist das Kontrollkästchen Sicheren Kanal (SSL) anfordern deaktiviert. Wählen Sie sie aus, um SSL zu erfordern. SSL unterstützt sowohl die 40-Bit- als auch die 128-Bit-Verschlüsselung. Je mehr Bits von der Verschlüsselung verwendet werden, desto schwieriger ist es, sie zu unterbrechen und herauszufinden, was die ursprünglichen Bits waren. Dies ist alles, was Sie tun müssen, um SSL für eine bestimmte ASMX-Datei oder einen gesamten Webdienst zu aktivieren. Dadurch ist die Kommunikation zwischen jedem Webdienstclient und dem Webdienst selbst sicher, solange das Zertifikat des Webservers nicht kompromittiert wird. SSL verwendet X.509-Zertifikate, die einen öffentlichen Schlüssel und möglicherweise auch einen privaten Schlüssel enthalten. Wenn der private Schlüssel einer externen Person bekannt wird, sind mit dem öffentlichen Schlüssel verschlüsselte Kommunikationen nicht mehr sicher vor der Überprüfung durch diesen Externen.

Sobald Sie die Ressource so eingerichtet haben, dass ssl für die Kommunikation erforderlich ist, werden alle zwischen Absender und Empfänger gesendeten Nachrichten verschlüsselt und signiert. Dies bedeutet, dass Externe den Inhalt der Nachrichten nicht lesen können. Wenn ein Externer die Bytes in der Nachricht ändert, kann der Nachrichtenempfänger sie erkennen.

Authentifizierung

Um die Authentifizierung zu nutzen, die IIS für Sie ausführt, müssen Sie die Web.config Datei bearbeiten, die Ihrem Webdienst zugeordnet ist. Damit die Identität des Benutzers im HttpContext verfügbar ist, müssen Sie das Attribut /configuration/system.web/authentication/@mode auf Windows festlegen. Das Mode-Attribut muss festgelegt werden, wenn IIS eine der folgenden Authentifizierungsoptionen verwendet: Basic, Digest, Integrated Windows Authentication (NTLM/Kerberos) oder X.509-Zertifikate. Die Benutzeranmeldeinformationen, die von einer dieser Authentifizierungsoptionen angezeigt werden, müssen einem Benutzer zugeordnet werden, der entweder auf dem lokalen Computer oder in Active Directory vorhanden ist.

Die Kombination aus IIS und den richtigen Web.config Einstellungen ermöglicht es dem Webdienst, die Identität des Aufrufers zu ermitteln. Als zusätzlichen Bonus übernimmt der Anforderungskontext die Identität des Aufrufers. Wenn Sie Windows-Authentifizierung verwenden möchten, muss die Web.config-Datei wie folgt aussehen:

<configuration>
    <system.web>
        <authentication mode="Windows" />
        <!-- other elements go here -->
    </system.web>
</configuration>

Für die Behandlung von Autorisierung, Überwachung und Nichtreudiation ist es wichtig, Windows-Authentifizierung zu aktivieren. Dadurch kann Ihre Webmethode als Aufrufer ausgeführt werden. Alle Protokollierungen, Zugriffsprüfungen usw. werden basierend auf den Berechtigungen des Benutzers durchgeführt.

Damit IIS erzwingt, dass die Identität des Aufrufers angezeigt wird, müssen Sie ihn anweisen, den anonymen Zugriff zu deaktivieren. Das ist wirklich alles. Wechseln Sie dazu zurück, und öffnen Sie inetmgr (klicken Sie auf Start, klicken Sie auf Ausführen, und geben Sie dann inetmgr ein). Navigieren Sie zum relevanten 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 klicken Sie dann auf Eigenschaften. Klicken Sie wie in Abbildung 1 dargestellt auf die Registerkarte Verzeichnissicherheit . Klicken Sie unter Anonyme Zugriffs- und Authentifizierungssteuerung auf Bearbeiten. Das Dialogfeld Authentifizierungsmethoden wird wie in Abbildung 3 dargestellt geöffnet.

Abbildung 3. Dialogfeld Authentifizierungsmethoden mit deaktiviertem anonymem Zugriff

Im Dialogfeld Authentifizierungsmethoden können Sie konfigurieren, wie Benutzer auf das virtuelle Verzeichnis oder die datei zugreifen können. Um die Anmeldeinformationen des Benutzers über die HTTP-Header zu übergeben, können Sie die Standard- oder Digestauthentifizierung verwenden. Weder die Standardauthentifizierung noch die Digestauthentifizierung bieten einen Mechanismus zum Schützen der Nachricht. Der Mechanismus zum Übergeben der Benutzeranmeldeinformationen wird durch RFC 2617: HTTP-Authentifizierung: Standard- und Digestzugriffsauthentifizierung definiert. Im Wesentlichen wird ein HTTP-Header namens Authorization verwendet, um den Benutzernamen und das Kennwort zu übergeben. Bei der Standardauthentifizierung wird die Kombination benutzername/kennwort in Klartext gesendet. Nun, nicht genau. Der Benutzername und das Kennwort werden tatsächlich mithilfe der Base64-Codierung gesendet, bei der es sich einfach um Klartext handelt. Für diejenigen von Ihnen, die mit der Base64-Codierung nicht vertraut sind, ist dies eine Möglichkeit, Binärdaten zu verwenden und diese Daten als Text darzustellen. Beim Codieren der Daten werden keine Geheimnisse/Schlüssel verwendet. Wenn Sie sich für die Standardauthentifizierung entscheiden, sollten Sie diese Anmeldeinformationen nur über SSL akzeptieren. Dadurch werden der Webdienst und der Aufrufer vor einer Entität geschützt, die den Kanal bei dem Versuch, einen gültigen Satz von Anmeldeinformationen zu erfassen, erschnüffelt hat.

Eine weitere Möglichkeit besteht darin, die Digestauthentifizierung zu verwenden. Wenn Sie diese Wahl treffen, sollten Sie verstehen, dass viele SOAP-Toolkits die Digestauthentifizierung nicht unterstützen. Daher beschränken Sie die Anzahl der Toolkits, die den Webdienst verwenden können. Verwenden Sie die Digestauthentifizierung, wenn Sie die Identität des Aufrufers kennen möchten, SOAP-Zieltoolkits Unterstützung für die Digestauthentifizierung enthalten und der Inhalt der SOAP-Nachrichten nicht besonders wichtig ist. Die Digestauthentifizierung verschlüsselt die Anmeldeinformationen des Aufrufers mithilfe eines freigegebenen Geheimnisses, das als Nonce bezeichnet wird.

Sowohl die Standard- als auch die Digestauthentifizierung verwenden Challenge-Response-Mechanismen. Aus diesem Zweck werden mehrere Anforderungen und Antworten zwischen dem Client und dem Empfänger gesendet, bevor überhaupt ein Aufruf der Webmethode erfolgt. Bei der Standardauthentifizierung können Die Herausforderung und Die Antwort ziemlich schnell sein. Tatsächlich kann ein Client Basic-Anmeldeinformationen im Voraus angeben, wenn er weiß, dass die Standardauthentifizierung erforderlich ist. Diese Beschleunigung kann bei einer SSL-basierten Verbindung, bei der das Serverzertifikat überprüft und ein Sitzungsschlüssel eingerichtet wird, von untergeordnetem Wert sein. Bei der Digestauthentifizierung muss die Nonce ausgetauscht werden, bevor die Anmeldeinformationen verschlüsselt werden. Auch hierfür ist ein Handshaking erforderlich, bevor Webdienstcode ausgeführt wird.

Um zu erzwingen, dass diese Elemente für Ihren Webdienst aktiviert werden, wählen Sie einfach die entsprechenden Felder im Dialogfeld Authentifizierungsmethoden aus. Wenn Sie sicherstellen möchten, dass sie nur authentifizierte Benutzer erhalten, stellen Sie sicher, dass das Kontrollkästchen Anonymer Zugriff deaktiviert ist. Sobald dies geschehen ist, können Sie die folgenden serverseitigen Schritte ausführen:

  • Ermitteln Sie, wer der Aufrufer ist.
  • Verwenden Sie die Codezugriffssicherheit, um einzuschränken, wer welche Methoden aufruft.

Der folgende Webdienst gibt die aktuellen Aufruferinformationen zurück:

[WebMethod]
public string WhoAmI() {
    return "Running as User : " +
        Thread.CurrentPrincipal.Identity.Name;
}

Wir ändern eine einfache Konsolenanwendung, die diesen Webdienst aufruft. Zunächst sieht der Client wie folgt 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 keine Sicherheit auf den Webdienst/die Anwendung angewendet wird, gibt die Main-Funktion die folgenden Informationen aus:

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

Wenn Sie den anonymen Zugriff über das in Abbildung 3 gezeigte Dialogfeld deaktivieren, kann der Client nicht auf den Webdienst zugreifen. Stattdessen wird folgende Fehlermeldung angezeigt:

System.Net.WebException: The request failed with HTTP status 401: Access Denied.

Warum? Standardmäßig verfügt ein Webdienstproxy über keine Informationen über den Aufrufer oder die zu übergebenden Anmeldeinformationen. Da sie sich nicht authentifizieren kann, schlägt der Versuch, die Webmethode aufzurufen, fehl, und es wird eine Ausnahme ausgelöst. Wenn Sie die richtigen Anmeldeinformationen für den aktuellen Benutzer übergeben möchten, ist es am einfachsten, die Standardanmeldeinformationen des aktuellen Benutzers zu übergeben. Der try-Block im Client muss geändert werden, um Folgendes zu lesen:

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

Dadurch kann der Proxy auf die Webmethode zugreifen, da er die Anmeldeinformationen des aktuellen Benutzers annehmen und bei Einer Aufforderung an die Webmethode übergeben kann. Der Webdienst gibt das folgende Ergebnis zurück:

Running as User : REDMOND\sseely

Dies funktioniert sowohl bei der Standard- als auch bei der Digestauthentifizierung. Die Authentifizierungsinformationen sind nur für einen Webdienstaufruf geeignet. Anders ausgedrückt: Der Webdienstcode kann mithilfe dieser Mechanismen keine anderen Webdienste aufrufen und die Identität des Aufrufers annehmen. Wenn Sie sich für die Standardauthentifizierung entscheiden, sollten Sie auch eine SSL-Verbindung für diese Datei benötigen, damit die Identität des Benutzers nicht für eine Entität verfügbar gemacht wird, die die Verbindung überwacht. Manchmal möchten Sie mit einer Identität, die sich vom aktuellen Benutzer unterscheidet, auf den Webdienst zugreifen. Wie können Sie dieses Ziel erreichen? Sie legen die Anmeldeinformationen "manuell" fest.

Auf meinem lokalen Webserver habe ich einen Benutzer namens sseely2 mit dem Namen Example , dessen Kennwort Test$123 lautet. Um die Anmeldeinformationen manuell festzulegen, muss ein CredentialCache erstellt werden. Der Code, der den CredentialCache verwendet, muss den Cache mit NetworkCredential-Objekten auffüllen. Beim Hinzufügen von NetworkCredential zum Cache muss der Code angeben, welche URL/Authentifizierungstyp-Kombination verwendet werden soll, um die angegebenen Anmeldeinformationen zurückzugeben. Es ist möglich, den Cache mit Identitätsinformationen für eine Reihe von Websites aufzufüllen und den Cache intelligent die richtigen Anmeldeinformationen für jeden Standort und Authentifizierungstyp zurückzugeben. Verwenden Sie den folgenden Code, um den Cache so einzurichten, dass die richtigen Anmeldeinformationen für eine Standardauthentifizierungsanforderung vom Webdienst gesendet werden:

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() );

Wenn Sie die URL übergeben, die in der Zeile verwendet werden soll, die credCache.Add enthält, werden Sie feststellen, dass die URL aus dem Webdienst übernommen wird, anstatt hartcodiert oder aus einer anderen Quelle ausgewählt zu werden. Ich möchte Aufrufe der Add-Methode auf diese Weise codieren, da es den geringsten Aufwand erfordert, sicherzustellen, dass der Webdienstendpunkt und der vom Add-Aufruf verwendete Endpunkt identisch sind.

Wenn Sie dieselben Anmeldeinformationen für die Digestauthentifizierung verwenden möchten, lautet die Zeile zum Hinzufügen der Informationen zum Anmeldeinformationscache:

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

Die Standardauthentifizierung funktioniert für Benutzer, die auf dem lokalen Computer registriert sind, oder für einen Benutzer, der im Verzeichnis registriert ist. Die Digestauthentifizierung akzeptiert nur Benutzer, die in einer vertrauenswürdigen Windows-Domäne registriert sind.

Eine weitere Möglichkeit zum Authentifizieren von Webdienstaufrufern ist die gegenseitige Authentifizierung über SSL. Absender und Empfänger der SOAP-Nachricht können Zertifikate austauschen und sich gegenseitig überprüfen. Der Server verfügt über ein Zertifikat, wenn er SSL-fähig ist. Der Client verfügt über ein Zertifikat, wenn es in irgendeiner Form für den Client ausgestellt wurde. Wenn Sie über einen Zertifikatserver verfügen, müssen Sie sich selbst ein Zertifikat ausstellen und das Zertifikat dann über das in Abbildung 2 gezeigte Dialogfeld Ihrem Benutzerkonto zuordnen. Weitere Informationen finden Sie unter Zuordnen von Clientzertifikaten zu Benutzerkonten .

Wenn Sie über Zertifikate verfügen, können Sie über das Internetoptionen-Applet im Systemsteuerung darauf zugreifen. Die einfachste Möglichkeit, auf dieses Applet zuzugreifen, ist über Microsoft® Internet Explorer. Wenn Sie kein Zertifikat installiert haben, sollten Sie jetzt ein Zertifikat erhalten. Öffnen Sie einfach internet Explorer, und navigieren Sie zu einem Windows Server-Computer, auf dem der Zertifikatserver installiert ist. Die gewünschte URL lautet http:// machine_name/certsrv. Befolgen Sie die Anweisungen auf dem Bildschirm, um ein Clientzertifikat anzufordern und zu installieren. Klicken Sie als Nächstes in Internet Explorer im Menü Extras auf Internetoptionen, klicken Sie auf die Registerkarte Inhalt und dann auf Zertifikate. Es sollte ein Dialogfeld ähnlich dem in Abbildung 5 angezeigt werden.

Abbildung 5. Dialogfeld "Zertifikate"

Sie müssen ein Zertifikat exportieren, damit es für die Webdienstproxyauthentifizierung verwendet werden kann. Klicken Sie zum Exportieren eines Zertifikats auf Exportieren , um den Zertifikatexport-Assistenten zu öffnen. Klicken Sie im Assistenten auf Weiter , um alle Standardwerte zu übernehmen, und wählen Sie dann einen Dateinamen aus, in den das Zertifikat geschrieben werden soll. In meinem Fall habe ich das Zertifikat unter c:\temp\secSample.cer gespeichert. Klicken Sie auf Weiterund dann auf Fertig stellen. Nun müssen wir dieses Zertifikat einem bestimmten Benutzer zuordnen.

  1. Wiederholen Sie das Verfahren, mit dem Sie SSL erforderlich haben, um einen oder alle Webdienste zu schützen. (Weitere Informationen finden Sie im Abschnitt Verschlüsselung und Signieren mit SSL, beginnend mit dem Verfahren zum Öffnen der IIS-Verwaltungskonsole.)
  2. Aktivieren Sie das Kontrollkästchen Clientzertifikatzuordnung aktivieren , und klicken Sie auf Bearbeiten.
  3. Klicken Sie auf der Registerkarte 1:1-Zuordnung auf Hinzufügen.
  4. Wählen Sie c:\temp\secSample.cer aus.
  5. Legen Sie im Dialogfeld Konto zuordnen die folgenden Elemente fest:

    • Kartenname: HTTP-Beispielzuordnung

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

    • Kennwort: Wird dem Kennwort des Kontos zugeordnet. In meinem Fall habe ich Test$123 eingegeben.

      Es ist in Ordnung, wenn die Zertifikatidentität und die dem Zertifikat zugeordnete Identität nicht übereinstimmen. Beim Abgleich eines Zertifikats mit einer Identität sucht der Server einfach nach einem anderen Zertifikat in seinen Speichern, das genau mit dem empfangenen Zertifikat übereinstimmt. Warum? Es ist möglich, dass eine Person über ein Clientzertifikat verfügt, das von einer öffentlichen Zertifizierungsstelle (CA) ausgestellt wurde. Bei Verwendung der SSL-Clientauthentifizierung kann der Server dieses Zertifikat einer Identität auf dem Hostcomputer zuordnen, ohne dass er dem Aussteller dieses Zertifikats in irgendeiner Weise zugeordnet werden muss.

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

Jetzt müssen Sie die anderen Optionen in IIS einrichten. Zunächst müssen Sie alle verfügbaren Authentifizierungsmethoden löschen, damit für die geschützte Ressource (ASMX-Datei oder virtuelles Verzeichnis) die Berechtigungen festgelegt sind, wie in Abbildung 6 dargestellt.

Abbildung 6. Alle Authentifizierungsmethoden gelöscht

Fordern Sie dann Clientzertifikate an, wie in Abbildung 7 dargestellt.

Abbildung 7. Anfordern von SSL- und Clientzertifikaten

Schließlich muss der Client so konfiguriert werden, dass das Zertifikat aus einer Datei geladen und dem Webdienst angezeigt wird. Die System.Security.Cryptography.X509Certificates.X509Certificate-Klasse weiß, wie ein DER-codiertes X.509-Zertifikat gelesen wird. Um das Zertifikat zu laden und für den Webdienst verfügbar zu machen, lesen Sie das Zertifikat in, und fügen Sie es der Clientzertifikatsammlung des Proxys 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();
    }
}

Wie erwartet, lautet die Ausgabe:

Running as User : SSEELY2\example

Bei der Authentifizierung des Benutzers mithilfe der Standard-/Digest-Authentifizierung oder X.509 können Sie auch Access Control Lists (ACL) verwenden, um zu definieren, welche Benutzer Zugriff auf das Verzeichnis haben. Eine Möglichkeit zum Anzeigen der Zugriffssteuerungsliste für eine Datei oder ein Verzeichnis ist die Verwendung von Windows Explorer. Klicken Sie mit der rechten Maustaste auf die Datei und dann auf Eigenschaften. Auf der Registerkarte Sicherheit können Sie Benutzer und Benutzergruppen hinzufügen und entfernen sowie die Aktionen bearbeiten, die mit den Dateien ausgeführt werden können.

Sie möchten nicht immer Benutzer des Webdiensts zu Active Directory hinzufügen. Stattdessen kann es besser sein, diese Informationen an anderer Stelle zu speichern. Um dieses Problem zu lösen, sind zwei Ansätze ziemlich häufig. Ein Ansatz, der für gesicherte Websites üblich ist, besteht darin, jedem Benutzer einen Benutzernamen und ein Kennwort auszugeben. Diese Anmeldeinformationen können dann über SOAP-Header und andere Mechanismen übergeben werden. Im Cold Storage-Beispiel wurden benutzerdefinierte SOAP-Header und ein HTTP-Modul verwendet, um die Authentifizierung bereitzustellen. Ein weiterer Ansatz umfasst das Erstellen eines benutzerdefinierten Anmeldewebdiensts. Hier meldet sich der Aufrufer über einen sicheren Kanal wie SSL an und empfängt ein Token, das beim Aufrufen anderer Methoden im Webdienst verwendet werden soll. Diese Methode wurde für den Favoriten-Webdienst verwendet.

Verwenden der Codezugriffssicherheit

Bisher haben wir nur nach Möglichkeiten gesucht, den Benutzer eindeutig zu identifizieren. Sobald wir wissen, wer der Benutzer ist, können wir diese Informationen verwenden, um den Benutzer für den Zugriff auf eine oder mehrere Methoden innerhalb des Webdiensts zu autorisieren. Der Beispielbenutzer ist Mitglied der Gruppe sseely2\SampleGroup. Wenn ich den Zugriff auf die WhoAmI-Webmethode nur auf Mitglieder dieser Gruppe beschränken möchte, kann ich system.Security.Permissions anwenden. PrincipalPermissionAttribute-Attribut . Insbesondere würde ich den folgenden Code verwenden:

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

Der vorherige Code ist etwas extrem. Es erfordert, dass die ID des Aufrufers bekannt ist, dass der Aufrufer zur Gruppe sseely2\SampleGroup gehört und dass der Name des Aufrufers sseely2\Example lautet. Es ist üblicher, die Mitgliedschaft in einer bestimmten Gruppe zu verlangen. Die Verwendung dieser Technik bietet eine einfache Möglichkeit, den Zugriff auf bestimmte Webmethoden zu gewähren oder zu verweigern. Verwenden der Codezugriffssicherheit: Wenn Sie den Zugriff auf asmx-Ebene schützen, reicht die Verwendung von Zugriffssteuerungslisten nicht aus.

Interoperabilität

Ich wäre vermisst, wenn ich nicht etwas über die Interoperabilität der oben beschriebenen Sicherheitsmechanismen Erwähnung würde. Wenn Sie erwarten, dass Nicht-Microsoft-Toolkits auf Ihren Webdienst zugreifen, besteht der am meisten interoperable/am besten getestete Sicherheitsmechanismus darin, die Standardauthentifizierung zu verwenden, um den Aufrufer zu identifizieren, und SSL zum Verschlüsseln des Kanals. Wenn Sie diesen Mechanismus mit integriertem Windows-Authentifizierung verwenden, müssen Sie die Benutzernamen und Kennwörter entweder den Benutzern des Webservers oder dem entsprechenden Windows-Domänencontroller hinzufügen. Der Grund dafür ist einfach: Viele Webdienststapel enthalten keinen HTTP-Teil, der die Behandlung der Digestauthentifizierung versteht. In vielen Fällen enthält die SSL/SOAP-Kombination möglicherweise keine Unterstützung für das Senden eines clientseitigen X.509-Zertifikats.

Zusammenfassung

Sie können einen Webdienst mit einer Kombination aus Features in IIS und ASP.NET schützen. ASP.NET Webdienste verwenden einen Anmeldeinformationscache, um auf Anforderungen für verschiedene Authentifizierungstypen zu reagieren.

Die Standard-/Digestauthentifizierung und SSL haben alle den gleichen Nachteil: Sie erfordern, dass einige Nachrichten zwischen dem Absender und dem Empfänger der SOAP-Nachricht ausgetauscht werden, bevor die Nachricht sicher gesendet werden kann. Dieses Handshaking kann die Geschwindigkeit der Übertragung von SOAP-Nachrichten einschränken. Die Beschleunigung ist nur eine der Beweggründe für die WS-Security-Spezifikation. WS-Security verwirf Transportprotokolltechniken zugunsten eines nachrichtenorientierten Sicherheitsmodells. Bis WS-Security allgemein verstanden und bereitgestellt ist, sind HTTP-basierte Sicherheitsmechanismen die beste Möglichkeit, ihre Webdienste zu schützen.

Ressourcen