Web Services

In den letzten Jahren hat sich das Internet immer mehr zu einer Plattform entwickelt, auf der Dienste angeboten werden. Bisher verwenden Dienste im Internet meist eine Kombination aus HTML-Seiten und HTML-Formularen als Schnittstelle, da sie für die Anzeige in einem Browser
und die Interaktion mit einem menschlichen Benutzer konzipiert wurden. Aus Gründen der Effizienzsteigerung wollen aber viele Firmen mittlerweile Dienste automatisiert nutzen, also ohne menschliche Interaktion, und eigene Dienste schnell und unkompliziert über das
Internet zur Verfügung stellen. Für diesen Zweck sind Formulare ungeeignet, da für jeden Dienst eigene, spezifische Formulare entwickelt werden müssen. Dies erschwert zum einen das Bereitstellen von Diensten und zum anderen deren automatisierte Nutzung und die
Ermittlung von Ergebnissen oder Fehlermeldungen aus den angezeigten HTML-Seiten. Zur Ermittlung der interessanten Informationen einer HTML-Seite müssen aufwändige „screen scraping“-Techniken eingesetzt werden. Diese sind gegenüber Änderungen des Designs der HTML-Seiten nicht robust und müssen so immer wieder angepasst werden. Um vollautomatische Dienstnutzung und Dienstkomposition (Interoperabilität) zu ermöglichen, wird derzeit immer öfter eine neue Technologie eingesetzt: Web Services.

0. Grundlegende Begriffe

Zu Beginn dieser Dokumentation sollen einige Begriffe erläutert werden, die für das Verständnis von Web Services von Bedeutung sind.

• Statische Website: Um zu verstehen wie eine „dynamische“ Website entsteht, sollte man wissen, wie eine „statische“ Website entsteht. Mit dem Entstehungsbegriff ist hier nicht die Entwicklung oder Programmierung gemeint, sondern wie die Website, die in einem Browser auf irgendeinem Rechner auf der Welt aufgerufen wird, dorthin gelangt.
Die Originalwebsite liegt auf dem Webserver und wird auf den Computer des Aufrufenden nur kopiert. Der Browser liest über das HTTP - Protokoll (HyperText Transfer Protocol) die Website von diesem Webserver. Durch dieses Protokoll weiß der Browser, dass es sich um eine HTML - Seite handelt, die er entsprechend zu interpretieren und darzustellen hat. Eine statische Website hat alle Inhalte im HTML - Code. Wenn Änderungen an der Seite vorgenommen werden, geschieht das in einem HTML-Editor. Dies ist bei einer dynamischen Website anders, dort liegen die Inhalte in einer Datenbank.

• Dynamische Webseite: Wenn eine Seite im Webbrowser aufgerufen wird, wird diese Anfrage über das HTTP-Protokoll zum entsprechenden Webserver geschickt, der sich die Seite ansieht. Anhand der Dateiendung sieht er, dass es sich um eine dynamische Webseite handelt. Bei PHP sind dies z.B. die Endungen *.php oder *.phtml.
Deshalb gibt der Webserver die Seite weiter an das PHP-Programm. Das PHP-Programm erkennt, ob Datenbankabfragen in der Seite enthalten sind. Wenn ja, lässt er sich von der Datenbank die entsprechenden Inhalte geben. Die Inhalte fügt er in das vorgegebene HTML-Raster ein. Wenn er fertig ist, gibt er die fertige Seite an den Webserver zurück. Dieser schickt die HTML-Seite per HTTP zurück zum Browser. Dieser stellt dann die Seite am Bildschirm dar. Der ganze Prozess von der Anfrage des Browers bis zur Darstellung der Seite dauert nur wenige Millisekunden (ohne Übertragungszeit der Dateien vom Webserver zum Browser).

• RFC(Requests for Comments): RFC sind eine Reihe von technischen und organisatorischen Dokumenten des RFC-Editor zum Internet (ursprünglich ARPANET), die am 7. April 1969 begonnen wurden. Bei der ersten Veröffentlichung noch im ursprünglichen Wortsinne zur Diskussion gestellt, behalten RFC auch dann ihren Namen, wenn sie sich durch allgemeine Akzeptanz und Gebrauch zum Standard entwickelt haben.

