Http auth

From MapbenderWiki

Jump to: navigation, search

Contents

EN

DE

Funktion

Zur Absicherung von Diensten gibt es im Mapbender das Owsproxy-Modul (owsproxy). Dieses Modul erzeugt dynamische URLs aus der SessionID des jeweiligen Nutzers und einer md5 Repräsentation der jeweiligen Resource (WMS/WFS). Um die dynamische URL nutzen zu können, muss ein Nutzer sich zunächst am Mapbender authentisieren und ein Modul aufrufen, dass ihm die URL dann zur Verfügung stellt. Die URL selbst hängt an der Session des Mapbenders und verfällt mit dieser. Nutzt ein Anwender den abgesicherten Dienst längere Zeit nicht mehr, so verfällt seine Authentisierung und die URL wird ungültig. Es erscheint eine Fehlermeldung 'Permission denied -> wmsId'.

HTTP Authentication

Um nun durch Mapbender abgesicherte Dienste dauerhaft in Fachanwendungen zu integrieren, ist eine persistente URL notwendig. Diese gilt immer und muss nicht mehr ausgewechselt werden.

Um Authentisierungsdaten über das http-Protokoll zu übertragen, gibt es derzeit zwei mögliche, standardisierte Wege:

  1. Basic Authentication
  2. Digest Access Authentication

Diese sind im folgenden Dokument definiert http://www.ietf.org/rfc/rfc2617.txt

Im Gegensatz zum Ansatz mit dem Owsproxy wird hier keine Session generiert oder verwendet. Das Modul ist wie auch das Protokoll stateless und kontrolliert die Autorisierung zur Laufzeit. Um die Entwicklung zunächst zu vereinfachen, dient das Owsproxy Modul als Grundlage. Da dieses Modul derzeit die Berechtigung bis auf die Layerebene hinunter überprüft, wurde das http_auth modul ebenfalls so aufgebaut.

Zur Abgabe der Capabilities-Dokumente wurde bisher in die Mapbender-Datenbank zugegriffen und das letzte hochgeladene Capabilities-Dokument wurde nach Austauschen der URLs abgegeben. Im Falle der Abgabe der Capabilities-Dokumente für einzelne Layer muss anders vorgegangen werden. Hier wird zunächst ein neues Capabilities-Dokument aus der Mapbender-Datenbank generiert und dieses wird an den Nutzer übergeben. Somit kann ein einheitlicher Aufbau der Capabilities-Dokumente gewährleistet werden was insbesondere die Weiterverwendung durch unterschiedliche Clients unterstützt.

Nach außen stellt der Mapbender für jede über den Owsproxy geroutete WMS-Ebene (WFS folgt noch) eine RESTful URL zur Verfügung: http://www.gdi-rp-dienste3.rlp.de/http_auth/24150? Diese URL kann von einem externen Nutzer wie eine normale WMS URL behandelt werden. Der jeweilige Client muss nur in der Lage sein den Standard HTTP Authentication zu unterstützen (In der prototypischen Phase nur http_digest). Beispielaufrufe:

  1. https://www.gdi-rp-dienste3.rlp.de/http_auth/24150?VERSION=1.1.1&REQUEST=GetCapabilities&SERVICE=WMS
  2. https://www.gdi-rp-dienste3.rlp.de/http_auth/24150?VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=wald_bdlm&STYLES=&SRS=EPSG:31466&BBOX=2570000,5596766.666666667,2575600,5601433.333333333&WIDTH=480&HEIGHT=400&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml
  3. https://www.gdi-rp-dienste3.rlp.de/http_auth/24150?version=1.1.1&service=WMS&request=GetLegendGraphic&layer=wald_bdlm&format=image/png

Die für das Beispiel eingerichtete Testkennung lautet:

  • cebit;hans-joachim.ring@lvermgeo.rlp.de

und das Password:

  • tibec

Hinweis: Der Browser speichert die Authentisierungsdaten. Um die Daten zu löschen und sich mit einer anderen Kennung anzumelden, muss man daher bspw. im Firefox unter dem Punkt Extras -> Private Daten löschen die gesicherten Verbindungen aktiviert haben.

Eindeutige Identifikation

Wie hier zu erkennen ist, ist es zur eindeutigen Identifizierung eines Mapbender Nutzers notwendig, als Kennung die Kombination von Nutzernamen und dessen Emailadresse zu verwenden. Das Semikolon als Trennzeichen wird verwendet, da der Doppelpunkt von einigen Bibliotheken (curl) benutzt wird um die Kennung von der Angabe des Passwortes zu trennen.

Clientseitiger Aufruf

Ein Aufruf von der Kommandozeile kann unter Verwendeung der curl-Bibliothek folgendermaßen durchgeführt werden: Es ist nun relativ einfach unter der Nutzung von curl auch den Mapbender dazu zu bringen, auf mit HTTP Authentication gesicherte Dienste zuzugreifen. Hier muss die Tabelle wms um eine Zugriffskennung, ein kodiertes Password (Basic Authentication) sowie einen Digest String erweitert werden. Die Nutzung des Dienstes im Mapbender kann dann problemlos über das Owsproxy Modul erfolgen.

Liste mit Clients die HTTP Authentication unterstützen

  1. ESRI Arc GIS Server 9.3 - Basic und Digest - siehe Abschnitt HTTP authentication http://webhelp.esri.com/arcgisserver/9.3/java/index.htm#wms_service.htm
  2. GAJA 2
  3. GAJA 3
  4. CardCorp - leider nur kurze Kennungen
  5. Wega Mars 5.7.3 - MOSS
  6. udig
  7. QGIS 1.3.0
  8. UMN Mapserver see http://www.mapserver.org/ogc/wms_client.html#mapfile-configuration
  9. Mapbender ab 2.7

