Web Service Toolkit für PHP5
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006 1
Web Service Toolkit für PHP5
Stefan Marr, Falko Menge, Gregor Gabrysiak, Martin Sprengel, Michael Perscheid,
Christoph Hartmann, Andreas Meyer und Sebastian Böttner
Hasso-Plattner-Institut für Softwaresystemtechnik
Zusammenfassung— Dieses Paper beschreibt die Ergebnisse dukte verwendet, die via Web Service in die Anwendungen
unserer Arbeit an einer Sammlung von Werkzeugen für die integriert werden.
automatisierte Erstellung von Web Services unter PHP5. Die In unserer ersten Ausarbeitung „Einführung in XML Web
besonderen Eigenschaften der Sprache machen die Entwicklung
von Meta-Spach-Werkzeugen etwas schwierig. Daher wurde die Services“ [4] haben wir SOAP, WSDL und UDDI vorgestellt
Reflection API von PHP5 erweitert, um die benötigten Infor- und gezeigt, wie man die Standards mit PHP5 nutzen kann.
mationen über Sprachkonstrukte zu erhalten und Annotationen PHP5 bietet eine Implementierung des SOAP-Protokolls, die
in PHP5 zu ermöglichen. Auf dieser Basis wurden zunächst sich nutzen lässt, um interoperable SOAP-Server und -Clients
ein leistungsfähiger WSDL-Generator und ein spezieller Code- zu entwickeln.
Generator entwickelt. Um eine sichere Authentifizierung für
Nutzer von Web Services zu ermöglichen wurde das Username- Um eine Klasse in PHP5 als Web Service anzubieten,
Token-Profile aus dem WS-Security-Standard für PHP5 imple- erstellt man zunächst eine Beschreibung der Schnittstelle mit
mentiert. Dazu wurde der SOAP-Server um einen Handler- WSDL. Dabei definiert man unter anderem für alle Datentypen
Chain-Mechanismus für SOAP-Intermediaries erweitert. Zusätz- mit Hilfe von XML Schema-Ausdrücken, wie sie für das
lich zu den Werkzeugen für SOAP-basierte Web Services ent-
Versenden in SOAP-Nachrichten serialisiert werden sollen.
stand eine Reihe von Werkzeugen zur Entwicklung von RESTful
Web Services mit PHP5. Ein Administrationstool stellt eine ein- Eine Dokumentation der Methodensemantik kann manuell aus
heitliche grafische Oberfläche für alle Werkzeuge zur Verfügung, dem Quelltext der Klasse in die Schnittstellen-Beschreibung
um automatisiert SOAP- und REST-Server für eine bestehende übertragen werden. Danach schreibt man ein PHP Script, das
Anwendung zu generieren, wodurch eine plattformübergreifende mit Hilfe der WSDL-Beschreibung einen SOAP Server startet.
Kommunikation mit anderen Anwendungen möglich wird.
Dieser erzeugt dann ein Exemplar der dazugehörigen Klasse
Stichworte— PHP5, Reflection, Annotations, Web Services, und beginnt SOAP-Anfragen zu beantworten.
WSDL-Generator, SOAP-Handler-Chains, WS-Security, Das ist natürlich bei weitem nicht so komfortabel, wie man
Username-Token-Profile, REST.
es von .NET oder der Java Enterprise Edition gewohnt ist.
Die SOAP-Implementierung ist zwar sehr einfach zu benutzen,
I. E INFÜHRUNG jedoch ist die manuelle Erstellung von WSDL-Beschreibungen
sehr aufwändig und könnte prinzipiell automatisiert werden.
EB SERVICES sind eines der wichtigsten IT-Themen
W der letzten Jahre. Sie bieten interoperable Kommunika-
tion über Plattform- und Programmiersprachengrenzen hinweg
Um also professionell in großen Systemen Web Services an-
zubieten, benötigt man umfangreiche Werkzeugunterstützung.
Typischerweise verwendet man in anderen Programmierspra-
und stellen aus diesem Grund für Unternehmen ein vielver- chen Annotationsmechanismen um Klassen und Methoden ei-
sprechendes Konzept dar, um bestehende interne und unter- ner Anwendung zu markieren, die als Web Service verwendet
nehmensübergreifende Anwendungen sinnvoll zu integrieren werden sollen. Mit dem so markierten Quelltext wird eine
und so Geschäftsprozesse zu optimieren. Das Grundprinzip Werkzeugkette angestoßen, die dann WSDL-Beschreibungen,
dabei ist, dass Anwendungen ihre Funktionalität in Form zusätzlichen Code für Stubs und Skeletons und falls nötig
von Diensten anbieten, die über das Internet von anderen Deployment-Deskriptoren generiert. Damit sind die Web Ser-
Anwendungen genutzt werden können. vices sofort bereit für den Produktiveinsatz.
Die wichtigsten Grundlagenstandards für Web Services sind Das Ziel unserer Arbeit war es, diese Lücken in der Werk-
das SOAP-Protokoll [1], die Web Services Description Lan- zeugunterstützung für PHP5 zu schließen. Im Folgenden wer-
guage (WSDL) [2] und Universal Description, Discovery and den zunächst die entwickelten Werkzeuge einzeln vorgestellt.
Integration (UDDI) [3]. SOAP ist dabei das Kommunika- Dabei wird besonders auf die Architektur und die getroffenen
tionsprotokoll für den Zugriff auf die Dienste. Mit WSDL Design-Entscheidungen, die zu der jeweiligen Lösung geführt
werden vertragsähnliche Beschreibungsdokumente erstellt, die haben, eingegangen. Danach wird in einer umfangreichen
ein Anbieter den Nutzern zur Verfügung stellen kann. UDDI Beispielanwendung gezeigt, wie die Werkzeuge zusammen
ist der Standard für Namensdienste, mit denen Web Services eingesetzt werden können, um eine Anwendung mit Web
bekannt gemacht und gesucht werden können. Service Schnittstellen auszustatten.
Zur effektiven und interoperablen Nutzung von SOAP und,
mit Abstrichen, von WSDL existieren für alle üblichen Pro-
II. E XTENDED R EFLECTION API
grammiersprachen und Plattformen voll ausgereifte Werkzeu-
ge, die für den Produktionsbetrieb eingesetzt werden können. Zunächst besteht das Problem, an Informationen zu ge-
Für UDDI Namensdienste werden meist kommerzielle Pro- langen, die in einer Programmiersprache formuliert sind.2 SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006
ReflectionProperty ReflecionClass ReflecionMethod ReflecionParameter
Diese Informationen beschreiben die Funktionalität und den
Ablauf eines beliebigen Programms sowie die Schnittstellen ExtReflectionProperty ExtReflecionClass ExtReflecionMethod ExtReflecionParameter
von Komponenten. In vielen Sprachumgebungen gibt es zu
diesem Zweck sogenannte Reflection APIs, welche es mit der ClassType
Programmiersprache selbst ermöglichen, an die gewünschten
«interface»
Metainformationen zu gelangen. Type
Die in PHP5 integrierte Reflection API bietet die grund-
AbstractType
legenden Möglichkeiten, um zur Laufzeit Informationen zur ExtendedReflectionApi
Struktur der verfügbaren programmiersprachlichen Konstruk- PrimitiveType ArrayType +getTypeByName(in type : string) : Type
te, insbesondere der verfügbaren Klassen, Erweiterungen und
Funktionen, zu erhalten. Darüber hinaus bietet sie ebenso Abb. 2. UML-Darstellung der erweiterten Reflection API
die Möglichkeit auf Exemplare dieser Konstrukte zuzugreifen,
um den aktuellen Zustand zur Laufzeit zu ermitteln oder zu
modifizieren. Konstrukts, die gewünschten Typinformationen zu gewinnen.
Dieses Typensystem erlaubt zusätzlich vielfältige eigene Er-
«interface»
Reflector
weiterungen. Durch die Verwendung einer TypeFactory ist
es möglich für verschiedene Anwendungsaspekte angepasste
Typenklassen zu entwickeln, die weitere Zusatzinformationen
ReflectionProperty ReflecionClass ReflecionFunction ReflecionParameter
zur Verfügung stellen. Aktuell implementiert ist unter anderem
ReflecionObject ReflecionMethod die Möglichkeit, direkt aus den Typen ihre Definition in XML
Schema zu erhalten. Das ist hilfreich beim Erstellen von
Abb. 1. UML-Darstellung der PHP5 Reflection API XML Schema Beschreibungen für Anwendungen, die PHP-
Datenstrukturen nach XML serialisieren.
In Abb. 1 ist die grobe Struktur der API dargestellt, welche Eine weitere wesentliche Erweiterung ist die Implemen-
einem Metamodel für die Definition einer Klasse im Sinne der tierung eines Annotation-Mechanismus, welcher in PHP bis
objektorientierten Programmierung entspricht. Da PHP5 selbst dahin nicht verfügbar war, sich jedoch in anderen gängigen
eine schwach typisierte und teils sogar dynamische Sprache ist, Programmiersprachen zunehmender Beliebtheit erfreut. Für
bietet die API nur sehr wenige Informationen zur Typisierung dieses Projekt steht die statische Verwendung von Zusatzinfor-
der einzelnen Sprachkonstrukte an. Um jedoch nicht nur zur mationen im Vordergrund. So ist es möglich die programmier-
Laufzeit Informationen über die Typisierung erhalten zu kön- sprachlichen Konstrukte mit zusätzlichen Eigenschaften zu
nen, wurde es erforderlich, die vorhandene API zu erweitern. versehen, unter anderem die Kennzeichnung als Web Service.
Ziel dieser Erweiterung ist es zusätzliche Informationen in Zusätzlich denkbar wäre es, diesen Annotation-Mechanismus
der Quelltext-Dokumentation der Sprachkonstrukte nutzen zu durch eine geeignete Laufzeitumgebung zu nutzen, um aspekt-
können. Dabei wurde auf PHPDoc, die in der PHP-Welt orientierte Programmierung unterstützen zu können. Dies ist
genutzte Variation des JavaDoc-Standards, gesetzt. Ursprüng- in diesem Projekt jedoch nicht realisiert.
lich sind diese Informationen dazu gedacht, die arbeitsteilige
Entwicklung zu unterstützen, in dem der Quellcode durch III. WSDL G ENERATOR
zusätzliche semantische Informationen angereichert wird. Nachdem die Extended Reflection API das Problem ge-
Da die PHPDoc-Tags sich in der PHP-Welt als Standard löst hatte, Typinformationen für PHP5 Sprachkonstrukte zu
durchgesetzt haben und in vielen bestehenden Projekten von ermitteln, konnten wir nun einen WSDL-Generator für die
diesen Gebrauch gemacht wird, bieten sie eine gute Basis Erstellung von Web Services entwickeln. Die Web Service
um die nötigen Informationen aus den Quelltext-Kommentaren Description Language (WSDL), welche in [4] näher erläutert
zu extrahieren, ohne neue Verfahren einzuführen, die in be- wird, verwendet man um die Schnittstellen der Dienste zu
stehenden Anwendungen weitgehende Anpassungen erfordern beschreiben. Anbieter von Web Services können ihren Nut-
würden. zern WSDL-Dokumente zur Verfügung stellen, aus denen sie
Die erweiterte Reflection API nutzt zur Gewinnung der erfahren, welche Operationen angeboten werden und welche
Typinformationen einen einfachen PHPDoc-Parser, welcher Elemente in den SOAP-Nachrichten enthalten sein müssen
die Quellcode-Kommentare untersucht und interpretiert. Um um sie zu nutzen. Die WSDL-Beschreibung ist dann eine
diese Informationen geeignet nutzen zu können, wurde eine Art Vertrag zwischen den Kommunikationspartnern, an den
programmiersprachliche Repräsentation für ein einfaches Ty- sich beide halten müssen um erfolgreich Nachrichten auszu-
pensystem entworfen. tauschen. Der von uns entwickelte WSDL-Generator erzeugt
In Abb. 2 ist das zentrale Interface Type dargestellt. WSDL-Dokumente gemäß dem WSDL 1.1 Standard [2].
Dieses wird im wesentlichen von drei Klassen implementiert. Bereits bei der Konzeption eines Web Services gibt es
PrimitiveType repräsentiert die einfachen Datentypen wie zwei grundlegende Entscheidungen zu treffen: die Art des
Integer, Float und String, ArrayType alle möglichen Methodenaufrufs und die Art der Datenrepräsentation in XML.
Array-Typen und ClassType alle Klassen. Damit ist es Zuerst widmen wir uns den Aufrufsmodi.
möglich aus einem programmiersprachlichen Konstrukt, nicht Ein Web Service kann durch zwei verschiedene Arten
nur zu dessen Laufzeit, sondern auch ohne ein Exemplar des angestoßen werden - entweder über einen „Remote-Procedure-WEB SERVICE TOOLKIT FÜR PHP5 3 Call“ (RPC) oder auf Basis des „Document“-Stils (DOC). Bei wird generell nicht mehr empfohlen. Daher wurde bei der RPC wird versucht, durch die Methode und deren Parameter Entwicklung des WSDL-Generators der Fokus in erster Linie einen Methodenaufrufsstack direkt beim Server nachzuahmen. auf die Kodierungsart Literal gesetzt. Trotzdem ist er in Die so aufgebaute Struktur, die diesen Stack repräsentiert, wird der Lage, neben den WS-I-konformen Varianten auch das dann zur Kommunikation genutzt. Der Client nimmt den Web dennoch gebräuchliche RPC/Encoded durch die Erzeugung Service als einzelne, logische Komponente mit gekapselten entsprechender WSDL-Dateien zu unterstützen. Objekten wahr. Die Komplexität wird also durch den SOAP Abb. 3 zeigt die Schnittstelle über die der WSDL-Generator RPC Stack verborgen. genutzt werden kann. Der Generator selbst wird initialisiert Bei der DOC-Variante hingegen wird der Methodenaufruf mit der Angabe des Namens für den zu erstellenden Service, direkt auf ein XML Dokument abgebildet, das dann über dem URI über den der Service erreichbar sein soll, dem SOAP versendet wird. Der gesamte Nachrichtenaustausch zwi- Namespace für die WSDL-Beschreibung und der gewünsch- schen Client und Web Service ist hier durch die zugrunde lie- ten SOAP-Bindung. Standardmäßig wird vom Generator die gende XML Schema Beschreibung bereits vorgegeben. Da die „Document/Literal-Wrapped“-Bindung erzeugt. Nachricht die Art und Reihenfolge der Kommunikation bereits vorgibt, muss diese demzufolge nur benannt werden um die Parameterliste direkt übergeben zu können. Dadurch entsteht bei der Kommunikation viel weniger Traffic, als es bei RPC der Fall ist. Während nämlich die Methodenaufrufe durch den Aufbau des Stacks erheblich mehr Overhead erzeugen, muss man bei DOC nur die Nachricht aus dem Schema identifizieren und kann die (benannten) Parameter direkt übergeben. Eine genauere Darstellung der Auswirkungen der verschiedenen SOAP Varianten auf die Performance ist unter [6] zu finden. Des Weiteren gibt es noch zwei verschiedene Kodierungs- möglichkeiten, um die Übergabewerte beim Sender zu seriali- sieren und beim Empfänger wieder zu rekonstruieren. Bei der ersten Variante wird eine spezielle Kodierung verwendet. Die einzige gebräuchliche Kodierung ist das im SOAP-Standard Abb. 3. Klassendiagramm des WSDL-Generators [1] spezifizierte SOAP-Encoding. Diese schreibt vor, wie man alle Typen der jeweiligen Programmiersprache, auf die vom Der Entwickler kann dann entweder per setClass() eine Standard definierten Typen von XML-Elementen abbildet. Klasse, deren Funktionalität angeboten werden soll, einlesen Wenn die Nachricht dann also versendet werden soll, müssen lassen oder per addFunction() eine beliebige Menge Client und Web Service dafür sorgen, diese Abbildungen zu von Methoden zur Erbringung dieser Funktionalität nutzen. nutzen. Die zweite Kodierungsart ist die „Literal“-Variante. Es ist jedoch nicht möglich, diese beiden Methoden der Hierbei wird für die Nachrichten keine spezielle Kodierung Erstellung zu mischen, da sie sich gegenseitig ausschließen. verwendet sondern reines XML, welches über XML Schema Ab diesem Punkt wird die Extended Reflection API aktiv. zu definieren ist. Der Nachteil hierbei ist, dass alle Daten- Sie liefert nicht nur die Methodennamen, sondern Listen konstrukte explizit durch eigene Schemas beschrieben werden von ExtReflectionMethod-Objekten, an denen direkt müssen. Informationen zu Parametern und Rückgabewerten abgefra- Diese zwei mal zwei Möglichkeiten lassen sich nun kom- gen werden können. Dies ist ein großer Vorteile für den binieren und so ergeben sich theoretisch vier Varianten, einen WSDLGenerator, da er so nicht selbst die Klassen parsen Web Service zu erstellen: muss, um die benötigten Informationen zu erhalten. • RPC/Encoded Alle so gefundenen Methoden bzw. jede hinzugefügte • RPC/Literal Funktion muss in die WSDL-Datei abgebildet werden. Soll- • Document/Encoded ten bestimmte Methoden nicht veröffentlicht werden, so • Document/Literal kann das Policy-PlugIn, das im Abschnitt VII-B vorgestellt Document/Encoded wird jedoch nicht genutzt, da es sich wird, genutzt werden. Es erhält als Eingabe die Liste der schon in seiner Konzeption selbst widerspricht. Die Frage ExtReflectionMethod-Objekte und liefert eine gefilterte bleibt also: welche Kombination ist zu bevorzugen? Die Ant- Liste zurück. Die Information, ob eine Methode veröffentlicht wort liefert die Web Services Interoperability Organization werden soll oder nicht, findet es in der angeschlossenen Da- (WS-I), ein Industriekonsortium, das sich mit der plattform- tenbank, die der Entwickler zuvor mit Hilfe des AdminTools übergreifenden Kommunikation zwischen Web Services be- für die entsprechende Klasse füllen muss. Im AdminTool kann schäftigt. Web Services, welche die Anforderungen in den WS- außerdem eine Beschreibung der Methode in die Datenbank I Profilen erfüllen, können interoperabel über Plattform- und eingepflegt werden, die dann automatisch, sofern das Policy- Programmiersprachengrenzen hinweg kommunizieren. Das ist PlugIn genutzt wird, mit in der WSDL-Datei ausgegeben wird. nur mit solchen Web Services möglich, die auf den Kom- Der schwierigste Teil der Abbildung von Methoden auf die binationen RPC/Literal oder Document/Literal aufbauen. Die WSDL-Beschreibung ist die korrekte Definition der Kodierung Verwendung des SOAP-Encodings oder anderen Kodierungen von komplexen Datentypen, da diese auch auf Clientseite er-
4 SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006
zeugt und verarbeitet werden müssen. Um das zu ermöglichen reguläre Methode und ist in bereits bestehenden Systemen
ist der WSDL-Generator in der Lage, rekursiv XML-Schemas völlig undenkbar. Zudem müssten die PHPDoc-Kommentare,
zu erstellen, die alle gebräuchlichen Datentypen abdecken. um eine WSDL-Generierung zu ermöglichen, die tatsächlichen
Per Extended Reflection API werden so z.B. Klassen als Typen für Argumente und Rückgabewert verleugnen.
solche erkannt. Damit ist der Generator in der Lage, die In manchen Klassen findet man beispielsweise folgende
Klassestruktur rekursiv zu analysieren und das XML Schema Konstruktionen um das Problem zu umgehen:
sukzessive zu ergänzen, sollten in einer Klasse selbst neue, public function echoString($inputString) {
komplexe Datentypen als Attribute enthalten sein. if (isset($inputString->inputString)) {
Damit dabei kein redundanter Code erzeugt wird, vermerkt return array(
’echoStringResult’
der Generator die Namen der erzeugten Typen in einer Liste => $inputString->inputString
und greift während der Verarbeitung auch auf diese zu. );
Der Generator erzeugt ein DOM-Dokument, das die WSDL- } else {
Struktur enthält. Der Aufbau dieser Struktur beginnt mit dem return $inputString;
Definition-Element, in dem alle verwendeten Namespaces }
}
definiert werden und das alle anderen Beschreibungselemente
enthält. Dann folgt die Types-Sektion, die XML Schema Die Fallunterscheidung macht die Methode wieder in ihrem
Beschreibungen für alle komplexen Datentypen enthält und, gewohnten Kontext verwendbar, ist aber nur eine partielle
bei Verwendung einer Literal-Kombination, außerdem die Lösung des Problems, da dies nur für Methoden mit ei-
Anfrage- und Antwortnachrichten definiert. Eine Liste der nem einzigen Parameter funktioniert. Allgemein lässt sich
Methoden ist indirekt durch den Message-Teil gegeben, bei das Problem lösen, indem man eine Adapter-Klasse einsetzt,
dem für jede Methode ein Element für die Anfrage und ein die Methoden mit den gleichen Namen anbietet, und diese
Element für die entsprechende Antwort vorhanden ist. Darauf anstelle der Original-Klasse beim SOAP-Server registriert.
folgt die PortType-Abteilung, in der die Methoden auf Die Methoden der Adapter-Klasse rufen die Methode an der
Operationen abgebildet werden. Anschließend wird die Kom- Original-Klasse mit den Argumenten aus dem vom SOAP-
bination aus Aufruf und Kodierung explizit in der Binding- Server übergebenen Objekt. Der jeweilige Rückgabewert wird
Sektion angegeben und abschließend folgt das Service- in ein Array verpackt bevor er zur Serialisierung an den SOAP-
Element, bei dem der Service an einen Port gebunden wird. Server zurückgegeben wird.
Auf die erzeugte Struktur kann der Anwender Eine einfache Beispielklasse könnte so aussehen:
dann mit den Methoden getString() oder /**
getDOMDocument() zugreifen, bzw. sie mit * @webservice
saveToFile(filename) in das Dateisystem */
speichern. Zusätzlich gibt es die Möglichkeit durch class Adder {
saveToFileAndStartSOAPServer(filename) /**
* @webmethod
direkt einen SOAP-Server zu starten um den Web Service
* @param integer $a
sofort zu testen. * @param integer $b
* @return integer
*/
IV. D OCUMENT /W RAPPED -A DAPTER -G ENERATOR public function add($a, $b) {
return $a + $b;
Um entfernte Funktionsaufrufe über Web Services mit einer }
Document/Literal SOAP-Bindung realisieren zu können, wird }
typischerweise ein Mechanismus verwendet, der auch als Do-
cument/Wrapped Bindung bezeichnet wird. Dabei sind in den Für diese Klasse könnte dann ein möglicher Adapter folgen-
dermaßen implementiert werden:
SOAP-Nachrichten die serialisierten Argumente und Rückga-
bewerte einer Operation in einem zusätzlichen XML-Element class AdderDocumentWrappedAdapter {
verpackt, so dass im Body der SOAP-Nachricht immer nur
/**
ein einzelnes XML-Element mit einem oder mehreren Kind-
* @var Adder
Elementen vorkommt. Die SOAP-Implementierung von PHP5 */
wurde entwickelt um alle Arten der SOAP-Bindung zu un- private $target;
terstützen. Diese generische Auslegung führt allerdings dazu,
dass das Wrapping und Unwrapping bei Document/Wrapped /**
Web Services nicht automatisch vom SOAP-Server vorge- * @param Adder $target
*/
nommen wird, sondern durch die gerufene Methode oder public function __construct($target = null) {
Funktion ausgeführt werden muss. Auf der einen Seite bie- if (empty($target)) {
tet dieses Vorgehen für Anwendungen einige Freiheiten in $this->target = new Adder();
der Verwendung von SOAP. Andererseits erfordert es, die } else {
$this->target = $target;
Signaturen der Methoden oder Funktionen anzupassen, um }
eine Document/Wrapped Bindung zu nutzen. Eine solche }
Anpassung verhindert allerdings die parallele Nutzung alsWEB SERVICE TOOLKIT FÜR PHP5 5
/** Für einige dieser Sicherheitsanforderungen existieren bereits
* @param object $args Lösungen, die auch mit PHP genutzt werden können. Die
* @return array Integrität der Daten wird bereits sichergestellt durch den Ein-
*/ satz des TCP-Protokolls zur Datenübertragung. Vertraulichkeit
public function add($args) {
return array( kann realisiert werden, indem eine SSL-Verschlüsselung zum
’addResult’ => Beispiel in Form des HTTPS-Protokolls genutzt wird. Grund-
$this->target->add($args->a, $args->b) voraussetzung für eine Autorisation ist ein authentifizierter
); Benutzer. Die Authentifizierung von Benutzern ist der Aspekt
}
} mit dem sich Web Services Security (WSS) beschäftigt.
Autorisation hingegen ist immer anwendungsspezifisch und
Die Adapter-Klasse sorgt transparent für das Unwrapping von kann daher nicht durch Standards abgedeckt werden. Die
Argumenten und das Wrapping von Rückgabewerten. Die entscheidende Komponente, die für sichere Web Services mit
Original-Klasse muss dazu in keiner Weise angepasst werden. PHP5 noch fehlte, war also eine Implementierung des WS-
Ein solcher Adapter enthält keine anwendungsspezifische Security-Standards.
Geschäftslogik und kann daher automatisch generiert werden. Für die Umsetzung von Sicherheitsaspekten für Web Ser-
Auf Basis unserer Extended Reflection API haben wir einen vices gilt es einige Designziele einzuhalten. Hierzu zählt
entsprechenden Code-Generator entwickelt. Abb. 4 zeigt die vor allem, dass die Benutzung von Sicherheitsmechanismen
Schnittstelle, über die das Werkzeug genutzt werden kann. nicht zu Lasten des Anwendungsentwicklers gehen darf. Eine
Sicherheits-Implementierung sollte daher nur eine Erweiterung
zur Geschäftslogik sein, die bei Bedarf ausgetauscht werden
kann. Ein weiteres wichtiges Ziel ist Interoperabilität, denn
Web Services dienen zur plattformübergreifenden Kommuni-
kation. Die Sicherheitsmechanismen müssen also beispielswei-
se problemlos mit .NET oder Java genutzt werden können.
B. Mögliche Ansätze zur Absicherung von Web Services
Ein grober Ablauf für eine mögliche Lösung könnte folgen-
dermaßen aussehen:
1) Anmelden, sowie Verschlüsseln der Anmeldedaten auf
Seite des Clients
Abb. 4. Klassendiagramm des Document/Wrapped-Adapter-Generators 2) Die Anmeldedaten auf Serverseite abfragen und auswer-
ten
Zusätzlich zu der Generierung von WSDL-Beschreibungen 3) Nach der korrekten Authentifizierung wird die Anfrage
wird somit auch dieser Schritt für die Erstellung von Web an die Web Service Implementierung weitergeleitet
Services mit PHP5 automatisiert. Lösungen eines selbst implementierten Token-Prinzips sind
immer möglich, stehen jedoch im Kontrast zu einer geforder-
V. WS-S ECURITY ten Interoperabilität. Demnach muss ein Standard gefunden
Nicht immer möchte man seine Web Services jedem frei werden, welcher genau diese Anforderungen erfüllen kann. In
verfügbar machen. Möglicherweise möchte man kostenpflich- der Welt von Java und .NET hat dabei Web Services Securi-
tige Dienste anbieten oder sie nur unternehmensintern bzw. ty1 von OASIS [7] eine weite Verbreitung gefunden. Dieser
mit ausgewählten Geschäftspartnern nutzen. Dabei werden die Standard umfasst mehrere Teile. Das ist zum einen SOAP
Grenzen der Grundlagenstandards SOAP, WSDL und UDDI Message Security zum Verschlüsseln von Nachrichten und zur
schnell erreicht. Dies bedeutet nicht, dass keine möglichen Behandlung von Fehlern. Zum anderen gibt es verschiedene
Lösungen existieren. Doch wenn keine einheitlichen Standards Token Profiles, welche Authentifizierungsmechanismen für
verwendet werden, gehen die Lösungen schnell soweit ausein- Web Services spezifizieren. Wir haben uns damit beschäftigt
ander, dass es an Interoperabilität mangelt und die Entwickler das Username Token Profile 1.0 für PHP5 umzusetzen.
von Client-Applikationen Integrationsprobleme haben. Dieses
Kapitel wird sich mit Sicherheitsmechanismen für Web Ser- C. Username Token Profile 1.0 im Detail
vices auseinander setzen. Das Username Token Profile [8] wurde von OASIS er-
arbeitet. Unsere Umsetzung basiert auf Version 1.0 dieses
A. Anforderungen an gesicherte Web Services Standards. Die Version 1.1 lag zu Beginn unserer Arbeit nur
als Entwurf vor und der erweiterte Funktionsumfang wurde
Wird allgemein von Sicherheit gesprochen, sind viele Din- nicht benötigt. Des Weiteren wird Version 1.0 bereits durch
ge zu beachten. Dabei handelt es sich meist nicht nur um diverse Middleware-Plattformen unterstützt und verspricht so-
funktionale, sondern auch um nicht-funktionale Anforderun- mit eine gute Interoperabilität. Der Standard beschreibt keine
gen. Im Allgemeinen sind dabei die Punkte Datenintegrität,
Vertraulichkeit, Authentifikation und Autorisation anerkannt. 1 Basiert auf Standard 1.0 (am 17.2.2006 wurde Version 1.1 veröffentlicht)6 SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006
neue Techniken, sondern gibt einen Rahmen vor, wie die Die letzten beiden Elemente werden nur für den Pass-
benötigten Informationen für eine Authentifizierung in einem worttyp PasswordDigest benötigt und senden zum einen
standardisierten Format zu übertragen sind. Diese Informa- die Zufallszahl() im Base64-Format und zum
tionen umfassen zum Beispiel Benutzername und Passwort, anderen den Erzeugungszeitpunkt() mit.
aber auch technische Details wie Angaben zum verwendeten Bei den Elementen werden die XML Namensräume
Verschlüsselungsverfahren. wsse (http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-secext-1.0.xsd) und wsu (http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-
1.0.xsd) verwendet.
Der Standard sieht vor, dass Anfragen mit einem alten
Zeitstempel zurückgewiesen werden und ein Cache mit schon
benutzen Zufallszahlen geführt wird. Als Minimum gibt der
Standard eine Empfehlung von fünf Minuten an.
Passwortäquivalent bedeutet in diesem Zusammenhang,
dass dieses extern verschlüsselt sein kann und sollte. Bei unse-
Abb. 5. Beispiel für die Elemente des Username Token Profils im SOAP- rer Umsetzung gilt grundsätzlich das Passwörter immer MD5-
Header
verschlüsselt sein müssen. Dementsprechend gilt auch beim
PasswordText, dass ein Passwort einem MD5(Passwort)
Das Format definiert ein neues Element entspricht und nicht nur durch ein reines Passwort repräsentiert
im SOAP-Header, welches weitere wird.
Elemente mit Web Services Security Daten kapselt. Darauf
Für weitere Details sei auf den Standard [8] verwiesen. Es
folgt ein Element , das die
wurden an dieser Stelle kurz und knapp die grundlegenden
Verwendung des Username Token Profils signalisiert und
Ideen des Standards zu vermittelt. Im Nachfolgenden soll die
die benötigten Daten-Elemente enthält. Das Datenelement
Umsetzung in PHP näher beleuchtet werden.
muss immer angegeben werden und
enthält den unverschlüsselten Benutzernamen. Das nächste
Element enthält das D. Erweiterter SOAP-Server mit WS-Security
Passwort des Benutzers oder Passwortäquivalent. Beim 1) Vorhandene Komponenten: PHP bietet seit der Version
Attribut Type dieses Elements gibt es zwei mögliche Werte: 5 eine Implementierung des SOAP-Protokolls in Form ei-
• PasswordText (Standardwert) Hierbei kann das Type- nes Erweiterungsmoduls. Mit dem Modul lassen sich eigene
Feld leer gelassen werden und als Daten sind nur der Web Services erstellen und vorhandene Dienste nutzen. Si-
Username und das Passwort (bzw. Passwortäquivalent) cherheitsmechanismen sind darin allerdings noch nicht inte-
notwendig. griert. Die Umsetzung des Username Token Profiles für PHP
• PasswordDigest Beim Type-Wert PasswordDigest wird auf Basis der vorhandenen Klassen SoapClient und
wird das Passwort verschlüsselt übertragen. Dabei werden SoapServer erfolgen. Die erstellten PHP Klassen erben
vom Standard keine Verschlüsselungsalgorithmen von diesen bzw. erweitern sie um die zusätzlich benötig-
festgelegt, da diese austauschbar sein sollen. Um ten Aspekte. Dies hat den Vorteil, dass das Abarbeiten von
sicherzustellen, dass keine Anfrage zweimal gesendet SOAP-Nachrichten nicht nochmal neu implementiert werden
werden kann (Replay-Attacke), wird das Passwort muss. Im Idealfall profitiert die erstellte Lösung auch von
(Password) zusammen mit einem Zeitstempel zukünftigen Verbesserungen des SOAP-Erweiterungsmoduls.
(Created) und einer Zufallszahl (Nonce) verschlüsselt. Das Erweiterungsmodul selbst ist in C geschrieben und bietet
Die Formel, nach der sich die Verschlüsselung somit einen klaren Geschwindigkeitsvorteil gegenüber anderen
zusammensetzt, sieht nun wie folgt aus: SOAP-Stacks, die direkt in PHP implementiert sind.
2) Probleme: Dieses Vorhaben erwies sich allerdings als
PasswordDigest = Base64( SHA-1( Nonce etwas problematisch. Das liegt einerseits an der knappen Do-
+ Created + Password )) kumentation der SOAP-Erweiterung, welche ein Review des
C-Quelltextes unerlässlich machte, und andererseits an einigen
Passwort, Zeitstempel und Zufallszahl sind besonderen Features der SOAP-Erweiterung. Beispielsweise
Zeichenketten, die aneinander gehängt, mit dem ruft der SOAP-Server anhand der Namen von Elementen
SHA-1-Algorithmus verschlüsselt und Base64 kodiert im SOAP-Header automatisch Methoden gleichen Namens
werden. Zufallszahl und Zeitstempel werden ebenfalls auf. Dies stellt eine potentielle Sicherheitslücke dar, weil
im SOAP-Header mitgeschickt. Der Server kann mit damit auch Methoden aufgerufen werden können, für die
diesen beiden Informationen und dem ihm bekannten keine WSDL-Ports spezifiziert wurden. Es muss daher eine
Passwort eine Vergleichswert errechnen, um damit die Lösung gefunden werden, welche es ermöglicht die Header-
Korrektheit der Anfrage zu überprüfen. Somit ist jede Informationen aus der SOAP-Nachricht nach deren Verwen-
Anfrage nur genau einmal gültig, denn das Ergebnis der dung zu entfernen. Die aktuelle Implementierung des SOAP-
Formel ist jedes Mal verschieden. Identische Anfragen Servers hat noch einen weiteren Nachteil. Sie sendet nicht
werden vom Server abgewiesen. unter allen Umständen korrekte SOAP-Faults. Das senden si-WEB SERVICE TOOLKIT FÜR PHP5 7
cherheitsrelevanter Fehler-Nachrichten sollte aber immer kor- problem der Ausführung von Methoden durch Header-
rekt ablaufen, gerade wenn Exceptions zur Laufzeit auftreten. Elemente zu verhindern (siehe V-D.6 XmlSoapHeader-
Parser).
Die XML-SOAP-Parser sind demnach eine Anwendung
des Strategy-Patterns2 , denn sie erlauben es, mehrere
Algorithmen unter einem einheitlichen Interface anzu-
sprechen und auszutauschen. Damit können Handler-
chains aus mehreren SOAP-Intermediaries realisiert wer-
den, denn es ist möglich, dem Extended SOAP-Server
beliebig viele XML-SOAP-Parser zu übergeben und diese
sequentiell der Reihenfolge nach abzuarbeiten.
Das Username Token Profile ist folglich nur als ei-
ne konkrete Umsetzung des XmlParserExtended
(siehe V-D.4 XmlSoapSecParser) anzusehen. Dabei
wird in der parse()-Methode auf das Interface
ICheckUserRunnable verwiesen und es einer Im-
plementierung dieser Schnittstelle überlassen, mit den ge-
parsten Werten für Username, Password, Nonce und
Created die die Anfrage auszuwerten. Nachdem die
Authentifikation erfolgt ist, werden alle entsprechenden
Elemente mit der delete()-Methode gelöscht.
Durch die Trennung von Parser und SOAP-Server ist die
Abb. 6. Erweiterungen des SOAP-Servers für Web Services Security Lösung unabhängig vom implementierten Standard. Eine Um-
stellung auf andere Token Profiles oder die Implementierung
3) Extended SOAP-Server: Um die Sicherheitsmechanis- weiterer Web Service Standards ist somit leicht möglich.
men in SOAP zu integrieren, wurde der „Extended SOAP- Damit eine Behandlung der SOAP-Nachricht noch vor der
Server“ entwickelt. Weiterleitung an den eigentlichen SOAP-Server (Ultimate Re-
Dabei war ein wichtiges Designziel, dass weitere Standards ceiver) erfolgen kann, wird die SOAP-Nachricht aus der globa-
möglichst einfach integrierbar sind. Dazu wurde von dem len Variablen $HTTP RAW POST DATA ausgelesen und falls
Problem der Behandlung von Sicherheitsaspekten abstrahiert. nötig durch die Parser angepasst. Das Ergebnis wird wieder in
• XmlParser dieser Variablen gespeichert, da die gekapselte SOAP-Server-
Bei Web Services handelt es sich um eine Übertragung Implementierung auf diese Variable zugreift.
von XML-Nachrichten Daher ist es offensichtlich, dass Es soll hierbei erwähnt werden, dass die Reihenfolge der
die Implementierung von XML-Handlern die Umsetzung Parser einen entscheidende Bedeutung hat. Ein Parser, welcher
von Web Service Standards massiv erleichtern kann. Es den gesamten SOAP-Header entfernt, sollte erst zum Schluss
gibt zwei grundsätzlich verschiedene Arten ein XML- ausgeführt werden. Da allerdings der Extended SOAP-Server
Dokument zu parsen. Auf dem Document Object Model keine Kenntnis über die Semantik der genutzten XML-Parser
(DOM) basierende Parser bilden im Speicher die Baum- hat, ist der Entwickler dafür verantwortlich, die XML Parser
struktur, des XML-Dokuments nach und ermöglichen so- in der richtigen Reihenfolge beim Extended SOAP-Server
mit den wahlfreien Zugriff auf alle Elemente. Die andere zu registrieren. Diese Reihenfolge wird bei der Ausführung
Möglichkeit sind sequentielle, Ereignis-getriebene SAX- beachtet.
Parser. Sie sind einfach beschrieben Tagsucher, welche Nachdem die anspruchsvolleren Probleme gelöst werden
bei jedem vorkommenden Tag eine Methode aufrufen. konnten, blieb nur noch die Frage nach den SOAP-Faults (sie-
Für das Parsen von SOAP-Nachrichten empfehlen sich he V-D.7 SoapFaults) offen. Als gute Lösung erwies sich die
dabei klar die SAX-Parser, da sie performanter sind und Verwendung eines weiteren SOAP-Servers für das Versenden
speichereffizienter agieren. Eine abstrakte Implementie- von Fehlermeldungen. Dabei wird ein minimaler Web Service
rung eines solchen Parsers, welcher Methodensignaturen bereitgestellt, der nicht einmal Dienste anbietet, denn er dient
definiert und eine Methode parse() bereitstellt, ist nur zum Initialisieren des Servers. Mit diesem SOAP-Server
der XmlParser. Diese Methode hat als Rückgabewert ist es nun möglich korrekte SOAP-Faults zu erstellen.
einen Fehlercode, der angibt, ob die Abarbeitung und Damit sind alle eingangs benannten Sicherheitsprobleme
Auswertung des Parsens erfolgreich war (return 0). erfolgreich gelöst.
• XmlParserExtended Allerdings ist es nun vom Design her nicht möglich einen
Der XmlParser wird durch XmlParserExtended Extended SOAP-Server als Ableitung von SoapServer zu
erweitert. Da jeder Parser das gesamte Dokument durch- implementieren, da zwei Exemplare eines SOAP-Servers be-
sucht, ist es sinnvoll schon benutzte Elemente zu ent- nötigt werden. Daher kapselt der Extended SOAP-Server nun
fernen, um doppelte Datenauswertungen zu verhindern. 2 „Define a family of algorithms, encapsulate each one, and make them
Ebenso ist es möglich, durch die richtige Implementa- interchangeable. Strategy lets the algorithm vary independently from clients
tion der Methode deleteHeader() das Sicherheits- that use it.“ [9]8 SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006 sämtliche Funktionen des SOAP-Servers und erweitert ihn um die zusätzlichen Bestandteile (siehe Abb. 6). Sollten später die Probleme in der SOAP-Implementierung behoben werden, ist eine Umstellung auf Vererbung aber nicht grundsätzlich unmöglich. Da eine Trennung der XML- Behandlung erfolgte, ist dies sogar mit relativ wenig Aufwand möglich. Die Verwendung des Extended SOAP-Servers ist nun nahezu identisch zu der des normalen SOAP-Servers. Es wurde lediglich eine Methode nach außen hinzugefügt: addXmlHandler() registriert entsprechend der Erläuterung des Chain-Handlers neue XML-SOAP-Parser und führt sie aus. 4) XmlSoapSecParser: Nachdem die Umsetzung eines Ser- vers näher erläutert wurde, besteht nun die spannende Frage, Abb. 7. Username Token Profile - Ablauf Teil 1 wie der XML-SOAP-Parser für das Username Token Profile aussieht. Der Parser sammelt aus dem SOAP-Header alle notwendi- setzt werden kann. Um nun zu erkennen, ob PasswordText gen Daten zusammen. Dazu zählen die Elemente Username, oder PasswordDigest verwendet wurde, wird in die- Password, Nonce und Created. Sind die benötigten Da- sem Fall auf das Vorhandensein der Elemente Nonce und ten ermittelt, so werden die Daten an eine Implementierung Created geachtet. des Interfaces ICheckUserRunnable übergeben. Dieses Nachdem der SOAP-Header ausgelesen und die notwendi- wird intern in der Methode parse() aufgerufen, die damit gen Daten übermittelt wurden, beginnt der Authentifikations- auch Fehler nach außen reichen kann. prozess, der in dem Petrinetz (Abb. 7 und Abb. 8) dargestellt Die schon oft erwähnte Methode deleteHeader() dient ist. Es lassen sich mehrere Wege durch das Petrinetz finden. nun dazu den gesamten oder nur Teile eines Headers zu Von links nach rechts gilt: entfernen. Grundsätzlich ist es hiermit auch möglich den 1) Sollte entweder die Zufallszahl oder der Zeitstempel Inhalt der gesamten SOAP-Nachricht zu löschen, was aber fehlen wird ein Fehler zurückgegeben. Dazu liefert die wenig Sinn macht. Bei der Implementierung muss die Va- Methode parse() des XmlSoapSecParser nicht 0 riable $this->deleteTag einfach mit dem betreffenden sondern -101 (siehe V-D.7 SoapFaults) Tag gesetzt werden. Nach der parse() Methode wird 2) Handelt es sich um eine Anfrage vom Typ dann automatisch eine Methode des XML Parsers durch PasswordText, dürfen weder Nonce noch den ExtendedSoapServer aufgerufen, welche den ge- Created im SOAP-Header auftauchen. Ist dies samten Inhalt des Tags löscht. Sollen keine Elemente des erfüllt findet die Authentifikation statt. Dabei kann SOAP-Headers entfernt werden, so braucht die Variable es vorkommen, dass ein Benutzer unbekannt ist $this->deleteTag nicht gesetzt zu werden. In der kon- (-104) oder sein Passwort ungültig ist (-105). Bei kreten Implementierung des XmlSoapSecParsers wird der einer erfolgreichen Authentifikation wird in unserer gesamte Inhalt des Security-Elements gelöscht. Beispielanwendung ein globales User-Objekt erzeugt, 5) ICheckUserRunnable und CheckUserRunnable: Die das später für die Autorisation verwendet werden kann. Trennung ist notwendig, da verschiedenste Datenhaltungstech- Anschließend wird die Anfrage an den Web Service niken zur Speicherung der für die Authentifikation benötigten weitergeleitet, sofern keine anderen Parser einen Fehler Benutzerdaten zum Einsatz kommen können. Nur so ist ge- melden. währleistet, eine flexible Implementierung zu erstellen. In der 3) Der gesamte Security Header fehlt und es kann somit Implementierung des Interfaces ICheckUserRunnable ist an dieser Stelle ein Gastaccount geladen werden. die eigentliche Logik des Standards enthalten. Hier wurde als 4) Als letzter Zweig wird nun PasswordDigest abgearbeitet. Beispiel eine Implementierung für die Benutzerverwaltung von Dafür wird als erstes das Alter der Anfrage überprüft. tele-TASK erstellt. Dabei gilt, alle Anfragen älter als fünf Minuten zu Um den Ablauf zu verdeutlichen wurde ein Petrinetz erstellt, verwerfen (-106). Sollte dies nicht der Fall sein wird die welches die Reihenfolge der Überprüfungen verdeutlicht. Es Zufallszahl dekodiert (Base64), alle alten Zufallszahlen besteht aus zwei Teilen um die Komplexität etwas zu verrin- werden entfernt und es wird überprüft ob diese Zahl gern. (siehe Abb. 7 und 8) schon vorhanden ist (-106). Die Implementierung des Username Token Profiles benötigt Sollte nun die gestellte Anfrage nicht doppelt oder zu alt eine relationale Datenbank. Diese wird durch ADOdb und der sein, so wird zuerst das Passwort (MD5 verschlüsselt) Klasse CheckUserDB gekapselt. Die entsprechende Daten- vom Server geholt. Sollte dies fehlschlagen ist hier banktabelle besitzt zwei Spalten mit den Attributen für Nonce ebenfalls der Benutzer unbekannt(-104). Mit dem nun (Primary Key) und dem Created-Zeitstempel. Mit diesen In- erhaltenen Passwort wird auf Serverseite ein zweiter formationen lassen sich doppelte und zu alte Anfragen filtern. Vergleichshashwert berechnet und mit dem Wert aus Etwas problematisch ist, dass das type-Attribut im der SOAP-Nachricht verglichen. Konnte der Hashwert Password-Element durch den PHP5 SOAP-Client nicht ge- korrekt erzeugt werden, so ist die Anfrage gültig und
WEB SERVICE TOOLKIT FÜR PHP5 9
8) Fazit: Als Abschluss soll noch einmal ein kritischer
Blick auf die erstellte Lösung geworfen werden. Es sind
alle geforderten Ziele umgesetzt worden. Die Benutzung des
Extended SOAP-Servers unterscheidet sich nur durch die
Anwendung von XML Parsern. Die WSDL-Beschreibung und
die anwendungsspezifischen Klassen, welche die WSDL-Ports
implementieren, bleiben dagegen völlig identisch.
Die unabhängige Implementierung der Sicherheitsaspekte
konnte durch das Strategy-Pattern gelöst werden. Für eine
Umsetzung von weiteren Web Services Standards wurde damit
eine solide Grundlage geschaffen.
Etwas unschön ist lediglich, dass der Extended SOAP-
Server nicht direkt von dem SOAP-Server der PHP-
Erweiterung abgeleitet werden konnte. Falls zukünftige Ver-
sionen der SOAP-Implementierung dies wieder möglich ma-
chen, ist ein Refactoring des Extended SOAP-Servers mit sehr
geringem Aufwand möglich.
Nachdem die Implementierung von Web Services Security
und dem Username Token Profile auf Serverseite erklärt
Abb. 8. Username Token Profile - Ablauf Teil 2 wurden, soll nun ein entsprechender SOAP-Client vorgestellt
werden.
kann weitergereicht werden (Globales Userobjekt wird
erzeugt und return 0 als Rückgabewert geliefert). E. Umsetzung eines SOAP-Clients mit WS-Security
Andernfalls wird auch hier ein Fehler zurückgegeben Das SOAP-Erweiterungsmodul von PHP5 stellt stellt einen
(-105) SOAP-Client zur Verfügung, der punktuell für das Userna-
6) XmlSoapHeaderParser: Dieser Parser löscht den ge- me Token Profile erweitert wurde. Dabei konnte hier wie
samten SOAP-Header. Dazu nutzt er die Funktiona- in Abb. 9 gezeigt von einer Vererbung profitiert werden.
lität des XmlParserExtended zum Entfernen von Aus der von vorhandenen Klasse SoapClient wurde der
Header-Elementen. Dies funktioniert wie schon zuvor in SecureSoapClient entwickelt.
XmlSoapSecParser beschrieben. Dabei ist der einzige
Unterschied, dass nicht nur das Security-Tag entfernt wird,
sondern sogar der gesamte SOAP-Header. Dieser Parser sollte
daher als letzter an den Extended SOAP-Server übergeben
werden.
7) SOAP-Faults: Die passenden SOAP-Faults für die jewei-
ligen Fehlersituationen sind ebenfalls im Web Services Securi- Abb. 9. Klassenstruktur des Clients
ty Standard spezifiziert (siehe [7] Soap Message Security 1.0).
Tabelle I zeigt die internen Fehlercodes und die zugehörigen Dazu wurde der Konstruktor leicht verändert, damit die zu-
standardisierten SOAP-Faults sowie deren Beschreibung. sätzlichen Parameter wie Name und Passwort entgegengenom-
men werden können. Dieser bietet demnach nun 4 Parameter
TABELLE I
an in denen die zusätzlichen Informationen übergeben werden:
F EHLERCODES
__construct($wsdl , $options, $user, $pw).
Interner Fault- Fault- Mit den zusätzlichen Daten generiert der Client bei jedem
Code Code String Aufruf von __call() automatisch den benötigten SOAP-
-101 wsse:UnsupportedSecurityToken An unsupported token
was provided Header. Die Benutzung der Klasse ist dabei verglichen mit
-102 wsse:UnsupportedAlgorithm An unsupported signature SoapClient nahezu identisch und unterscheidet sich ledig-
or encryption algorithm lich im erweiterten Konstruktor. Das macht es Anwendern sehr
was used
-103 wsse:InvalidSecurity An error was discovered
leicht die Sicherheitsmechanismen zu integrieren.
processing the Die Erstellung des SOAP-Headers ist allerdings mit
header der SOAP-Erweiterung von PHP5 etwas umständlich. Es
-104 wsse:InvalidSecurityToken An invalid security
token was provided
ist erforderlich eine Struktur von Structs zu generieren,
-105 wsse:FailedAuthentication The security token could um einen konformen Header erzeugen zu können. Hierbei
not be authenticated kommen auch die Klassen SoapVar und SoapHeader
or authorized aus der SOAP-Erweiterung zum Einsatz. Der sogenannte
-106 wsse:FailedCheck The signature or
decryption was invalid SecurityStruct, der das Username Token kapselt, wird
-107 wsse:SecurityTokenUnavailable Referenced security token an SoapVar übergeben, welches daraus eine XML konforme
could not be retrieved Darstellung erzeugt. Das Ergebnis wird anschließend dem10 SEMINAR KONZEPTE UND METHODEN DER WEB-PROGRAMMIERUNG 2005/2006
SoapHeader übergeben. Dabei ist leider zu beachten, dass Das Administrations-Tool, das in Kapitel VII näher erläutert
type-Attribute innerhalb eines Elements nicht erzeugt werden wird, wurde so erweitert, dass es mit einem zusätzlichen Flag
können. Damit ist die Interoperabilität vom PHP-Client zu sichere Web Services erstellen kann.
beliebigen Web Services Security Servern leider nicht mög-
lich. Aufgrund dessen, dass der Client nur PasswordDigest G. Interoperabilität
unterstützt, aber dies im Tag nicht identifizieren kann, wird er
Um die Interoperabilität zu überprüfen, wurde der sichere
von anderen Servern als PasswordText interpretiert und dies
Web Service mit einem C# und einem Java Client getestet. Bei-
sorgt für eine Ablehnung der Anfrage. Bei dem erstellten
de Interoperabilitätstests verliefen erfolgreich. Die Umsetzung
Extended SOAP-Server ist dies kein Problem, da er dies
des User Token Profiles auf Client Seite wird hier nicht näher
anhand der übergebenen Argumente herleitet und somit der
erläutert. Es sei hier auf die Referenzimplementierungen3
Server einfach und problemlos mit dem Client kommunizieren
verwiesen.
kann. Demnach ist ein Erfolg bei anderen Servern abhängig
von deren Implementierung.
Im Prinzip ist die Implementierung des Clients recht un- VI. REST FUL W EB S ERVICES
spektakulär. Jedoch wurden einige undokumentierte Funk- A. Representational State Transfer (REST)
tionen der SOAP-Erweiterung benutzt, was die Entwicklung Der Begriff REST bzw. Representational State Transfer
weitaus schwieriger gestaltete, als anfänglich angenommen geht auf Roy Thomas Fielding zurück und wird in [10] im
wurde. Zusammenhang mit Web Services näher beleuchtet. Für Web
Dieser Client kann durchaus als Vorlage für die Implemen- Services im Allgemeinen ist eine Implementierung des REST-
tierung weiterer Token Profiles dienen. Eine Umstellung auf Archtiekturstils in Verbindung mit dem Hypertext Transfer
PasswordText wäre relativ problemlos möglich, um Interope- Protocol (HTTP) besonders interessant und soll hier kurz
rabilität zu anderen Servern gewährleisten zu können. aufgegriffen werden.
Der Hauptgedanke bei RESTful Web Services liegt in der
Verwendung eines uniformen und minimalen Interfaces für
F. Einbettung in das Gesamtsystem
alle Web Services, unabhängig von einem speziellen Einsatz-
Nachdem die Implementierungen von Server und Client bereich. Dies steht damit im Gegensatz zu den auf SOAP auf-
vorgestellt wurden, soll nun ein Blick auf das Gesamtsystem bauenden Web Services, welche als gemeinsame Basis nur das
geworfen werden. Dabei wird das aus [5] bekannte Modell zu SOAP-Nachrichtenformat verwenden und darauf aufbauend
Grunde gelegt (siehe Abb. 10). jeweils eigene anwendungsspezifische Nachrichtenprotokolle
und Schnittstellen definieren.
Wie in [10] dargelegt, hat es verschiedene Vorteile, eine
allgemeingültige Schnittstelle zu verwenden, unter anderem
wird damit die Interoperabilität verbessert, da unabhängig von
einer speziellen Implementierung Aussagen über das zu erwar-
tende Verhalten getroffen werden können. In Bezug auf HTTP-
REST ergeben sich außerdem Vorteile bei der Verwendung
von URI (Uniform Resource Identifier) bezogenen Fähigkeiten
von diversen bestehenden Standards (z.B. XML-Dialekte), da
so die Ressourcen eines RESTful Web Services ohne Umwege
direkt in diesen Anwendungen verwendet werden können. Bei
SOAP basierten Diensten ist für solch eine Verwendung bisher
immer ein Zwischenschritt nötig, da die Ressourcen dieser
Dienste in einem eigenen Namensraum definiert sind.
B. Realisierung mit Hilfe des Toolkits
Für die Erstellung eines Web Services nach dem REST-
Architekturstil sind verschiedene konzeptionelle Schritte nötig,
die im Tutorial [11] und in [10] erläutert werden.
Abb. 10. Gesamtaufbau mit Sicherheit Prinzipiell sollte man sich an dieser Stelle des Konzepts
einer Remote-Facade [12] bedienen, welche das System
In diesem Aufbaumodell wurde nun der Security Agent nach außen hin in geeigneter Weise kapselt und die Methoden
detaillierter dargestellt. Der Extended Server übernimmt dabei zum Abfragen und Manipulieren der Ressourcen des Dienstes
die Kapselung des eigentlichen SOAP-Server und leitet die bereitstellt.
Anfrage an die zwei Parser weiter, die damit entsprechend Das Toolkit stellt nun die benötigten Mechanismen bereit,
ihrer Funktion umgehen. Als letzter neuer Bestandteil über- um den entworfenen URI-Namensraum des REST Services auf
nimmt User Token Check die Authetifikation mit Hilfe der 3 Microsoft Web Services Enhancements 3.0 www.microsoft.com und Java
Datenbank und dem User Management. Axis 1.3 http://ws.apache.org/axis/WEB SERVICE TOOLKIT FÜR PHP5 11
diese Methoden abzubilden und die Ressourcenrepräsentatio- Administration Tool des Web Service Frameworks
nen in geeigneter Weise wählen zu können. Dafür lässt sich Wizard Klassen registrieren Klassen konfigurieren Web Service erstellen Einstellungen
über einen regulären Ausdruck der Aufbau der URIs angeben,
welche den Ressourcen entsprechen, die durch eine Methode Einstellungen
repräsentiert werden. Für jede dieser Methoden kann außerdem Standardsuchpfad für Web Service Klassen:
C:/Programme/Apache Group/Apache2/htdocs
der passende Serializer sowie Deserializer angegeben werden,
Standard-Server:
um die Anfragedaten in programmiersprachliche Konstrukte SOAP-Server
REST-Server
bzw. in ein gewähltes Datenformat zu überführen. Sicherheit:
WS-Security (Username/Token-Profile)
Als Ergebnis wird mit Hilfe eines Tools aus diesen Angaben
Keine
heraus ein Deployment Descriptor generiert, welcher von dem Abbrechen Ok
durch das Toolkit bereitgestellten RESTServer interpretiert
wird, um die Anfragen an den Service abzuarbeiten. Abb. 11. Grafische Oberfläche des Administrations-Tools
C. Sicherheit für RESTful Web Services zu konfigurieren. Klassen werden entweder automatisch in
Da diese Form der Web Services allein auf HTTP aufsetzt, einem gegebenen Klassenpfad gesucht oder können einzeln
kann hier ohne weitere Schwierigkeiten auf die Standardme- angegeben werden. Dabei kann schon der Programmierer einer
chanismen zur Gewährleistung von Sicherheit zurückgegriffen Web Service Klasse mit Hilfe der Annotation @webservice
werden. Sei dies nun mit HTTP over TLS (HTTPS) [13] die seine Klasse als Web Service Klasse markieren. So markier-
Verschlüsselung der Datenübertragung oder die Basic bzw. te Klassen können vom Administrations-Tool herausgefiltert
Digest Authentifizierungsmechanismen [14] zum Steuern des bzw. explizit gesucht werden. Zu einer registrierten Klasse
Zugriffs auf den Service. HTTPS ist in den meisten Fällen an- kann nun angegeben werden, welche ihrer Methoden letzt-
wendungsunabhängig über den HTTP-Server realisierbar, für endlich veröffentlicht werden sollen. Auch dafür gibt es eine
die Authentifizierung hingegen ist oft eine direkte Einbindung Annotation (@webmethod). Des Weiteren hat der Admi-
in die Anwendung wünschenswert. nistrator die Möglichkeit sich Kommentare zu den Klassen
Diese Anbindung erfolgt über die Implementierung des und Methoden aus dem Quellcode anzeigen zu lassen. Zu
AuthProvider-Interfaces. Die kann dann über eine entspre- diesen kann er zusätzlich eigene Kommentare hinzufügen,
chende Konfiguration des RESTServers verwendet werden. die dann von anderen Programmen weiterverwendet werden
Je nach gewünschtem Authentifizierungsverfahren gilt es hier können. Eines dieser Programme ist der WSDL-Generator, der
darauf zu achten, dass gegebenenfalls die Nutzerpasswörter in vom Administrations-Tool genutzt wird um WSDL-Dateien
einer geeigneten Art und Weise abgelegt werden. Details dazu zu erzeugen (siehe Kapitel III). Diesem können die eigenen
sind in der Beschreibung des Interfaces bzw. im entsprechen- Kommentare zur Beschreibung von Web Service Klassen
den Abschnitt des Tutorials zu finden. und Methoden übergeben werden. Ein weiteres Programm,
das vom Administrations-Tool genutzt wird, ist der Adapter-
VII. A DMINISTRATIONS -T OOL & P OLICY-P LUG I N Generator, der zur Erzeugung von speziellen Adapter-Klassen
für Document/Wrapped Web Services dient (siehe Kapitel IV).
Das Administrations-Tool ist eine grafische Oberfläche, die
Letztendlich erzeugt das Administrations-Tool mit Hilfe
der einfachen Konfiguration und Verwendung der Werkzeuge
der Generatoren und der Informationen zu den Web Service
des Web Service Frameworks dient. Das Policy-PlugIn hin-
Klassen die jeweils notwendigen Dateien zur Bereitstellung
gegen fungiert als Filter für Web Service Klassen bzw. deren
eins Web Services und legt diese in dem vom Benutzer
Methoden.
gewünschten Verzeichnis im Dateisystem ab.
Das Administrations-Tool bietet auch einen Assistenten
A. Administrations-Tool (Wizard), mit dessen Hilfe Web Services im Frage-Antwort-
Das Administrations-Tool soll dem Benutzer die Hand- Stil aufgesetzt werden können.
habung des Web Service Frameworks erleichtern. Das Web
Service Framework stellt eine Reihe nützlicher Programme
zur Verfügung, die völlig unabhängig voneinander eingesetzt B. Policy-PlugIn
werden können. Hier setzt das Administrations-Tool an, dass Wie schon erwähnt, dient das Policy-PlugIn der Filterung
eine intuitive und zentrale Möglichkeit der Administration und von Web Service Methoden. Hauptnutzer des PlugIns ist der
Konfiguration der Werkzeuge bieten soll. WSDL-Generator. Dieser bekommt mit Hilfe des PlugIns
Das Administrations-Tool nutzt eine eigene Bibliothek, die diejenigen Methoden einer Klasse heraus, die zur Veröffent-
die grundlegende Funktionalität zur Verfügung stellt und die lichung mittels Web Service gedacht sind. Auch das Policy-
Anbindung an die externen Tools kapselt. Darüber hinaus wird PlugIn benötigt eine Datenbankanbindung, welche wiederum
für die Anbindung der Datenbank ADOdb genutzt und das durch ADOdb gekapselt wird. Durch das PlugIn werden in
Benutzerinterface wird mit Hilfe der Smarty Template Engine der Datenbank Informationen zu Klassen, deren Methoden
realisiert. und Kommentare hinterlegt. Schon durch die Benutzung des
Allgemein hat der Nutzer die Möglichkeit Klassen beim PlugIns wird eine Klasse samt ihrer Methoden registriert und
Administrations-Tool zu registrieren und diese anschließend kann dann wie beschrieben konfiguriert werden.Sie können auch lesen