• Performance: Performance bezeichnet in der Informatik den Ressourcenverbrauch und die Qualität der Ausgabe von Programmen und Hardware. Meistens ist mit Performance die Datenrate gemeint, also die Menge von Daten, die innerhalb einer bestimmten Zeitspanne verarbeitet werden kann. Im Gegensatz zur Effizienz, die sich auf die Zeit- und Platzkomplexität eines abstrakten Algorithmus bezieht, bezeichnet die Performance die Leistung eines konkreten Programms auf einem realen Computer.

• Thread: Thread ist die kleinste Verarbeitungseinheit bei einem Betriebssystem bzw. einem Anwendungsprogramm, der Rechenzeit zugewiesen werden kann. Unterstützt das Betriebsystem Multithreading, kann es mehrere Teilaufgaben eines entsprechend konzipierten Anwendungsprogramms parallel verarbeiten. In einem Kommunikationssystem wie in Foren, Newsgroups oder Usenet bezeichnet man eine Folge von Nachrichten bzw. Beiträgen, die als Antwort oder Reaktion auf einen Beitrag bzw. Nachricht aufgegeben wurden, als Thread.

• DCE (distributed computing environment): Das Distributed Computing Environment (DCE) ist eine offene standardisierte Plattform für Client-Server-Architekturen von der Open Software Foundation. In OSF DCE sind nicht nur Schnittstellen definiert, sondern auch Codes.
Die Architektur von DCE benutzt als Basisfunktion eine Verteilplattform mit RPC als zentralem Interaktionsmechanismus. Ziel von DCE ist die Verteilung und Nutzung von Ressourcen auf einer Vielzahl von Rechnern. Jeder Anwender, Client und Server, kann unmittelbar alle zur Verfügung stehenden Ressourcen nutzen. Darüber hinaus unterstützt DCE ein verteiltes Dateisystem sowie die Integration von PCs.

• Middleware: Middleware bezeichnet in der Informatik anwendungsunabhängige Technologien, die Dienstleistungen zur Vermittlung zwischen Anwendungen anbieten, so dass die Komplexität der zugrundeliegenden Applikationen und Infrastruktur verborgen wird. Man kann Middleware auch als eine Verteilungsplattform, d.h. als ein Protokoll (oder Protokollbündel) auf einer höheren Schicht als der der gewöhnlichen Rechnerkommunikation auffassen.

• RSA: RSA ist ein Verfahren oder Algorithmus zur Verschlüsselung elektronischer Daten, der verschiedene Schlüssel zum Ver- und Entschlüsseln verwendet, wobei der Schlüssel zum Entschlüsseln nicht oder nur mit hohem Aufwand aus dem Schlüssel zum Verschlüsseln berechenbar ist. Der Schlüssel zur Verschlüsselung kann daher veröffentlicht werden. Solche Verfahren werden als asymmetrische oder Public-Key-Verfahren bezeichnet.

• SSL-Verschlüsselung: SSL steht für Secure Socket Layer und wurde von der Firma Netscape und RSA Data Security entwickelt. Das SSL-Protokoll gewährleistet, dass Daten während der Übertragung nicht gelesen oder manipuliert werden können und stellt die Identität einer Internetseite sicher. Neben dem Netscape Navigator unterstützten aber auch der Internet Explorer von Microsoft und andere Browser SSL.

• RPC-Nachrichten: Typischerweise treten RPC-Nachrichten paarweise auf. Die Anfrage (der Client sendet Informationen zum Funktionsaufruf an den Server) und die Antwort (der Server sendet einen oder mehrere Rückgabewerte an den Client zurück).

1. Was ist Web-Service

Web-Service ist die neueste und modernste Generation von Webanwendungen. Webanwendungen existieren seit Beginn des Internets, angefangen mit statischen HTML-Seiten, bei denen Informationen mit Hilfe von HTML formatiert und im Browser angezeigt werden. Die Navigation erfolgt dabei durch Links. Bei dieser Art Webanwendung handelt es sich um eine einseitige Verbindung zwischen dem Webserver, der die Anfragen entgegennimmt, und dem Browser, an den die gewünschten Informationen zurückgesendet werden. Dies ist noch keine „Maschine-zu-Maschine-Kommunikation“ sondern eine „Mensch-zu-Maschine-Kommunikation“.

