Web Services: Implementierung der Business-Logik

Sicherheit ist wahrscheinlich das heute am heißesten diskutierte IT-Thema, besonders angesichts der aktuellen Würmer, die Lücken im RPC-Protokoll ausnutzen. Beim Umgang mit Web Services liegen die Verantwortlichkeiten des Entwicklers in Sachen Sicherheit aber anderswo. Es gibt zwei Hauptaspekte bei der Sicherheit von Anwendungen: Autorisierung/Authentifizierung und Datenübertragung. Im Wesentlichen geht es darum, Unbefugte außen vor zu halten und zu verhindern, dass Daten während der Übertragung abgefangen werden.

ASP.NET bietet eine Reihe unterschiedlicher Methoden zur Abwicklung des Authentifizierungsaspekts der Sicherheit. Sicherheitsanforderungen in Bezug auf die Datenübertragung können durch den Aufruf von Web Services über SSL erfüllt werden. Die gleichzeitige Implementierung dieser beiden Sicherheitsmaßnahmen sorgt für eine sehr sichere Umgebung. Bei dem Beispiel hier wird wegen der Komplexität der Installation und Konfiguration sowie der damit verbundenen Kosten auf den SSL-Teil verzichtet. Man kann allerdings Testzertifikate für den eigenen Server herunterladen, wenn man seine Web Services über SSL testen will.

Um Johns Web Services abzusichern, soll hier ein eigener SOAP-Header implementiert werden, bei dem es sich im Wesentlichen um die Definition einer privaten Klasse mit einigen öffentlichen Eigenschaften handelt, die beim Aufruf einer Web-Methode mit in den SOAP-Envelope gepackt werden. Durch die Definition von Eigenschaften dieser SOAP-Header-Klasse kann man Eigenschaften einrichten, durch die der Web Service feststellen kann, ob der Benutzer tatsächlich zum Zugriff auf die Anwendung autorisiert ist.

Die zweite zu implementierende Schutzmaßnahme besteht darin, bestimmte Protokolle abzublocken, so dass nicht auf unerwünschte Weise auf den Web Service zugegriffen werden kann. Abbildung A zeigt die Protokoll-Richtlinien für Johns Anwendung.

Durch das Entfernen der Protokolle HttpPost, HttpGet und Documentation verhindert man das Aufrufen des Web Services über Post und Get und unterbindet gleichzeitig die Fähigkeit zur Erstellung von WSDL-Dokumenten, die es unautorisierten Benutzern ermöglichen könnten, Web-Referenzen und Proxy-Klassen für die Web Services zu erstellen.

Durch den gleichzeitigen Einsatz beider Sicherheitsmaßnahmen wird Folgendes erreicht:

• Das Entdecken und Aufrufen des Web Service kann ausschließlich über HttpSoap geschehen, was im Wesentlichen bedeutet, dass die Benutzer des Web Service über eine gültige Proxy-Klasse verfügen müssen, bevor der Web Service abgeschlossen wird (Lockdown). Damit kann nur der Entwickler Zugriff auf den Web Service gewähren.
• Falls ein Benutzer doch auf irgendeine Weise auf den Web Service stoßen sollte, ist er nicht in der Lage die WSDL-Datei für den Service zu erzeugen, da das Documentation-Protokoll entfernt wurde.
• Falls ein unautorisierter Benutzer es schaffen sollte, auf irgendeine Weise an eine Proxy-Klasse oder WSDL-Datei zu gelangen, würde er die Authentifizierungs-Überprüfung nicht bestehen, da er über keine gültigen ClientIds oder WSTokens verfügt, die im selbstgenerierten SOAP-Header vorhanden sein müssen.

Damit gibt es einen beinahe unüberwindbaren Sicherheitsmechanismus. Ein unautorisierter Benutzer müsste drei solide Schutzschichten durchdringen, ehe er in der Lage wäre, die Anwendung zu kompromittieren. Wenn dann noch SSL hinzukommt, wird der Grad an Sicherheit sogar noch weiter erhöht.