Sichere Datenübertragung mit XML Web Services

Das Thema "XML Web Services" erzeugt bei vielen Entwicklern vor Begehrlichkeit geweitete Augen. Doch so hilfreich XML Web Services zur Verbindung verschiedener Anwendungen und Rechnerwelten sind, lassen sie doch die Frage nach der Sicherheit zunächst unbeantwortet. Dieser Artikel zeigt, welche Sicherheitsmechanismen es gibt, wenn ASP.NET eingesetzt wird.

Auf dieser Seite

 Grundlegendes
 Vorsorge treffen
 Erweiterbares SOAP-Modell
 Web-Sicherheit bei Web Services
 Authentifizierungsvarianten
 Sicherheit in ASP.NET
 Besonderheit .NET - formlose Vorstellung
 Zusammenfassung

Grundlegendes

Sicherlich sind viele Unternehmen an der Web Services-Technologie interessiert. Und sicherlich haben schon einige von ihnen Beispielanwendungen implementiert, die entweder im Intranet oder gar über Firewall-Grenzen hinweg Daten über einen XML-Strom austauschen. Doch dürfte auch gelten, dass der ernsthafte und produktive Einsatz von XML-basierten Web Services wegen der fehlenden ausreichend guten Sicherheitsmodelle- und standards noch eine Zeit lang auf sich warten lassen wird.

In puncto Sicherheit wird immer auf die noch nicht vorhandenen Spezifikationen und Implementierungen für Web-Services-Sicherheit hingewiesen. Schließ;lich ergeben sich durch die von Web-Services-Anwendungen propagierte Vision der echten, plattform-, hersteller- und implementierungsübergreifenden B2B-Kommunikation groß;e Bedenken im Hinblick auf die Sicherheit.

Im Gegensatz zu klassischen Web-Anwendungen laufen in einer Web-Services-Welt viele Prozesse automatisch ab, bei denen eine ausreichende Authentifizierung und Autorisierung in Verbindung mit dem Einsatz von Signaturen zur Überprüfung der Integrität der XML-Nachrichten unabdingbar ist. Und die notwendigen Standards befinden sich derzeit noch in der Entwicklung.
Doch was ist so speziell an der Sicherheit für Web Services? Lassen Sie uns einen kurzen Blick auf diese Problemstellung werfen.

Vorsorge treffen

Einer der grundlegenden Standards in der Web-Services-Welt ist SOAP. Ursprünglich als Simple Object Access Protocol ins Leben gerufen, steht SOAP heute als eigenständiges Akronym und ist das XML-Kommunikationsprotokoll zum Austausch von Daten zwischen Clientanwendungen und Web Services.

SOAP war innerhalb der Spezifikation der Version 1.1 immer mit HTTP als Protokoll für den Übertragungskanal verknüpft. Obwohl diese Bindung ausdrücklich als ein optionaler Bestandteil von SOAP definiert wurde, haben sich sämtliche SOAP-Anbieter an diese Vorgabe gehalten.

Egal, ob IBM, Apache oder Microsoft: Alle bieten Ihre SOAP Stacks mit HTTP an; nur selten kommt es vor, dass ein alternatives Protokoll wie beispielsweise SMTP zum Einsatz kommt.

Und eben diese enge Beziehung zwischen SOAP und HTTP macht das Thema Sicherheit so undurchsichtig bzw. schwer nachvollziehbar. Wer sich Abschnitt 8 der SOAP-Spezifikation anschaut, wird schnell bemerken, dass jegliche Form von Sicherheit nicht die Aufgabe von SOAP war, ist und sein wird. SOAP ist eben nur der Standard zur Übertragung der gewünschten Daten.

Somit entwickelte sich in den letzen drei Jahren das ungeschriebene Gesetz, dass SOAP unsicher sei. Oder vielmehr, dass man Web Services besonders absichern müsse, da es ein potentiell groß;es Risiko darstellt, wenn man diese einsetzen möchte. Diese Sorge ist jedoch völlig unbegründet.