Mit der zweiten Generation wurden dynamische Webseiten eingeführt. Das so genannte Common Gateway Interface (kurz CGI) ermöglichte die Datenerfassung über HTML-Oberflächen, die Bearbeitung der Anfrage am Server und den anschließenden Aufbau einer dynamischen Seite. Mit CGI hat man bei vielen Zugriffen der Endnutzer, wie es im Internet häufig vorkommt, den Nachteil einer schlechten Performance. Deshalb wurde CGI schnell durch serverseitige Webtechnologien, wie Java Servlets, Java Server Pages, Active Server Pages und PHP, abgelöst. Diese Technologien basieren auf Threads, so dass bei jedem neuen Aufruf durch einen Endnutzer nur ein neuer Thread gestartet werden muss. Threads benötigen erheblich weniger Ressourcen und bieten somit eine bessere Darstellung, aber es ist immer noch eine „Mensch-zu-Maschine-Kommunikation“.

Eine wirkliche „Maschine-zu-Maschine-Kommunikation“ wurde erst mit Web-Services realisiert. Damit diese Art Kommunikation gewährleistet werden kann, müssen einheitliche Übertragungsstandards garantieren, dass Daten und Funktionalitäten problemlos zwischen den Kommunikationspartnern ausgetauscht werden können. Dabei findet keine Kommunikation zwischen Menschen statt, daher entstand der Begriff „Maschine-zu-Maschine Kommunikation“. Web-Services bieten dem Endnutzer komplexe Dienste an und suchen nahezu eigenständig nach geeigneten Teildiensten im Internet. Eine typische Anwendung ist z. B. eine Buchung für eine Reise, bei der der Web-Service im Hintergrund weiter Dienste in Anspruch nimmt, wie die Hotelbuchung, Flugticket, Mietfahrzeug usw. Prominente Anwendungen für Web-Services kommen von Google und Amazon. Google erlaubt privaten Webseiten, die Google-Suche per Web Services auf der eigenen Seite zu nutzen, Amazon bietet die Shop-Suche und das deutsche Partnerprogramm als Web Service an.

Bei der Realisierung des Web-Services kann auf Middleware-Konzepte wie CORBA und DCOM gänzlich verzichtet werden. Dadurch unterscheidet sich der Web-Service deutlich vom bereits bekannten distributed computing. Der Verzicht auf Middleware-Konzepte vereinfacht die Handhabung wesentlich. Zu den Stärken des Web-Services gehört, dass die Kommunikation über bekannte Internetprotokolle erfolgen kann. HTTP (siehe Kap. 2), sowie andere Grundfunktionalitäten des Web-Services, beruhen auf anerkannten Standards. Die Nachrichtenübermittlung, Beschreibung und Verzeichnisdienste (siehe Kap. 3-5) zählen zu den wesentlichen Funktionen. Einzig der Bereich der Sicherheit (siehe Kap.6) offenbart noch einige Schwächen. Zurzeit gibt es mehrere Ansätze und Standards hierfür, aber es ist noch nicht ganz abzusehen, was sich wann und wie durchsetzen wird. Allerdings kann man mit PHP selbst eigene Sicherheitsmechanismen implementieren oder auf Altbewährtes zurückgreifen.

Nachfolgende Grafik soll die zugrunde liegende Architektur von Web-Services verdeutlichen:

• Service Anbieter: Service Anbieter sind die Anbieter des Services. Sie implementieren den Service und veröffentlichen dessen Beschreibung und dessen Schnittstellen über das Internet.

• Service Konsument: Service Konsument sind alle möglichen Kunden des Services. Der Kunde benutzt den Service indem er eine Netzwerkverbindung aufbaut, eine evtl. parametrisierten Frage sendet und den erwünschten Service als Antwort darauf erhält.

• Service Verzeichnis: Bei einem Service Verzeichnis handelt es sich um ein zentrales, logisches Verzeichnis von Services. Das Verzeichnis ist ein zentraler Punkt, mit welchem Entwickler ihre Services veröffentlichen können und Kunden existierende auffinden können.

Im Folgenden sollen die Standardisierungsgremien erläutert werden.

• Eines der bedeutendsten Gremien ist das World Wide Web Consortium (kurz W3C), welches unter anderem SOAP und WSDL, zwei der wichtigsten Web-Service Standards für Nachrichtenübermittlung und Beschreibung, verwaltet.

