Zugriffskontrolle in Geodateninfrastrukturen: Der Web Authentication and Authorization Service (WAAS)

Transkript

1 Zugriffskontrolle in Geodateninfrastrukturen: Der Web Authentication and Authorization Service (WAAS) Rüdiger GARTMANN, Felix JUNGERMANN Zusammenfassung Die fortschreitende Standardisierung von Internet-GIS-Technologien lässt die verteilte Nutzung von Geoinformationen über das Internet mehr und mehr Realität werden. Für einen kommerziellen Vertrieb von Geoinformationen sind diese Technologien alleine jedoch noch nicht ausreichend. Hier werden zusätzlich traditionelle ecommerce- Funktionalitäten wie die Unterstützung von Preisberechnung und Verkaufstransaktionen sowie die Gewährleistung des Zugriffsschutzes benötigt. Dieses Papier soll aufzeigen, wie ein Zugriffsschutz in verteilten Geo-Web-Service-Umgebungen realisiert und wie dieser in bestehende OGC-konforme Geodateninfrastrukturen integriert werden kann. 1 Einleitung Weltweit schreitet die Entwicklung von Geodateninfrastrukturen voran. Im Rahmen dieser Infrastrukturen stellen Anbieter ihre Geoinformationen über standardisierte Web-Services zur Verfügung. Hierdurch soll eine breitere Nutzung dieser Ressourcen durch einen vereinfachten Zugang sowie eine effizientere Nutzung durch vielfältige Integrationsmöglichkeiten unterschiedlicher Datenbestände erzielt werden. Durch die Standardisierungsbemühungen des OpenGIS Consortiums (OGC) stehen bereits eine Reihe von Diensten für die Nutzung über das Internet zur Verfügung. Allerdings sind diese Geoinformationen in der Regel wertvoll und nicht öffentlich, wie etwa personenbezogene oder militärische Daten. Diese Daten sind zum Teil nur bestimmten Benutzergruppen zugänglich, zudem sollen sie in der Regel kommerziell genutzt, also verkauft werden. Nachdem mit dem Web Pricing and Ordering Service (WPOS) (WAGNER 2002) bereits eine Lösung zur Abwicklung von kommerziellen Transaktionen mit Geodaten in den Standardisierungsprozess des OGC eingereicht wurde, besteht der nächste Schritt darin, den Zugriff auf Geodatenbestände nur berechtigten Personen, also Personen, die dafür gezahlt haben oder die eine anderweitige Berechtigung besitzen, zu gestatten. Eine wichtige Forderung in diesem Zusammenhang ist hierbei, die Vorteile von Geodateninfrastrukturen damit nicht aufzugeben. Im Einzelnen bedeutet dies, dass diese Dienste für berechtigte Benutzer nach wie vor über das Internet zugreifbar bleiben und dass weiterhin Standardsoftware einsetzbar sein soll, die die vom OGC spezifizierten Schnittstellen unterstützt und nicht mit zusätzlichen Sicherheitsfunktionen erweitert werden muss. Bislang gibt es für diese Problemstellung seitens des OGC noch keine Lösung.