Ein einfaches Beispiel ist die Interaktion eines Zulieferers mit einem Herstellerunternehmen über Web Services. Der Hersteller kann durch Sicherheitsmechanismen, die in HTTP zur Verfügung stehen, sicherstellen, dass nur eingetragene und berechtigte Benutzer Daten über den Web Service abrufen können.Das weiter oben geschilderte Szenario mit mehreren beteiligten Parteien in einem lose gekoppelten Umfeld erfordert dann allerdings eine umfassendere und transportunabhängige Lösung.

Da es sich bei der heutigen Form von Web Services gewissermaß;en um Web-Anwendungen dreht, kann man auch bei Web Services auf die Sicherheitstechnologien rund um HTTP setzen. Warum das allerdings problematisch sein kann, soll erst am Ende dieses Artikels erläutert werden.

Die Aufgabe von SOAP als plattformübergreifender Standard zum Austausch von XML-Nachrichten besteht nicht in der Absicherung der Kommunikation auf welcher Ebene auch immer. SOAP verlässt sich zum momentanen Zeitpunkt fast ausschließ;lich auf die Sicherheits-Features der darunter liegenden Transportprotokolle.

So sollte man kritische Daten beispielsweise immer über eine mit SSL (Secure Sockets Layer) abgeschottete Verbindung schicken - SOAP bekommt davon allerdings nichts mit. Wenn man SOAP Sicherheit beibringen möchte, dann existiert über das Konzept der SOAP Header eine Möglichkeit, relevante Informationen für jede Nachricht in einem oder mehreren Headern unterzubringen.

Erweiterbares SOAP-Modell

Werfen wir also einen Blick auf eine eigens gestrickte Lösung auf Basis von SOAP Headern. Eine SOAP-Nachricht besteht aus einem oder mehreren optionalen SOAP Headern und einem SOAP Body als Pflichtteil. In einem SOAP Header werden normalerweise Zusatzinformationen für einen SOAP Request übertragen, die mit dem eigentlichen Inhalt der zu versendenden Daten nichts direkt zu tun haben. Prädestiniert hierfür sind z.B. Transaktions-IDs, Sitzungs-IDs oder aber eben Sicherheitsinformationen (z.B. für die Authentifizierung).

Microsoft hat zusammen mit IBM und VeriSign eine Spezifikation im Rahmen der Global XML Web Services Architecture (GXA) ins Leben gerufen, die genau auf diesem SOAP-Feature aufsetzt. Die als WS-Security bekannte Spezifikation sorgt dabei u.a. für die Übertragung von Lizenznachweisen (im Sinne eines Authentifizierungsnachweis) innerhalb von SOAP Headern.

Der SOAP Envelope in Listing 1 zeigt eine unvollständige Nachricht mit einer binären Lizenz im SOAP Header wssec:credentials.

Listing 1. Mögliche Annotation einer SOAP-Nachricht mit Authentifizierungsdaten in einem SOAP Header

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S=... xmlns:xsd=... xmlns:xsi=...>
   <S:Header>
      <wssec:credentials …>
         <wslic:binaryLicense …>MIIEBAgI...</wslic:binaryLicense>
      </wssec:credentials>
   </S:Header>
   <S:Body>
      <…>
   </S:Body>
</S:Envelope>

WS-Security wird zwar mittlerweile von allen groß;en Web-Services-Anbietern akzeptiert, allerdings ist diese Spezifikation und alle darauf aufsetzenden Erweiterungen noch weit von einem flächendeckenden Einsatz in Applikationen und Web Services-Architekturen entfernt.

Web-Sicherheit bei Web Services

WS-Security bietet eine Lösung für die Sicherheitsbereiche Integrität (Signatur einer Nachricht), Vertraulichkeit (Verschlüsselung einer Nachricht) und Lizenz (Authentifizierungs- und Berechtigungsnachweis).

Wir wollen uns allerdings im Rest dieses Artikels den Möglichkeiten der heute real nutzbaren HTTP-Sicherheit in Verbindung mit der Web Services-Technologie widmen. Derzeit wird HTTP fast ausschließ;lich als Transportprotokoll für SOAP verwendet und bietet schon seit vielen Jahren Konzepte für die sichere Kommunikation im Intranet oder Internet.

