Rechtebasierter und sicherer Zugriff auf OGC Web Services Markus U. MÜLLER und Andreas POTH Zusammenfassung Mit zunehmender Verbreitung von standardisierten Webdiensten wie Web Map Service und Web Feature Service entsteht der Bedarf an Kontrolle über den Informationsfluss. Nicht alle Daten, die über Dienste solcher Art veröffentlicht werden, sollen ungeschützt für jeden zur Verfügung stehen. Darum bedarf es in der Zukunft Mechanismen zum sicheren und rechtebasierten Zugriff auf OGC Web Services. Sowohl im Rahmen der Initiative GDI-NRW, als auch im OGC selbst hat man diese Problematik erkannt und befasst sich mit der Entwicklung von dementsprechenden Standards. In der Zwischenzeit sind Lösungen gefragt, die Interoperabilität nur zu einem Mindestmaß einschränken und sich an vorhandenen und sich abzeichnende Standards anlehnen. Das Open Source Projekt deegree umfasst mit dem owsproxy eine solche Komponente, die bereits in der Praxis zum Einsatz kommt 1 Problemstellung Geographische Informationssysteme im Inter- oder Intranet sind heute ohne den Einsatz von OGC Web Services (OWS) nicht mehr denkbar; Geodateninfrastrukturen ohne Web Map Services (WMS), Web Feature Service (WFS) und einen Katalogdienst kaum noch möglich. Mit der Verabschiedung weiterer Spezifikationen durch das OGC werden in naher Zukunft zusätzliche Dienste wie der Web Coverage Service (WCS) oder der Sensor Observation Service (SOS) zum Standard moderner, netzwerkbasierter GIS gehören. Mit dem steigenden Einsatz derartiger Dienste, gleich ob auf Freier Software basierend (z. B. UMN MapServer, deegree) oder auf Produkten großer Hersteller (z. B. ESRI ArcIMS, Intergraph Geomedia) steigt die Zahl der verfügbaren Klienten (z. B. deegree igeoportal, SDI Suite, GIS Portal Toolkit, MapBender). Parallel dazu sinkt die Hürde für den Zugang zu OWS; ihre Nutzung ist kein Expertenwissen mehr. Mit der Überführung zahlreicher in den letzten Jahren häufig noch eher prototypisch aufgesetzter OWS-basierter Systeme in den produktiven Betrieb, entsteht zudem die Anforderung, Daten bereit zu stellen, die zwar im Netzwerk verfügbar, nicht aber für jedermann zugreifbar sein sollen. Dies betrifft sowohl die Sichtbarkeit der Daten als solche als auch ihren Transport von Server zum Klienten bzw. umgekehrt. So soll es z. B. möglich sein, bestimmte Layer eines WMS nur für bestimmte Nutzer in einer beschränkten räumlichen Auflösung in ausgewählten Netzsegmenten sichtbar zu machen. Sind die Layer z. B. aus datenschutzrechtlichen Gründen sensibel, soll darüber hinaus sichergestellt werden, dass die Kommunikation zwischen Server und Klient vor dem Zugriff Dritter geschützt ist. Gleichzeitig sollen sich der/die Dienste aber standardkonform verhalten, um Interoperabilität mit anderen Diensten und Klienten zu gewährleisten.
488 M. U. Müller und A. Poth Beide Anforderungen werden bislang von keinem der vom OGC spezifizierten Dienste erfüllt. Daher beschränkt sich ihr Einsatz in der Praxis häufig auf die Bereitstellung freier Informationen (z. B. Stadtpläne) oder den Einsatz im Intranet einer Institution/Firma/ Verwaltung. Dort wo sensible Informationen über einen OWS verfügbar gemacht werden, wird dieser häufig um proprietäre Funktionen/Parameter ergänzt und verhält sich nicht mehr standardkonform (z. B. ausschließliche Verwendung von SSL zum Verbindungsaufbau). Zwar hat das OGC im Juni 2004 die Einrichtung einer Arbeitsgruppe hierzu beschlossen (Geo Digital Rights Management Working Group GeoDRM WG), doch diese steht erst am Anfang ihrer komplexen Arbeit. Parallel wurden in der Initiative Geodateninfrastruktur Nordrhein-Westfalen (GDI-NRW) erste Entwurfs-Spezifikationen erarbeitet, die sich mit der selben Problematik befassen. Mittelfristig müssen diese mit den Aktivitäten des OGC harmonisiert werden. Für die Übergangszeit, bis die GeoDRM WG also entsprechende Standards entwickelt und etabliert hat, ist es notwendig Lösungen zu finden, die den dringend benötigten sicheren und rechtebasierten Zugriff auf OWS ermöglichen, ohne ihre Interoperabilität einzuschränken. 2 Aktivitäten in GDI-NRW und OGC Die Problematik des sicheren Zugriffs auf OWS wurde sowohl innerhalb der GDI-NRW als auch es OGC selbst erkannt. In beiden Gremien haben sich Arbeitsgruppen gebildet, die standardisierte Erweiterungen für OWS entwickeln wollen, die es in der Zukunft erlauben auch in diesem Themenbereich interoperable Software zu erstellen. Die GDI- NRW konnte hier flexibler und schneller agieren und hat bereits Spezifikationen für Dienste solcher Art erarbeitet, während das OGC noch mehr am Anfang dieser Arbeit steht. 2.1 WSS und WAAS der GDI-NRW Bislang weitgehend unabhängig von OGC und GeoDRM Arbeitsgruppe (siehe 2.2) wurde im Rahmen der Initiative Geodateninfrastruktur Nordrhein-Westfalen (GDI-NRW) mit dem Web Security Service (WSS, JUNGERMANN & GARTMANN 2002) ein Dienst spezifiziert, der den Austausch von Informationen zwischen Klienten und OWS über eine abgesicherte Verbindung wie SSL/HTTPS ermöglicht. Da hierfür wieder ein standardisiertes Protokoll zum Einsatz kommt, das die eigentlichen Anfragen kapselt, sind keine proprietären Erweiterungen einzelner Dienste notwendig. Die benutzerabhängige Freigabe einzelner Ressourcen eines OWS ist über einen WSS jedoch nicht standardisiert möglich. Beim sicheren Zugriff auf Informationsressourcen ist es neben der Kontrolle über den Informationsfluss notwendig zu wissen, von wem eine Anfrage abgesetzt wurde. Hierzu wurde der Web Authentication and Authorization Service (WAAS, DREWNAK 2002) spezifiziert. Dieser übernimmt die Aufgabe der Authentizifierung, also der Identifizierung eines Nutzers, was beispielsweise mithilfe einer Nutzername/Passwort-Kombination durchgeführt wird. Ist ein Nutzer authentifiziert, wird jeder Anfrage ein Zertifikat beigefügt, das sicherstellt, dass diese vom entsprechenden Nutzer abgesetzt wurde. Dieses Zerti-
Rechtebasierter und sicherer Zugriff auf OGC Web Services 489 fikat wird vom WSS validiert, bevor dieser den Zugriff auf entsprechende geschützte Informationsressourcen ermöglicht. Beide Spezifikationen bauen auf Standards des IT-Mainstream auf, benutzen also keine speziellen Geo-Standards. Insbesondere die Security Assertion Markup Language (SAML, OASIS 2002) der OASIS spielt eine wichtige Rolle. Da der Web Authentication and Authorization Service nicht im eigentlichen Sinne eine Authorisierung vornimmt, wird der in Zukunft nur noch als WAS bezeichnet werden, was sich auch in der folgenden Abbildung widerspiegelt. Abb. 1: Zusammenspiel von WSS, WA(A)S, WMS und WFS (vereinfacht) Abbildung 1 verdeutlicht das Zusammenspiel der beiden GDI-NRW Security Services mit den Diensten WMS (Kartenzugriff) und WFS (Zugriff auf Vektor-Geodaten). Die Zugriffswege auf WMS bzw. WFS erfolgen auf die gleiche Weise. Das Zusammenspiel der Services ist hier zur Anschaulichkeit vereinfacht dargestellt, insbesondere wurde der in GDI-NRW WSS-Spezifikation beschriebene GetSession-Request hier ausgeklammert. Zuerst authentifiziert sich ein Client (links oben) beim WA(A)S und erhält ein Zertifikat. Dieses Zertifikat fügt er einem DoService-Request bei, der beispielsweise einen WMS GetMap oder WFS GetFeature Request kapselt. Der DoService-Request wird vom WSS entgegengenommen. Der WSS überprüft, ob das Zertifikat valide ist, indem er eine entsprechende Anfrage an den WA(A)S stellt. Der WA(A)S bestätigt die Echtheit des Zertifikates. Jetzt kann der WSS den OWS Request (also einen WMS oder WFS request) an dem WMS/WFS absenden. Abschließend wird die Antwort des WMS/WFS vom WSS and den Client zurückgegeben.
490 M. U. Müller und A. Poth Diese Vorgehensweise erlaubt es insbesondere vorhandene WMS/WFS-Instanzen einzubinden, ohne dass deren Schnittstellen angepasst werden müssen. Es ist nur wichtig sicherzustellen, dass der Zugriff auf den geschützten Service ausschließlich über den zugehörigen WSS möglich ist. 2.2 Die GeoDRM Working Group des OGC Auf dem Treffen des OGC im April 2004 fand die konstituierende Sitzung der Geo Digital Rights Management (GeoDRM) Arbeitsgruppe statt. Das Mission Statement dieser Arbeitsgruppe formuliert, dass Mechanismen zum Digital Rights Management im Umfeld der OGC Web Services fehlen. Die GeoDRM Working Group soll die Anwendung und Weiterentwicklung existierender DRM-Mechanismen für räumliche Fragestellungen koordinieren. Konkrete Aufgaben sind: Formulierung von Anforderungen Erstellung einer roadmap Testen und Überprüfung der Anwendung von DRM-Mechanismen auf OGC-Technologien Erfolgreiche Resultate der GeoDRM Arbeit fördern Die GeoDRM WG trifft sich seither regelmäßig und hat begonnen, das Aufgabenfeld zu sichten und erste Grundsätze seiner Arbeit aufzustellen. Die Prinzipien der Arbeitsgruppe sind: Allgemeiner DRM-Standards (https, SAML, XACML, XrML, MPEG 21-REL, ) sollen wo immer möglich benutzt werden. Embedding without touching : Vorhandene Spezifikationen sollen so wenig wie möglich verändert werden; Sicherheitsmechanismen kapseln ungeschützte Dienste. Sämtgliche Arbeitsschritte erfolgen in enger Zusammenarbeit zwischen Nutzern und Entwicklern im OGC. Spezifische Themengebiete der Arbeit der Gruppe umfassen die Authentifizerung und Authorisierung, Übermittlung des Copyrights, Verteilung, Limitierung der Verteilung, Nachverfolgung von Änderungen, Bepreisung und Bestellung. 2.3 GeoDRM in OWS-3 Ein erheblicher Teil der Arbeit des OGC erfolgt in so genannten Interoperability Initiatives, Projekten, in denen Softwarehersteller in enger Zusammenarbeit mit Sponsoren Lösungen und Entwurfsspezifikationen erarbeiten. Die umfangreichste aktuelle Interoperability Initiative stellt die OGC Web Services 3 Intitiative (OWS-3) dar. Diese befasst sich mit fünf übergeordneten Themengebieten, von denen eines GeoDRM darstellt. Der Anwendungsfall, der hier untersucht werden soll, ist das so genannte click-through licensing. Hierbei soll der Zugriff auf einen WMS oder WFS erst dann erlaubt werden, wenn ein Nutzer bestätigt hat, dass er eine entsprechende Lizenzbedinung gelesen hat und bereit ist, diese anzuerkennen. Lizenzen können auf Ebene von Layern beim WMS oder auf für FeatureCollections/Features bei WFS vergeben werden.
Rechtebasierter und sicherer Zugriff auf OGC Web Services 491 Was auf den ersten Blick wie ein sehr einfacher Anwendungsfall wirkt, kann bei genauerer Betrachtung dazu führen, dass eine Reihe der wichtigen Fragen des GeoDRM gelöst werden müssen. Möchte man vermeiden, dass ein Nutzer das Lesen einer Lizenzbedingung wieder und wieder zu bestätigen hat, ist es notwendig, diesen zu identifizieren (Authentifizierung) und ihm für die Datensätze, für die bereits eine Bestätigung durchgeführt wurde, direkt den Zugriff zu erlauben (Authorisierung). Weiterhin ist es hierfür natürlich unerlässlich, dass Kontrolle über den Informationsfluss ausgeübt wird und beispielsweise sichere Protokolle wie SSL/HTTPS benutzt werden. 3 Lösungsansätze für die Praxis So lange es noch keine verabschiedeten Standards zum Digital Rights Management innerhalb des OGC gibt, müssen alle Lösungen als Übergangslösungen angesehen werden. Für diese Lösungen gilt, dass sie Interoperabilität zwischen vorhandenen Softwarekomponenten nur minimal einschränken und darüber hinaus an Prä-Standards oder lokale Standards wie die der GDI-NRW soweit möglich umgesetzt werden sollen. Ein Beispiel hierfür stellt der im Rahmen des deegree Projekts realisierte owsproxy an. Wie der Name sagt, agiert er als Proxy ( Stellvertreter ) für verschiedene OWS und verbirgt die eigentlichen Dienste. Der deegree owsproxy erscheint für einen anfragenden Klienten z. B. als Web Map Server oder Web Feature Server, sodass mit jedem Standardklienten auf ihn zugegriffen werden kann. Da es sich um eine eigenständige Webapplikation handelt, die z. B. in Servlet Engines wie Apache Tomcat betrieben werden kann, ist der Einsatz nicht auf die Nutzung zusammen mit deegree Web Services beschränkt, sondern kann auf jegliche OWS-Implementierung angewendet werden. deegree stellt darüber hinaus eine Implementierung der GDI-NRW Standards WSS und WA(A)S zur Verfügung, wobei die Unterstützung von SAML bislang noch nicht umgesetzt ist, da in der Praxis noch kein Bedarf hierfür bestand. Im Rahmen der OWS-3 Initiative ist geplant dies nachzuholen. Die Kommunikation innerhalb des owsproxy erfolgt über WSS und WA(A)S Operationen, nach außen wird er wie ein WMS oder WFS angesprochen. Beim Zugriff auf geschützte Ressourcen ist natürlich eine Authentifizierung notwendig. Jeder Instanz eines owsproxy wird bei der Initialisierung eine so genannte Policy-Datei übergeben, die den Zugriff auf den abgeschirmten OWS regelt. Hierüber kann für jeden Parameter der vom gekapselten OWS unterstützten Anfragen ein gültiger Wertebereich definiert werden. Z. B. kann für einen WMS festgelegt werden, dass: Nur die Layer 'Cities', 'Countries' und 'Rivers' über den owsproxy verfügbar sein sollen, alle anderen Layer werden ausgeblendet, Karten maximal in einer Größe von 600 600 Pixel im Format image/png, bei einer maximal zulässigen Auflösung von 10 m pro Pixel und in einem definiert Raumausschnitt liegend abgerufen werden können. Der Wertebereich der übrigen WMS GetMap Parameter (Styles, Exceptions, Transparent, BGColor, Version) kann entsprechend eingeschränkt wer-
492 M. U. Müller und A. Poth den. Ähnliche Einschränkungen lassen sich auch für andere Anfragen bzw. andere OWS festlegen. Alle Einschränkungen sind Untermengen der vom gekapselten OWS bereitgestellten Wertebereiche. Darüber hinaus besteht die Möglichkeit, einen owsproxy an eine Benutzer- und Rechteverwaltung zu koppeln. Damit kann der gültige Wertebereich eines oder mehrerer Parameter an individuelle Rechte einzelner Nutzer(-gruppen) gekoppelt werden. Die Authentifizierung der Nutzer kann auf verschiedenen Wegen erfolgen. Zum einen können an Anfragen Benutzername und Passwort als zusätzliche Parameter, über die sich ein Nutzer bei der Rechteverwaltung authentifiziert, angehängt werden. Alternativ kann für diesen Zweck auch eine an eine Anfrage angehängte ID dienen, die zuvor bei einem dem owsproxy bekannten Authentifizierungsdienst abgefragt wurde und die für einen definierten Zeitraum als Schlüssel gültig ist. Ferner besteht die Möglichkeit, Nutzer über die IP- Adresse mit der sie einen owsproxy anfragen oder über ihre Netzwerkkennung (Intranet) zu identifizieren. Enthält eine Anfrage keine Nutzerkennung, wird sie als von einem anonymen Nutzer stammend behandelt. D. h. zur Authentifizierung sind zwar zusätzliche 'vendorspecific' Parameter erforderlich, doch auch beim Fehlen dieser Parameter ist ein owsproxy als WMS, WFS etc. voll funktionsfähig. Der deegree owsproxy zeigt somit auf beispielhafte Weise eine Lösungsmöglichkeit auf, zum jetzigen Zeitpunkt Sicherheit für OWS zu gewährleisten und Interoperabilität nur im unbedingt notwendigen Maße einzuschränken. 4 Ausblick Mittelfristig wird die GeoDRM Arbeitsgruppe des OGC die benötigten Standards für den rechtebasierten und sicheren Zugriff auf OWS entwickeln und diese sind dann zu unterstützen. Für die Übergangszeit sind pragmatische Lösungen gefragt, wie der beschriebene deegree owsproxy. Dieser erlaubt es vorhandene Clients und Services weiterhin einzusetzen und setzt zu großen Teilen bereits jetzt die Standards der GDI-NRW um. Weiterhin beteiligt sich lat/lon an der OWS-3 Initiative und ist dort verantwortlich für die Spezifikation und Entwicklung eines GeoDRM-enabled WFS. Im Rahmen dieser Aktivitäten wird der deegree owsproxy sowohl für den Zugriff auf WFS als auch für WMS an die in Entwicklung befindlichen Standards des OGC zum GeoDRM angepasst. Referenzen DREWNAK, J. (Hrsg.) (2002): GDI-NRW Testbed II Web Security Service. http://www.gdi-nrw.org/index.php?id=37. JUNGERMANN, F. & G. GARTMANN (Hrsg) (2002): GDI-NRW Testbed II Web Authentification and Authorization Service. http://www.gdi-nrw.org/index.php?id=37. OASIS (2002): Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML). http://www.oasis-open.org/committees/security/docs/cs-sstc-bindings-01.pdf.