2 Rüdiger Gartmann, Felix Jungermann Im Rahmen der Geodateninfrastruktur Nordrhein-Westfalen (GDI NRW) wurde ein Ansatz entwickelt, um diesen Anforderungen gerecht zu werden. Der hier vorgestellte Web Authentication and Authorization Service (WAAS) (GARTMANN, JUNGERMANN 2003) ist das vorläufige Ergebnis dieser Arbeiten. 2 Authentisierung und Autorisierung mit dem WAAS Der WAAS ist ein Dienst, der Benutzer authentisieren und für Zugriffe auf Geo-Services autorisieren kann. Hierzu muss der Benutzer bei diesem Dienst registriert sein. Eine Authentisierung erfolgt, wenn der Benutzer durch einen speziellen WAA-Client dem WAAS mitteilt, welche Ressource, also welchen Geo-Service, er nutzen will. Zudem muss er sich gegenüber dem WAAS authentifizieren. Dies kann durch verschiedene Verfahren geschehen, beispielsweise durch Verwendung von Passwörtern, durch Kryptographiekarten oder mit Hilfe von biometrischen Verfahren. Eine Festlegung auf ein bestimmtes Verfahren ist nicht Bestandteil der WAAS Spezifikation und soll flexibel gehalten werden. Der WAAS prüft nun die Identität des Benutzers. Fällt die Prüfung positiv aus, so erstellt der WAAS ein digital signiertes Zertifikat, welches den Benutzer berechtigt, die gewünschte Ressource zu nutzen. Dieses Zertifikat kann er nun der Ressource vorlegen und damit seine erfolgreiche Authentifizierung nachweisen. Der eigentliche Geodienst wird hierbei durch einen sogenannten Web Security Service (WSS) (DREWNAK 2003) geschützt, der das Zertifikat prüft und nur berechtigte Requests an den Geo-Service weiterleitet. Zur Erstellung des Zertifikats wird das SAML-Format (Security Assertions Markup Language) verwendet, welches von OASIS spezifiziert worden ist (OASIS 2002). Dieses Format erfüllt die sich aus dieser Problemstellung ergebenden Anforderungen und ist flexibel genug, um auch Erweiterungen des WAAS-Protokolls zu unterstützen. Der Vorteil dieser Lösung gegenüber einer Authentisierung durch den Geodienst selbst ist, dass hier der Benutzer dem Geodienst nicht bekannt sein muss. Er muss lediglich einem (von mehreren möglichen) WAAS bekannt sein und kann sich somit für jeden Dienst innerhalb einer Geodateninfrastruktur authentifizieren. Ein WAAS kann auch die Authentifizierung für mehrere Geodienste übernehmen. Dieses Verfahren entlastet so den Benutzer davon, bei allen zu benutzenden Diensten separate Accounts anzulegen und möglicherweise sogar noch unterschiedliche Authentifizierungsverfahren nutzen zu müssen. Auf der anderen Seite entfällt für die Geodienste der Aufwand, eine eigene Benutzer- und Rechteverwaltung zu unterhalten. Ebenso wie der Web Pricing and Ordering Service stellt der WAAS keinen geospezifischen Dienst im eigentlichen Sinne dar. Es handelt sich hierbei um einen Zusatzdienst, der Geodateninfrastrukturen ergänzt, aber mit der eigentlichen Verarbeitung der Geoinformationen nicht interagieren soll. Sowohl der eigentliche Geodienst als auch der Client, mit dem dieser aufgerufen wird, sollen durch die Verwendung des WAAS nicht durch WAAS-spezifische Funktionalitäten erweitert werden müssen. Die eigentliche Funktionalität des WAAS wird völlig transparent für die eigentlichen Geodienste in das