Eine typische SOAP-Nachricht sieht wie in Listing 2 dargestellt aus. Zusätzlich zum so genannten SOAP Envelope - also Ihrer in XML beschriebenen Daten, die übertragen werden sollen - müssen korrespondierend mit der Bindung zu einem Übertragungsprotokoll noch die protokollspezifischen Informationen mit überliefert werden.
Diese Informationen werden im Fall von HTTP in einem oder mehreren HTTP Headern festgelegt.

Listing 2. SOAP-Nachricht bestehend aus einer Anfrage (SOAP Request) und einer Antwort (SOAP Response)

POST /CCC/CC_CS.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/GetOrderDetails"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetOrderDetails xmlns="http://tempuri.org/" />
  </soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetOrderDetailsResponse xmlns="http://tempuri.org/">
      <GetOrderDetailsResult OrderId=7 CompanyName="eYesoft">
        <CustomerFirstName>Christian</CustomerFirstName>
        <CustomerLastName>Weyer</CustomerLastName>
        <email>cw at eyesoft.de</email>
        <OrderItemDetail>
          <OrderItem ItemName="CD-Rohlinge" ItemId=47 
ItemDescription="Sehr günstig" />
          <OrderItem ItemName="Druckerpapier" ItemId=11 
ItemDescription="Extra weiß" />
        </OrderItemDetail>
      </GetOrderDetailsResult>
    </GetOrderDetailsResponse>
  </soap:Body>
</soap:Envelope>

Wenn man nun eine der verfügbaren Authentifizierungsmethoden in Verbindung mit HTTP einsetzt, dann werden deren Daten in einem entsprechenden HTTP Header mitgeteilt und haben mit der im HTTP-Request transportierten SOAP-Nachricht nichts zu tun. HTTP-Sicherheit liegt im Protokoll-Stack unterhalb von SOAP.

Die Microsoft Internet Information Services (IIS) bieten drei unterschiedliche Authentifizierungsmechanismen an (siehe Tabelle 1). Standardmäß;ig wird ein Benutzer über eine anonyme Anmeldung im System mit dem Benutzerkonto IUSR_Rechnername bekannt gemacht (dieses Konto ist standardmäß;ig eingestellt, kann aber über die Verwaltungskonsole der IIS konfiguriert werden).

HTTP-Authentifizierungsmethoden	Beschreibung
Basic	Benutzername und -passwort werden im Klartext (als Base64-Wert) übertragen. HTTP-Standard
Digest	Benutzername und -passwort werden als Hash-Wert übertragen. HTTP-Standard
Windows-Integriert	Benutzerdaten werden als Hash-Wert übertragen. Windows-Standard (NTLM oder Kerberos)

Tabelle 1: HTTP-Authentifizierungsmethoden im IIS

Authentifizierungsvarianten

Die Variante Basic sorgt dafür, dass der Benutzer im Falle einer Browser-basierten Web-Anwendung den Benutzernamen und das Passwort in eine Dialogbox eingeben muss. Bei einer Web-Services-Client-Applikation müssen diese Informationen freilich entweder durch den Entwickler vorbelegt werden oder dem Benutzer wird eine ähnliche Möglichkeit geboten, sich am System anzumelden. Ein Beispiel hierfür finden Sie weiter unten im Abschnitt "Sicherheits-Features in ASP.NET".

Der groß;e Nachteil dieser Methode ist, dass die Benutzerdaten nicht verschlüsselt, sondern einfach nur in einer Base64-Repräsentation über die Leitung geschickt werden. Besonders hier ist also eine zusätzliche Verschlüsselung des Kommunikationskanals beispielsweise über SSL dringend anzuraten. Auch sie liegt im Protokoll-Stack unterhalb von SOAP und ist daher für Web Services auf HTTP transparent.

Die Digest-Authentifizierung ist der Basic-Version ähnlich. Nur werden hier die Benutzerdaten nicht im Klartext, sondern als MD5 Hash-Wert übertragen. Der Nachteil von Digest ist aber, dass man in einer Windows-Umgebung serverseitig einen Domäne-Controller dafür benötigt.

Weiterhin ist Digest eine Erweiterung von HTTP 1.1 - und nicht alle Browser auf allen Plattformen - geschweige denn alle SOAP-Implementierungen auf den verschiedenen Plattformen - unterstützen HTTP in diesem Maß;e. Digest-Authentifizierungsinformationen können allerdings über Proxy- und Firewall-Grenzen hinweg übertragen werden. Dieser Umstand ist sehr wichtig und stellt einen unschätzbaren Vorteil im Vergleich zur Windows-Integrierten Authentifizierung dar.