• Ein weiteres Gremium ist die Internet Engineering Task Force (kurz IETF), das unter anderem für HTTP zuständig ist. ITEF weist jedem Standard einen Request for Comment (kurz RFC) zu, mit dem Vorteil, dass man die aktuellsten Standards durch die höhere RFC sofort erkennt.

• Zuständig für UDDI, einen der Verzeichnisdienste des Web-Service, ist die Organisation for the Advancement of Structured Information Standards (kurz OASIS), die auch für WS-Security, eine der verwendeten Sicherheitslösungen, zuständig ist.

• Zu erwähnen sind außerdem das United Nations Center for Trade Facilities and Electronic Business (kurz UN/CEFACT), ein Gremium unter der Leitung der Vereinten Nationen (kurz UN), das sich unter anderem eine Architektur für den elektronischen Geschäftsverkehr definiert, die eine logische Sichtweise auf die abstrakten Bausteine liefert und die Web-Service Interoperability Organisation, die eine Interoperabilität zwischen verschiedenen Web Services-Implementationen sicherstellen möchte.

Angesichts der zahlreichen Gremien und Organisationen offenbaren sich die Schwierigkeiten einer Standardisierung durch einzelne Gremien. Allerdings erleichtert die vereinbarte Aufgabenteilung und Rückendeckung durch große Konzerne, wie IBM und Microsoft, diese mühselige Standardisierung. Dennoch wäre eine Regulierung der Arbeit der einzelnen Gremien durch ein übergeordnetes Gremium vorteilhaft.

2. Kommunikation über HTTP

Das Hyper Text Transmission Protocol (kurz HTTP) ist eines der weltweit wichtigsten Internet-Übertragungs-Protokolle. HTTP das Kommunikationsprotokoll im WWW und damit das schon erwähnte Rückrad des Web-Services, weil Web-Service keine Einzelanwendung ist, sondern einer breiten Öffentlichkeit zugänglich sein soll.

Für den Benutzers ist die Anfrage (engl. request) problemlos. Nach der Eingabe der URI oder Anklicken des entsprechenden Links erhält der Endnutzer als Antwort (engl. response) die gewünschten Daten oder schlimmsten Falls eine Fehlermeldung. Technisch gesehen ist dieser Vorgang aber ein äußerst komplexer Mechanismus, bei dem die Transferdaten die tatsächlich benötigten Informationsdaten häufig um ein Vielfaches übertreffen. Folgende komplexe Vorgänge können von HTTP realisiert werden:

• Der Client teilt dem Server die Anfrage mit. Als zusätzliche Informationen können Authentifizierungsdaten, Cookies usw. übertragen werden.

• Der Server teilt dem Client mit, welchen Status das Ereignis(Ein Ereignis ist eine Aktion oder Zustandsänderung, auf die ein Programm antworten kann. Typische Ereignisse sind z.B. Mausbewegungen, das Drücken einer Taste oder das Klicken auf einer Schaltfläche) hat, d. h. Fehlerinformationen, Authentifizierungsanfragen usw.

• Bei der Übertragung der Nutzdaten können eine Reihe von Metainformationen mit gesendet werden, beispielsweise Gültigkeitsdauer, Sprache, Medientyp usw.

• Informationen zur Verbesserung der Netzwerk-Performance

3. Nachrichtenübermittlung mit SOAP

Für die Kommunikation und den Datenaustausch zwischen Web-Services benötigt man ein standardisiertes und weltweit anerkanntes Protokoll, das alle notwendigen Grundfunktionalitäten zur Verfügung stellt. Das Simple Object Access Protokoll (kurz SOAP), welches federführend von Microsoft und IBM entwickelt wurde, hat sich als ein geltendes Protokoll etabliert. Damit wurden die allgemein geltenden Regeln zum Austausch von Nachrichten und Applikationen verbindlich festgelegt.

Bei SOAP handelt es sich eigentlich um ein zustandsloses, One-way-Paradigma zum Nachrichtenaustausch. Komplexere Interaktionsformen, wie zum Beispiel request-response oder request-multiple-responses, können durch eine Kombination der einfachen Nachrichten mit protokollspezifischen Eigenheiten bzw. Anwendungslogik erreicht werden. Die Spezifikation macht keine Aussagen über die Semantik der zu transportierenden Daten, das Routing der Nachrichten, Verlässlichkeit des Transfers oder der Überwindung von Firewalls. SOAP stellt ein Framework zum Nachrichtenaustausch aufbauend auf vorhandene Protokolle wie zum Beispiel HTTP, SMTP oder FTP dar. Beschrieben werden auch die Aktionen, die ein SOAP-Knoten bei Empfang einer Nachricht auszuführen hat.