3 Zugriffskontrolle in Geodateninfrastrukturen: Der Web Authentication and Authorization Service Protokoll, das von den Geodiensten verwendet wird, hineingeschachtelt. Eine schematische Darstellung findet sich in Abb. 1. Geo Client WAA Client WAAS Web Security Geo Service Service Abb. 1: Sequenzdiagramm eines zugriffsgeschützten Geoservice-Aufrufs Der Geo Client besitzt keinerlei WAAS-Fähigkeiten. Mit diesem Client kann der Benutzer einen Request erzeugen, den er ohne Zugriffsschutz direkt an den Geo Service richten würde. Unter Verwendung des WAAS wird dieser Request jedoch an den WAA Client gesandt (1), der sich aus Sicht des Geo Clients genau wie ein Geo Service verhält. Der WAA-Client sendet nun einen Authenticate -Request an den WAAS (2), in dem er den ursprünglichen Geo-Request sowie seine Authentifizierungsinformationen übersendet. Der WAAS sendet nach erfolgreicher Authentisierung als Response das Zertifikat zurück (3). Nun sendet der WAA Client den Geo-Request sowie das Zertifikat an den Web Security Service (4). Akzeptiert dieser das Zertifikat, so leitet er den Geo-Request an den Geo Service weiter (5), der die gewünschte Antwort an den Geo Client übergibt (6). Die vom WAAS ausgegebenen Zertifikate beziehen sich lediglich auf eine bestimmte Ressource, soll eine weitere Ressource aufgerufen werden, so wird ein neues Zertifikat benötigt. Zudem besitzen sie einen Gültigkeitszeitraum, der auf wenige Minuten beschränkt werden sollte, so dass dieses Zertifikat nicht speicherbar und für spätere, womöglich unberechtigte, Zugriffe verwendbar ist. Der WAA-Client und der Web Security Service besitzen die Möglichkeit, eine Session aufzubauen. So wird es ermöglicht, dass ein Benutzer nicht für jeden einzelnen Request ein neues Zertifikat einholen muss. Dieses wird nur beim initialen Request benötigt, alle weiteren Requests in der gleichen Session können ohne Zertifikat verarbeitet werden.

4 Rüdiger Gartmann, Felix Jungermann Die Initiierung des WAAS-Protokolls beim Aufruf eines Geo-Services geschieht, indem der Geo-Service in seinen Capabilities sowie in den Metadaten, die diesen Service beschreiben, angibt, dass zu seiner Nutzung ein Zertifikat eines WAAS erforderlich ist. Somit wird der Geo-Client angewiesen, nicht den Geo-Service direkt, sondern einen WAA- Client anzusprechen. Dieser WAA-Client agiert aus Sicht des Geo-Clients genau wie ein Geo-Service, initiiert jedoch den Authentisierungsprozess. 3 Prinzip der Protokollschachtelung Die vom OGC spezifizierten Web Services beziehen sich auf reine Geo-Services. Mit diesen Diensten ist es möglich, komplexe Geodateninfrastrukturen aufzubauen, die es erlauben, verteilte Geoinformationen über Internetprotokolle zu integrieren und zu nutzen. Zusatzdienste wie Authentisierung oder Verkaufstransaktionen sind in diesen Diensten nicht berücksichtigt. Bei der Entwicklung von Zusatzdiensten ist es daher anzustreben, diese so zu spezifizieren, dass deren Nutzung keine Auswirkung hinsichtlich der Implementierung der bereits vorhandenen Infrastrukturen hat. Vorhandene Geo-Clients sollen also ungestört mit ihren Geo-Services kommunizieren, unabhängig davon, ob diese Interaktion durch einen Zusatzdienst wie den WAAS unterstützt wird. Die Nutzung solcher Zusatzdienste soll somit für die Geodienste völlig transparent geschehen. Um dieses Ziel zu erreichen, müssen das Geo-Protokoll und das WAAS-Protokoll auf unterschiedlichen logischen Schichten realisiert werden. Das Verfahren wird bereits vom Web Pricing and Ordering Service genutzt (vgl. WAGNER 2002) und wird in Abb. 2 veranschaulicht. Geo Client Geo Request Geo Response Geo Service Geo Request Geo Request Geo Response Geo Service Fassade WAA Client WSS Request WSS Response WSS Geo Client Fassade Geo Response Abb. 2: Prinzip der Protokollschachtelung In der Abbildung wird auf die Darstellung der Kommunikation mit dem WAAS zur Einholung des Zertifikats verzichtet, da dies für die Beschreibung des Protokollschichtungsansatzes nicht von Relevanz ist. Die gestrichelten Pfeile stellen die