Die Windows-Integrierte Authentifizierung macht sich die in Windows eingebauten Mechanismen zur Anmeldung eines Benutzers zu Eigen. Dies hat zur Folge, dass auf einem Domänen-Controller mit installiertem Active Directory das Kerberos-Protokoll in der Version 5 verwendet wird (wenn die Client-Software dies unterstützt).

Auf allen anderen Systemen kommt das über viele Jahre hinweg eingesetzte und wohl bekannte NTLM-Protokoll (Windows NT LAN Manager) zum Einsatz. Bei Windows-Authentifizierung werden ebenfalls keine Klartextdaten, sondern ein Hash-Wert übermittelt. Ein groß;er Nachteil dieser Variante ist allerdings, dass es zurzeit nur von Windows- bzw. Microsoft-Produkten unterstützt werden und dass man es nicht über Proxys betreiben kann.

Sicherheit in ASP.NET

Wenn Sie nun die ASP.NET als Plattform zur Entwicklung von Web-Anwendungen und Web Services betrachten, zeigt sich, dass sich ASP.NET der in den IIS zur Verfügung stehenden Authentifizierungsmethoden bedienen kann. Man muss allerdings anmerken, dass ASP.NET nicht mehr so eng an die IIS gekoppelt ist wie seine Vorgänger.

ASP.NET lässt sich relativ einfach mit anderen Web Servern wie Apache zum Laufen bringen. Die Firma Covalent hat hierzu eine Lösung im Rahmen ihres Enterprise Application Servers im Angebot (http:/www.covalent.com/).

In ASP.NET stehen prinzipiell drei Varianten bereit (vgl. Tabelle 2). Bei der Windows-Variante bedient sich ASP.NET der Einstellungen in der IIS Metabase. Diese werden dann innerhalb von ASP.NET weiter verwendet, um den aktuell durch die IIS authentifizierten Benutzer auch in ASP.NET zu benutzen. Dabei ist es belanglos, ob eine anonyme, eine Basic, eine Digest oder eine Windows-Integrierte Authentifizierung konfiguriert wurde. Sie wird einfach von ASP.NET so übernommen.

Im Falle einer Forms-basierten Authentifizierung muss der Entwickler selbst Sorge tragen, dass die Benutzerdaten überprüft werden. Hierfür bietet ihm ASP.NET ein spezielles API im Namespace System.Web.Security an.

Über diverse Methoden und Eigenschaften der Klasse FormsAuthentication kann der Programmierer festlegen, wann und ob ein Benutzer authentifiziert wird. Der übliche Weg geht über die Bereitstellung von Benutzername und -passwort durch ein HTML-Formular. Dieses wird dann auf der ASP.NET-Seite ausgewertet. Bei einem Web Service sieht dies aber etwas anders aus (siehe weiter unten).

Die dritte Möglichkeit ist, den Microsoft-eigenen Passport-Dienst einzusetzen. Diese Möglichkeit soll hier verwendet werden, da die Zukunft von Passport sehr ungewiss ist und ein Einsatz von Passport in einer Web-Services-Landschaft momentan noch sehr viele Probleme bereitet.

Authentifizierungsmethoden in ASP.NET	Beschreibung
Windows	Benutzt die Informationen aus der IIS Metabase. Werden über die ISAPI DLL aspnet_isapi.dll weiter gegeben
Forms	Der Entwickler muss selbst bestimmen, wann und wie ein Benutzer authentifiziert wird
Passport	Single Sign On-Lösung von Microsoft für diverse Web Sites

Tabelle 2: Verfügbare Authentifizierungsmethoden in ASP.NET

Die Konfiguration der Authentifizierungs-Methode erfolgt dabei, wie es in .NET und v.a. in ASP.NET üblich ist, über eine XML-Datei. Sie als Programmierer oder Administrator können entweder systemweit in der machine.config oder aber anwendungsweit über die web.config festlegen, welche Variante ASP.NET verwenden soll.

