A simple centralized approach for solving actual licensing and service protection problems in SDIs using FOSS


Armin Retterath


Eurogeographics - INSPIRE KEN Service/Data Webinar 26.11.2013

Some notes about me

  1. Architect of the SDI for the German Federal State Rhineland-Palatinate since 2005
  2. Chair of the German Working Group for Geoservices (~Spatial Data Services) since 2006

Overview

Rhineland-Palatinate and its SDI

Architectural concept

Security Proxy concept

Handling of information about terms of use

Conclusions/Drawback

Rhineland-Palatinate

Unicorn

Where?

- Somewhere in Europe

Unicorn

Where else?

- Somewhere in Germany

Unicorn

So small?

It depend on the used scale ;-)

Unicorn

Some statistics:

  • Population: 4 Mio (~0.8% of the EU)
  • Area: 20.000 km2 (~0.5% of the EU)
  • Wine production: 6 Mio hectolitre (~3.4% of the EU)

Administrative Boundaries

NUTS 3 Level: 36

NUTS 3

Administrative Boundaries

LAU 1 Level (Collective municipalities): 198

LAU 1

Administrative Boundaries

LAU 2 Level (Municipalities): 2459

LAU 2

Historical development of the SDI (1)

2005

  • Political decision to establish a SDI for Rhineland-Palatinate (by cabinet order)
  • Initial concept for the SDI and the geoportal
  • Europe-wide tender for a geoportal that should be freely distributable

Historical development of the SDI (2)

2006

  • Preparing of a fine-concept
  • Phase of implementation

Historical development of the SDI (3)

2007

  • 8th January - Opening the geoportal to public access

SDI statistics (1)

  • 15.000 registrated users
  • 482 WMS with ~4800 different layers
  • 9 WFS with different 42 use options (comparable to stored queries)
  • 90 authorities which provide OWS

SDI statistics (2)

Distribution of providers

Overview registrating departments

SDI statistics (3)

Concurrent users in the last 3 years

nutzerstatistik

SDI statistics (4)

Requests to the geoportal (last year)

webserver statistics

Architectural concept (1)

The basic principals for service management

  • A central database, where OWS are registered (similar to a metadata catalogue)
  • Central user management in the geoportal (self-registration possible)
  • Central management of authorities as groups in the role concept
  • Each authority can define own roles in the information model
  • Catalogue search reacts on the signed in user and allows requests for access
  • Possibility to set access control at layer/stored query level

Architectural concept (2)

Schema

SDI-RP-schema

Security Proxy concept (1)

Schematic View

proxy schema

Security Proxy concept (2)

Example capabilities with central url

caps1

Security Proxy concept (3)

Example for different urls used in capabilities

caps2

Security Proxy concept (4)

Benefits

  • Servers behind the metadata proxy can get new urls, but the capabilities location is persistant
  • Clients may enhanced to implement the OGC updateSequence parameter for the GetCapabilities request
  • We are able to do many things which are mandated by INSPIRE at one single place
  • Users only need one central account to access services from different authorities
  • We can use the central information to enhance the metadata in our catalogue (e.g. generation of a disclaimer!)

Security Proxy practical workflow (1)

Register Service (provider view)

register_service

Security Proxy practical workflow (2)

Register Service (provider view)

register_service

Security Proxy practical workflow (3)

Activate Security Proxy / Logging (provider view)

activate proxy

Security Proxy practical workflow (4)

Display of the different urls (user view)

usage

Security Proxy practical workflow (5)

Authorization info in catalogue (user view)

catalogue

Security Proxy practical workflow (6)

Authorization info in catalogue (user view)

catalogue

Security Proxy practical workflow (7)

User request for access via mail form (user view)

grant access

Security Proxy practical workflow (8)

Authority grant access to ressource (provider view)

grant access

Security Proxy practical workflow (9)

Usage of secured service in geoportal (user view)

usage

Security Proxy practical workflow (10)

Usage of secured service in geoportal

show url

Security Proxy practical workflow (11)

Transparent usage of http_digest authentication in desktop clients

qgis insert credentials

Security Proxy practical workflow (12)

Transparent usage of http_digest authentication in desktop clients

qgis secure service

Security Proxy practical workflow (13)

Reasons for usage of http authentication

  • It's the standard for http (RFC2617)
  • It it easy to implement
  • More than 80% of GIS clients support it

Security Proxy - Some notes on ressource identities (1)

Update of service

update_service

Security Proxy - Some notes on ressource identities (2)

Update of service - match changed layer names

match layer names

Handling of information about terms of use (1)

Problems

  • Information in metadata is not well standardized
  • Licences for datasets and services may differ
  • Some points regarding data privacy are not considered yet
  • Synchronization with OpenData portals need the knowledge, if the licence "is open" in a common sense (UK solved this problem otherwise ;-) )

Handling of information about terms of use (2)

Our approach to a solution

  • Let the providers choose a predefined licence after registration of service
  • Enrich the information about terms of use with some central information (active logging, defined price, ...)
  • Show a custom disclaimer when connecting to a distributed ressource

Handling of information about terms of use (3)

Metadata editor with option to choose predefined licence

update_service

Handling of information about terms of use (4)

New information about terms of use in html metadata representation

update_service

Conclusions / Drawback

  • There are many open problems regarding security and licences that have to be solved to implement a real SDI in Europe
  • The key would be to keep all things as simple as possible and to use standardized ways
  • We have to look at the metadata and its modelling with reference to standardized licences and data privacy
  • Don't forget one of the biggest goals of an SDI: The access to the ressources should be done via webservices. And each webservice has one single point of access (url) - that have to be persistant. Think about a change of an url and the resulting consequences for the whole infrastructure.
RLP Motto

All components of our portal are based on FOSS

... and can be downloaded as VM for testing

Questions?

Thanks for your attention