5 Zugriffskontrolle in Geodateninfrastrukturen: Der Web Authentication and Authorization Service Kommunikation ohne Zugriffsschutz dar. In diesem Fall sendet der Geo Client einen Request an den Geo Service und bekommt die entsprechende Response. Die durchgezogenen Pfeile veranschaulichen das Verfahren bei Benutzung des Zugriffsschutzes. Der Geo Client erzeugt den gleichen Request als würde er direkt den Geo Service ansprechen. Statt des direkten Aufrufs wird dieser Request aber an den WAA Client umgeleitet. Dieser WAA Client bietet die gleichen Operation an wie der Geo Service, er besitzt also sozusagen eine Geo Service Fassade. Das bedeutet, er nimmt jeden request entgegen, führt die Authentisierung durch und leitet den Request zusammen mit den Authentisierungsinformationen an den WSS weiter, der den eigentlichen Geo-Service kapselt. Hierzu transformiert er den Geo Request nun in das WSS Protokoll. Dieses Protokoll muss die benötigten Funktionalitäten des gekapselten Dienstes, hier also des WSS, aufnehmen sowie den eigentlichen Geo Request mittransportieren. In diesem Fall geschieht dies dadurch, dass dem Geo Request ein Zertifikat hinzugefügt wird. Der WSS prüft das Zertifikat, extrahiert den ursprünglichen Geo Request und sendet ihn an den Geo Service. Dabei agiert der WSS als Geo Client, er besitzt sozusagen eine Geo Client Fassade und ist für den Geo Service nicht von anderen Geo Clients unterscheidbar. Der Geo- Service produziert die Response auf den an ihn gerichteten Request und leitet diese durch den WSS und den WAA-Client wieder an den Geo-Client zurück. Auf diese Weise können beliebige Zusatzdienste in bestehende Geodateninfrastrukturen eingebettet werden. Unabhängig von der Art des Zusatzdienstes ist für dieses Schachtelungsverfahren die Fassadentechnik sowie der Transport des Geoprotokolls im Protokoll des Zusatzdienstes kennzeichnend. Dieses Verfahren kann auch mehrfach angewandt werden, etwa indem ein WPOS Protokoll noch in das WSS Protokoll hineingeschachtelt wird. In diesem Fall müsste der WPO Client eine WSS Fassade und der WPOS eine Fassade des WAA Clients besitzen. In das WPOS Protokoll müsste dabei das WSS Protokoll aufgenommen werden. 4 Sicherheit des Verfahrens Um die Sicherheit des Protokolls zu gewährleisten, muss die komplette Kommunikation zwischen WAA-Client, WAA-Service und Web Security Service verschlüsselt werden. Hier bietet sich das Secure Socket Layer (SSL) Verfahren an, dass sich mittlerweile als Standard-Verschlüsselungsverfahren im Internet etabliert hat. Die Verwendung von SSL geschieht für die Anwendung völlig transparent. Bei diesem Verfahren verfügen Server über ein SSL-Zertifikat, das von unabhängigen Zertifizierungsstellen herausgegeben wird und vom Client jederzeit verifiziert werden kann. Hierdurch wird sichergestellt, dass kein Angreifer einen falschen WAAS zur Verfügung stellt, der die Authentifizierung des Clients missbräuchlich nutzen kann, da dieser nicht über das korrekte SSL-Zertifikat verfügt. Der gleiche Mechanismus wirkt auch bei der Kommunikation zwischen WAA-Client und Web Security Service und stellt sicher, dass kein falscher WSS das Zertifikat des Clients entgegennehmen kann, um es anschließend missbräuchlich zu benutzen.