Im Folgenden entsteht ein Beispiel-Web-Service, der von Client-Anwendungen aus angesprochen wird. Der Web Service ist sehr schlicht gehalten und gibt lediglich ein Gebilde von Klasseninstanzen an den Aufrufer zurück. Dieser Rückgabewert entspricht einer Bestellung von unterschiedlichen Artikeln (siehe Listing 4).

Der Code in Listing 3 zeigt den relevanten Teil einer web.config-Datei für die Authentifizierung. Wir wollen uns zunächst die Windows- Authentifizierung von ASP.NET in Verbindung mit den möglichen Einstellungen im IIS näher betrachten.

Listing 3. web.config für die Konfiguration von Windows- oder Forms-Authentifizierung in ASP.NET

<configuration>   
<system.web>
<authentication mode="Windows" />
<authorization>         
<deny users="?" />
</authorization>
</system.web>
</configuration>

In der gezeigten web.config ist die Windows-Authentifizierung aktiviert. Wenn der Modus (mode) auf Windows gesetzt ist, dann wird das Kindelement einfach ignoriert. Wenn wir nun in den IIS die Windows-Integrierte Authentifizierung aktivieren, dann können wir einen .NET-Client wie in Listing 5 gezeigt schreiben.

Der Abschnitt <authorization> gibt an, wer Zugriff auf diese Ressource - in unserem Fall also die Dateien innerhalb dieses Verzeichnisses - besitzt. Mit dem Element <deny> und der Angabe von ? bestimmen wir, dass allen nicht-authentifizierten (also anonymen) Benutzern der Zugriff verweigert wird.

Eine Client-Anwendung muss erst mit den Informationen über den jeweils zu authentifizierenden Benutzer versorgt werden. Hierbei gibt es zwei prinzipielle Methoden: Zum einen kann man explizit einen Benutzer spezifizieren. Zum anderen kann man der clientseitigen Web Services Proxy-Klasse die Daten des aktuell angemeldeten Windows-Benutzers zuweisen.

Das folgende Listing stellt den eingesetzten Web Service vor.

Listing 4. Web Service Code für die Rückgabe von Bestellinformationen

<%@ WebService language="C#" class="CC" %>
using System;
using System.Web.Services;
using System.Xml.Serialization;
using System.Web.Services.Protocols;
[WebService(Namespace="http://eyesoft.de/webservices/")]
public class CC
{
[WebMethod]
public OrderDetails GetOrderDetails()
{
OrderDetails orderDetails = new OrderDetails();
orderDetails.OrderNumber = 7;
orderDetails.CompanyName = "eYesoft";
orderDetails.CustomerFirstName = "Christian";
orderDetails.CustomerLastName = "Weyer";
orderDetails.CustomerEmail = "cw at eyesoft.de";
orderDetails.OrderItems = new OrderItem[2];
orderDetails.OrderItems[0] = new OrderItem();
orderDetails.OrderItems[1] = new OrderItem();
orderDetails.OrderItems[0].ItemName = "CD-Rohlinge";
orderDetails.OrderItems[0].ItemId = 47;
orderDetails.OrderItems[0].ItemDescription = 
"Überlänge";
orderDetails.OrderItems[1].ItemName = 
"Druckerpapier";
orderDetails.OrderItems[1].ItemId = 11;
orderDetails.OrderItems[1].ItemDescription = 
"Extra weiß";
return orderDetails;
}
}
public class OrderDetails
{
[XmlAttribute("OrderId")]
public int OrderNumber;           
[XmlAttribute()]
public string CompanyName;        
public string CustomerFirstName;
public string CustomerLastName;
[XmlElement("email")]
public string CustomerEmail;      
[XmlArray("OrderItemDetail")]
public OrderItem[] OrderItems;    
}
public class OrderItem
{
[XmlAttribute()]
public string ItemName;
[XmlAttribute()]
public int ItemId;
[XmlAttribute()]
public string ItemDescription;
}

Damit eine Client-Applikation nun den Web Service mit den notwendigen Informationen aufrufen kann, muss man die so genannten Credentials der Proxy-Klasse setzen. Credentials sind Authentifizierungsinformationen, die man einer Anfrage an den Web Service mitgeben muss.