Nachfolgende Grafik soll den Aufbau einer SOAP-Nachricht verdeutlichen:

• SOAP-Nachrichten: Das SOAP Envelope stellt das Wurzelelement einer SOAP-Nachricht dar. Es besteht aus den beiden Teilen header und body. Die Inhalte dieser Elemente sind applikationsspezifisch. Es werden in der Spezifikation nur Aussagen darüber gemacht, wie diese Elemente aufgebaut sind.

• SOAP-Header: Das header-Element ist optional. Es wird hauptsächlich dazu verwendet, Kontrollnachrichten zu transportieren. Diese Kontrollnachrichten können Verarbeitungshinweise oder Kontextinformationen der Nachricht beinhalten.

• SOAP-Body: Das body-Element hingegen ist Pflicht. Es enthält die eigentlichen Nachrichten für die Ende-zu-Ende-Kommunikation meist in Form eines RPC request oder response, verpackt in eine XML-Syntax. Diese Inhalte sind wiederum Anwendungsspezifisch und werden deshalb nicht weiter von der SOAP-Spezifikation festgelegt. Als Erweiterung der body-Elemente können Fault-Elemente angegeben werden. Diese regeln, wie von wem auf Fehler zu reagieren ist.

4. Beschreibung mit WDSL

Der Quellcode des Web-Services liegt dem Endnutzer in den seltensten Fällen vor. Dennoch werden unzählige Informationen wie Methodennamen und Parameter unbedingt benötigt, so dass wir auf eine passable und ausführliche Dokumentation angewiesen sind. Diese Dokumentation besitzt der Endnutzer wiederum höchst selten. Daher haben sich große Firmen früh auf eine Web Service Description Language (kurz WSDL) geeinigt. Im Web Service ist WSDL die Schnittstelle und fungiert als Basis für die Identifikation und das Auffinden von Web Services. Dadurch können Anwendungen einem breiten Publikum, z. B. über das Internet, bereitgestellt werden. WSDL ist in der Funktion mit den Typenbibliotheken von CORBA und COM. PHP vergleichbar.

WSDL bietet eine WSDL-Unterstützung an, die mit NuSOAP oder PEAR::SOAP realisiert wird. Die Implementierung der Programme, die WSDL erzeugen und anschließend konsumieren können, ist umfangreich und kompliziert. Ein WSDL Dokument muss einer strengen Grammatik folgen. Diese beinhaltet sowohl die Spezifikation der Methodenschnittstellen, als auch technische Daten, die zur Identifikation, zum Auffinden des Web Services und zur Abwicklung der Kommunikation benötigt werden.

5 .Verzeichnisdienste DISCO & UDDI

Sind die ersten Implementierungsschwierigkeiten erst einmal überwunden, besteht der nächste Schritt bei der Veröffentlichung eines Web Services darin, ihn auch bekannt zu machen. Für Webseiten gibt es Suchmaschinen, für Web Services gibt es Verzeichnisdienste. Denn was nützt die schönste und aufwendigste Implementierung, wenn es keine Mittel und Wege gibt, diese für eine breite Öffentlichkeit nutzbar zu machen.

Zu Beginn existierte die statische Suche mit eingeschränktem Funktionsumfang, z. B. FTP und HTTP GET. Darauf folgend wurde DISCO entwickelt, später WSDL-respository und als derzeit höchste Ausbaustufe gilt UDDI. Die statische Suche hat sich allmählich zu einer dynamischen entwickelt. Der Funktionsumfang wurde immer mehr erweitert.

DISCO ist das Synonym für Discovery (dt. Entdeckung). DISCO nutzt den Web-Service um auf WSDL Informationen zu verweisen und zusätzlich Informationen zu liefern. Dieses einfache Konzept ermöglicht dem Benutzer sowohl den Erhalt des wichtigen URL des WSDL-Dokumentes als auch eine HTML-Seite mit Zusatzinformationen, z. B. über die Schnittstellen. Die Funktion von DISCO beschränkt sich somit auf das Auffinden bzw. Entdecken von Informationen.