Beispiel Apache Konfiguration

Zur Umsetzung der RESTful URL bietet sich ein Umschreiben der URLs durch den Webserver an. Das folgende Beispiel zeigt wie so eine Directive im Apache22 aussehen kann: Wichtiger Hinweis: Das Setzen der Variable ProxyPreserveHost erlaubt später auf den ursprünglichen HOSTNAME über $_SERVER['HTTP_HOST'] zuzugreifen.

Konfigurationsabschnitt mapbender.conf

Hinweis

Die Sicherheit des Verfahrens kann nur dann gewährleistet werden, wenn als Protokoll https verwendet wird. Zwar kann durch die Nutzung der Digest Authentisierung vermieden werden, dass das Password als Klartext im Header übertragen wird, jedoch bietet dies keinen hinreichenden Schutz vor man in the middle-Attacken.

B Server/Proxy

  1. Digest has to be saved to database

  1. Digest has to be updated in database whenever
    1. username is changed TODO
      • php/mod_editFilteredUser.php
      • php/mod_editUser.php
    2. password is changed TODO
      • php/mod_editFilteredUser.php
      • php/mod_editUser.php
      • realm is changed in conf/mapbender.conf TODO
    3. realm is is defined in conf/mapbender.conf - done
  2. The script wms.php is used to get the edited wms-capabilities documents for the single layers!
  3. /owsproxy/index.php - Übergabe der auth Daten an class_connector.php - done - Check for lost exception pictures
  4. /http_auth/index.php - Anpassung der regexpr an https - done - Wird in der mapbender.conf definiert. Man muss aber auch https unterstützen - ist von der jeweiligen Implementierung abhängig.

MB Client

  1. Merging Load und Update WMS (Termin WG)
  2. Merging OWSPROXY Einstellung - ggf. Anzeige ob Kommunikation über http_auth erfolgt - done (Termin WG)
  3. Update WMS Caps
  4. Moduls to be changed:
    • mod_owsproxy_conf.php - Dienste ausgrauen, die http_auth verwenden. - done
  5. Upload WMS Caps
    • php/mod_loadCapabilities.php - Möglichkeit der Eingabe von username, password, auth_type - wenn curl connection in mapbender.conf gesetzt - done
    • php/mod_loadwms.php - Übergabe von username, password, auth_type an class_wms.php - done
    • classes/class_wms.php - Übergabe von auth an class_connector.php - done
    • php/mod_updateWMS.php
    • classes/class_connector.php - Übergabe von auth und Nutzung der Parameter durch curl connection - done
      • Die Klasse bekommt als neuen optionalen Parameter den assozierten array auth. Dieser beinhaltet username, password, realm?,auth_type. Der Wert von auth_type ist entweder basic oder digest. CURL wird entweder mit Basic oder Digest aufgerufen - keine automatische Negotiation - das würde unsicher sein. - done
  6. Change to Database - done

Aktuelle Funktionen

  1. Server: Mapbender arbeitet als WMS-Kaskade mit ggf. editierten bzw. angereicherten Capabilities-Dokumenten. Die Services werden als je ein Service pro Layer nach einem RESTful-Ansatz generiert.
    1. Für den Zugriff auf abgesicherte Services stehen zwei verschiedene Möglichkeiten damit zur Wahl:
      1. HTTP Cookie based: Dynamische Urls, deren Gültigkeit an der SESSION auf dem Mapbender Server hängen, werden generiert. Hier ist ein IP Binding möglich, wird jedoch aufgrund der vielen NATs oft verhindert.
      2. HTTP Authentication: Die Mapbender Benutzerdatenbank, sowie die Berechtigungszuweisung über die GUIs werden zur Authentisierung sowie Autorisierung der Nutzerzugriffe verwendet. Es werden nur Ressourcen freigegeben, für die die Owner den OWSPROXY aktiviert haben.
    2. Logging: Es kann entschieden werden ob die Zugriffe im einzelnen gelogged werden oder nicht (steht in Verantwortung des Eigentümers (owner) des Dienstes). Gelogged werden: timestamp, wms_id, user_id , GetMap Request, Preis(pro Mpixel)
    3. Abrechung: Es kann für jeden Dienst angegeben werden, wie hoch die Kosten pro MPixel sind. Die Ergebnisse werden in eine Log Tabelle geschrieben. (logrotate derzeit noch nicht eingerichtet)
  2. Client: Mapbender unterstützt über curlsowohl Basic als auch Digest Authentication. Die Clientkomponente ist derzeit so eingerichtet, dass die verteilten Services serverseitig abgefragt werden. Zur Anzeige im Mapbender Javascript Client wird der interne OWSPROXY verwendet.
    1. Unterstützte Requests:
      1. GetCapabilities
      2. GetMap
      3. GetFeatureInfo
      4. GetLegendGraphics
  3. Hinweis: Man kann jetzt die Mapbender Services (HTTP Authentication) wieder im gleichen Mapbender registrieren. Das zum Testen auch mehrfach kaskadierend erfolgen (bis der Zugriff zu langsam wird). Die nächsten Tests sollten darauf zielen wie der Mapbender auf Updates der Ressourcen reagieren kann. (Insbesondere in Verbindung mit dem Monitoring-Tool sowie den kommenden automatischen Updateverfahren) Weiterhin sollte das Absicherungsverfahren in der Praxis erprobt werden - done - hat sich bewährt.

Links auf Trunk

  1. Client/Server: http://trac.osgeo.org/mapbender/changeset/4586
  2. Script für Capabilities Auslieferung: http://trac.osgeo.org/mapbender/log/trunk/mapbender/http/php/wms.php

Retrieved from "http://www.mapbender.org/Http_auth"
Views
Personal tools