Das Beispiel in Listing 5 zeigt wie man für eine standardmäß;ige .NET Web-Service-Proxy-Klasse (über "Webverweis hinzufügen" im Visual Studio .NET oder mit wsdl.exe erzeugt) diese Credentials setzen kann. In diesem Fall werden die DefaultCredentials übergeben; diese entsprechen den Informationen des gerade am System eingeloggten Windows-Benutzers. Dieser muss selbstredend Berechtigungen zum Lesen und Ausführen des Web Services auf dem jeweiligen Server besitzen. Diese Berechtigungen werden über die ACLs (Access Control Lists) des Dateisystems festgelegt (vgl. nachstehende Abbildung).

Listing 5. Client-Code (.NET) für ASP.NET Web Service mit Windows-Authentifizierung

using eYesoft.Web.Services.Clients;
public class CCClient
{
public static void Main()
{
CC myProxy = new CC();
myProxy.Credentials =
                 System.Net.CredentialCache.DefaultCredentials;
OrderDetails myOrder = myProxy.GetOrderDetails();
System.Console.WriteLine(myOrder.email);
}
}

Wenn wir nun die Zeile für die Übergabe der Credentials auskommentieren und die kompilierte Anwendung nochmals ausführen, dann präsentiert sich Ihnen folgende Fehlermeldung:

D:\Documents and Settings\Christian Weyer\My Documents>cc_client
Unhandled Exception: System.Net.WebException: The request failed 
with HTTP status 401: Access Denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse
   (SoapClientMessage message, WebResponse response,
 Stream responseStream)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke
(String methodName, Object[] parameters)
   at eYesoft.Web.Services.Clients.CC.GetOrderDetails()
   at CCClient.Main()

Somit hat der Schutz der Web Service Ressource Erfolg gehabt.
Den gleichen Code kann man übrigens auch verwenden, wenn man Basic Authentication in den IIS aktiviert hat. Nur muss man sich im Klaren sein, dass die Benutzerdaten dann nur als Base64-Wert über die Leitung gehen - und dieser ist sehr einfach ausspähbar. Für dieses Beispiel werden in der Client-Anwendung die Benutzerdaten explizit gesetzt. Dies geschieht durch folgende Zeile:

myProxy.Credentials = 
        new System.Net.NetworkCredential("Test", "MSDN");

Abbildung 2 zeigt einen Mitschnitt einer SOAP-Kommunikation mittels HTTP Basic Authentication. Der Benutzername ist "Test", das Passwort lautet "MSDN". Da auf dem Server diesem Benutzer keine Berechtigungen eingeräumt wurden, gibt der angesprochene IIS eine 401-Fehlermeldung zurück: Zugriff verweigert.

Abbildung 2: SOAP-Kommunikation in einem Tracing-Werkzeug bei aktivierter Basic-Authentifizierung

In einer SOAP und Web-Services-basierten Welt kommt es natürlich hauptsächlich auf die Interoperabilität an. Hierfür muss eine SOAP-Implementierung die jeweiligen Standards für HTTP-Authentifizierung unterstützen. Im Java-Umfeld beherrschen viele Toolkits HTTP Basic und HTTP Digest als Standards. Windows-Integrierte Sicherheit hingegen findet man ausschließ;lich in Microsoft-Produkten wieder.

Besonderheit .NET - formlose Vorstellung

Zum Abschluss dieses Überblicks über den Einsatz von HTTP- und ASP.NET Sicherheitsmechanismen in Verbindung mit XML Web Services wollen wir noch einen Blick auf die Forms-basierte Authentifizierung werfen.

Abbildung 3 zeigt den generellen Ablauf bei der Forms-Authentifizierung. Wenn der Benutzer auf dem Server authentifiziert wurde, dann wird ein Cookie auf dem Client geschrieben. Anhand dieses Ablaufdiagramms kann man auch schon die groß;e Schwäche dieser Variante sehen.

Sie verwendet ein Redirect, um den Benutzer auf eine Login-Seite umzulenken. Dies können wir in einer Web-Services-regierten Welt natürlich nicht machen.

Abbildung 3: Ablauf des Forms Authentication-Prozesses