Bei UDDI hingegen ist der Funktionsumfang um die Attribute Beschreiben und Verwenden ergänzt. Das Hauptelement ist das Universal Business Registries (kurz UBR), ein Verzeichnis öffentlicher Web-Services, auf dem die Benutzer operieren können.

6. Sicherheit

Web-Services mit PHP bieten zwar eine Menge Vorteile, diese sind aber spätestens dann hinfällig, wenn die notwendige Sicherheit nicht gewährleistet werden kann. Obwohl dieses Problem nicht erst seit heute besteht, hat sich noch keine einheitlich anerkannte oder optimale Lösung herauskristallisiert.

Man unterscheidet zwei Lösungsansätze: entweder wird eine Verschlüsselung eingesetzt oder man richtet ein Autorisierungssystem ein. Bei der Verschlüsselung hat man die Wahl zwischen einer guten Laufzeit, mit dem Risiko, dass die Verschlüsselung geknackt wird, und einer sicheren Verschlüsselung mit dem Nachteil der schlechten Performance. Im Gegensatz dazu bietet ein Autorisierungssystem die Möglichkeit, alle ungewollten Besucher abzublocken und sogar die ungewollten Besucher zu identifizieren, in dem man zum Schein der Authentifizierung stattgibt, ihn aber nur auf wertlose Daten zugreifen lässt.

Bei der Verschlüsselung greift man auf bereits existierende Methoden zurück. Die bekannteste und am meisten etablierte Möglichkeit ist die SSL Verschlüsselung. Zur Absicherung von Web Services ist SSL allerdings nur bedingt tauglich, da sich so zwar der Transportweg zwischen Absender und Empfänger absichern lässt, nicht aber das dabei übermittelte Dokument selbst. So können weder der SOAP-Message-Header noch der im SOAP-Body enthaltene Payload mittels SSL digital signiert oder selektiv verschlüsselt werden, da sonst wichtige Routing-Informationen verloren gingen. Dazu kommt, dass SSL wichtige Session-Informationen, die beispielsweise Auskunft über die Identität eines Aufrufers eines Web Service oder die Gültigkeitsdauer einer Anwendersitzung geben, nur ungenügend ausdrückt. Nicht zuletzt deshalb ist SSL alleine ausschließlich für Punkt-zu-Punkt-Verbindungen geeignet und gewährleistet keine durchgehende Ende-zu-Ende-Sicherheit einer SOAP-Nachricht.

Eine andere Möglichkeit ist IPsec. Dieses Protokoll setzt auf einen Teil von TCP/IP auf und da die zugrunde liegenden Protokolle wie TCP/IP für sich allein unsichere Transportmechanismen sind ist deshalb für öffentliche Netze denkbar ungeeignet.

Eine bessere Lösung bietet die WS-Security, die in SOAP eingebunden wird und XML
Encryption/XML Signature. Letztere sind zwar nicht für Web Service spezifisch entwickelt worden, da aber alles über XML läuft, können auch diese verwendet werden. XML-Encryption ist sehr flexibel, da von der Caesar-Chiffre bis zum RSA jeder beliebige Algorithmus zur Verschlüsselung eingesetzt werden kann. XML Signature verfügt auch über diese Flexibilität, benutzt aber eine asymmetrische Verschlüsselung, d. h. ein System aus öffentlichen und geheimen Schlüsseln, vorzugsweise mit RSA.

Einen ganz anderen Lösungsansatz verfolgt das Autorisierungssystem. Eine beliebte Möglichkeit ist es, eine Art Ticketing-System einzusetzen: Ein Benutzer meldet sich per Benutzername und Passwort bei einem Autorisierungs-Web-Service an und erhält, sofern das erfolgreich war, ein „Ticket“- eine ID; die ihm Zugriff auf den „eigentlichen“ Web Service gewährt. Bei jedem Aufruf einer Webmethode muss das Ticket als Parameter übergeben werden. Der Webdienst überprüft dann, ob das Ticket gültig ist oder nicht; falls es gültig ist, werden die gewünschten Informationen geliefert. Das Autorisierungsverfahren ist eine sehr sichere Methode, die einen wirksamen Schutz vor ungebetenen Gästen bietet. Allerdings kommt auch dieses Verfahren nicht ganz ohne Verschlüsselung aus, denn die Anforderung des Tickets und dessen Rücksendung muss natürlich verschlüsselt werden, vorzugsweise mit RSA.