6 Rüdiger Gartmann, Felix Jungermann Zudem ist die Kommunikation mit SSL durch einen symmetrischen 128 Bit Schlüssel chiffriert. Ein Brechen dieses Schlüssels ist bislang praktisch nicht realisierbar, vor allem dann nicht, wenn die Gültigkeit eines Zertifikats auf wenige Minuten beschränkt ist und das Brechen des Schlüssels in diesem Zeitraum erfolgen müsste. Die Kommunikation zwischen Geo-Client und WAA-Client sowie zwischen WSS und Geo-Service kann in einem geschützten Bereich stattfinden, etwa hinter einer Firewall oder ebenfalls mit SSL verschlüsselt. 5 Kaskadierung von Diensten Bislang war immer von einem Benutzer die Rede, der sich gegenüber dem WAAS authentifizieren muss. Dies muss nicht zwangsläufig immer ein menschlicher Benutzer sein, vielmehr ist dies vermutlich in voll ausgeprägten Geodateninfrastrukturen eher die Ausnahme. Ebenso können Client-Applikationen dieses Verfahren nutzen, um sich gegenüber Services zu authentifizieren. Insbesondere bei Web Service Kaskaden, bei denen mehrere Web Services aufeinander aufbauen, ist dies von Relevanz. Technisch ist es ohne Belang, ob ein menschlicher Benutzer oder ein kaskadierender Dienst beim WAAS ein Zertifikat anfordert. Bei Kaskaden nimmt ein Geo Service zusätzlich die Rolle eines Geo Clients ein, wenn er wiederum einen Request an einen weiteren Geo Service absetzt. Zu beachten ist, dass sich in der derzeitigen Architektur mit dem WAAS jeweils ein Geo Client gegen den von ihm genutzten Geo Service authentifiziert. Das bedeutet, dass die Identität des initialen Clients nicht über mehrere Stufen einer Kaskade hinweg übermittelt wird. Dies erscheint jedoch auch nicht notwendig. Schließlich besitzt der Client, der den initialen Request abgesetzt hat, keine Informationen darüber, welche Dienste in dieser Kaskade aufgerufen werden. Alle Requests, die der kaskadierende Dienst absetzt, sind für diesen Client transparent. Wenn jedoch in den vom WAAS ausgegebenen Zertifikaten die anzusprechende Ressource referenziert wird, so besitzt dieser Client keine Möglichkeit, Zertifikate für Requests, die von kaskadierenden Services abgesetzt werden, zu erzeugen, da er die Requests nicht kennt. Aus Sicht des Clients erbringt der von ihm angesprochene Service die komplette Leistung. Unter der Voraussetzung, dass alle angesprochenen Services in einer Kaskade vertrauenswürdig sind, besteht allerdings die Möglichkeit, dass sie die Identität des initialen Clients in ihre nachgelagerten WSS-Requests aufnehmen und diese weiterleiten. So erhalten alle an der Kaskade beteiligten Dienste neben der Identität des Dienstes, der sie aufruft, auch die Identität des Clients, der den Ausgangspunkt der Kaskade darstellt. Der Bedarf für eine solche Lösung ist allerdings bislang noch nicht absehbar und hängt in erster Linie von organisatorischen und rechtlichen Faktoren ab. So ist etwa zu klären, inwieweit eine amtliche Stelle nicht-öffentliche Geo-Daten innerhalb einer Kaskade an