Wir müssen deshalb innerhalb unseres Web Services eine ausgewiesene Login-Methode bereitstellen. In dieser überprüfen wir den Benutzer und setzen über den Aufruf der Methode SetAuthCookie (Klasse FormsAuthentication) den Cookie für eine erfolgreiche Authentifizierung.

Der Vollständigkeit halber sollten wir analog auch noch eine Möglichkeit zum Abmelden bieten. Dort wird über die Methode SignOut der gleichen Klasse dafür gesorgt, dass das Cookie auf dem Client entfernt wird und der Benutzer somit nicht mehr angemeldet ist (vgl. Listing 6).

Wichtig für das Funktionieren von Forms-Authentifizierung ist also die Unterstützung von Cookies. ASP.NET Web Services sind dazu in der Lage. Allerdings gibt es zahlreiche SOAP-Implementierungen für andere Plattformen, die keine Cookies verarbeiten können. Sogar das Microsoft-eigene SOAP Toolkit 3.0 für COM-Anwendungen bleibt hier auß;en vor.

Listing 6. Login- und Logout-Methoden des Web Services für die Forms-Authentifizierung

[WebMethod] 
public bool Login(string sUsername, string sPwd)
{
if (sUsername == "CW" && sPwd == "nichtWIRKLICH")
{
FormsAuthentication.SetAuthCookie(sUsername, true);
return true;
}
else
return false;
}
[WebMethod] 
public bool Logout()
{
if (Context.User.Identity.IsAuthenticated == true)
{
FormsAuthentication.SignOut();
return true;
}
else
throw new Exception("Sie sind nicht angemeldet.");
}

Dadurch muss aber jetzt in jeder Web-Service-Methode überprüft werden, ob es sich um einen authentifizierten Aufruf handelt: Nur wenn if (Context.User.Identity.IsAuthenticated == true) gilt, kann man mit der Datenverarbeitung fortfahren.

Der zugehörige Code für die Client-Anwendung hält noch eine Besonderheit parat. Wie Sie in Listing 7 sehen, müssen wir hier noch darauf achten, dass das gesetzte Cookie auch von der Web-Service-Proxy-Klasse beachtet und verarbeitet wird. Damit dies der Fall ist, müssen wir einen CookieContainer anlegen und der Proxy-Klasse bekannt machen. Dieser kümmert sich dann um die Verwaltung des Forms-Cookies.

Listing 7. Client-Code für einen über Forms-Authentifizierung abgesicherten Web Service

using eYesoft.Web.Services.Clients;
using System.Net;
public class CCClient
{
public static void Main()
{
CC myProxy = new CC();
myProxy.CookieContainer = new CookieContainer();
myProxy.Login("CW", "nichtWIRKLICH");
OrderDetails myOrder = myProxy.GetOrderDetails();
System.Console.WriteLine(myOrder.email);
myProxy.Logout();
}
}

Zum Schluss müssen wir noch die zugehörige web.config -Datei zeigen. Die Umleitung ist hier nicht existent, denn wir verweisen in der web.config auf die ursprüngliche Web Service-Datei.

Listing 8. web.config-Datei für Forms-Authentifizierung in einem Web Service

<configuration>   
<system.web>
<authentication mode="Forms">         
<forms name=".WSDemo" 
                           loginUrl="CC_CS.asmx" 
                           protection="All" 
                           timeout="60" path="/" />
</authentication>
<authorization>         
<deny users="?" />
</authorization>
</system.web>
</configuration>

Zusammenfassung

Sicherlich sind die HTTP-basierten Sicherheitsmechanismen nicht der Weisheit letzter Schluss. Dies gilt vor allem, wenn man an anwendungsspezifische Sicherheitsanforderungen denkt. HTTP ist ja nur das Basisprotokoll und kann daher diesen Service nicht bieten. Vor allem der Einsatz von Forms-Authentifizierung sollte im Umfeld von XML Web Services mit Vorsicht genossen werden, da sie sich auf die Unterstützung von Cookies beruft.

Es wird noch einige Zeit vergehen bis die umfangreichen Spezifikationen aus dem GXA Framework und anderen Standardisierungsgremien Früchte tragen werden. So lange kann man sich aber die vorhandene Infrastruktur zu eigen machen und durch sichere Web Services der eigenen Architektur zum Erfolg verhelfen.