7 Zugriffskontrolle in Geodateninfrastrukturen: Der Web Authentication and Authorization Service einen weiteren Dienst abgeben und die Prüfung der Berechtigung des zugreifenden Benutzers delegieren darf. 6 Zusammenfassung und Ausblick Der momentane Stand der Spezifikation und Implementierung des WAAS ist bislang noch auf die Authentisierung beschränkt. Dies ist gleichbedeutend damit, dass ein registrierter Nutzer Dienste ohne weitere Einschränkung nutzen kann, das heißt, ein authentisierter Benutzer ist gleichzeitig auch für den Dienst autorisiert. In der Praxis wird dies in den überwiegenden Fällen als ausreichend angesehen. Im nächsten Schritt ist geplant, ein feineres Autorisierungsmodell zu entwickeln. Dies erfordert, dass Geo-Ressourcen ihr Berechtigungsmodell in einem XML-Format angeben. Hierzu sollten sinnvollerweise Benutzergruppen definiert werden, denen einzelne Benutzer zugeordnet werden. An dieser Stelle ist anzumerken, dass für eine Autorisierung, die nicht nur die Berechtigung zum allgemeinen Zugriff auf einen bestimmten Service, sondern Berechtigungen für den Zugriff auf Datenbestände oder Funktionalitäten eines Services prüft, eine Interpretation des Geo-Requests durch den WAAS notwendig wird. In diesem Fall benötigt der WAAS Kenntnisse des verwendeten Geo-Protokolls und ist nicht mehr absolut generisch. Daher ist zu diskutieren, ob eine so feingranulare Zugriffskontrolle notwendig und praktikabel ist. Zu beachten ist, dass das hier beschriebene Authentisierungsverfahren für die Anwendung in Infrastrukturen entwickelt wurde. Viele Geodatenportale bieten bereits jetzt Zugriffskontrollverfahren an, wie etwa die Abfrage von Passwörtern oder die Verwendung von Signaturkarten. Diese Verfahren sind darauf ausgelegt, dass ein Benutzer mit einem Portal kommuniziert, das ihm bekannt ist und bei dem er einen Account besitzt. Für dieses Use Case wird keine weitergehende Technologie benötigt. Als Bestandteil von Geodateninfrastrukturen greift ein solches Portal jedoch nicht bzw. nicht ausschließlich auf einen eigenen, lokalen Datenbestand zu, sondern es nutzt weitere, externe Services. Erfordern diese Services eine Zugriffskontrolle, so kann diese über WAAS gewährleistet werden. Die Kommunikation des Benutzers mit dem Portal ist davon nicht berührt und kann weiterhin über traditionelle Zugriffskontrollverfahren gesichert werden. Als Vorteil des WAAS ist zu sehen, dass es sich hier um einen generischen Ansatz handelt, der in allen Web-Service-Infrastrukturen so zum Einsatz kommen kann. Auch wenn es innerhalb des OGC Bestrebungen gibt, das Basic Service Model, welches die grundlegende Struktur aller OGC-konformen Web-Services definiert (OPENGIS CONSORTIUM 2001), zu modifizieren, kann der hier beschriebene WAAS weiterhin unverändert genutzt werden. Auch eine Nutzung innerhalb von nicht-geo Web-Service-Infrastrukturen ist problemlos möglich.

8 Rüdiger Gartmann, Felix Jungermann Der hier beschriebene WAAS wurde innerhalb eines Testbeds im Rahmen der Geodateninfrastruktur Nordrhein-Westfalen (GDI NRW) im Jahr 2002 erfolgreich entwickelt, implementiert und erprobt. Die als Ergebnis dieser Testbed-Aktivitäten entstandene Spezifikation wird als offizielles GDI NRW-Dokument in der Version 0.1 öffentlich publiziert. Literatur Drewnak (2003): Testbed II Web Security Service, Gartmann, Jungermann (2003): Testbed II Web Authentication & Authorization Service, OASIS (2002): Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML), / OpenGIS Consortium (2001): Basic Services Model Draft Candidate Implementation Specification, Wagner (2002): Perspektiven mit dem Complex Configuration & Pricing Format (XCPF) und dem kaskadierfähigen Web Pricing & Ordering Service. (AGIT-Symposium 14, 2002, Salzburg). In: Strobl, J.: Angewandte Geographische Informationsverarbeitung XIV, Beiträge zum AGIT-Symposium Salzburg 2002 Heidelberg, Wichmann, 2002, S Wagner, Gartmann (2002): GIS Meets ebusiness. Web Pricing & Ordering Service (WPOS). (Geospatial Information & Technology Association (Annual Conference) 25, 2002, Tampa/Fla.) In: Geospatial Information & Technology Association -GITA-, GITA Annual Conference 25 Tampa, USA, 2002