Secure WMS

White Paper

Secure WMS

Table of Contents
Secure WMS Documentation White Paper................................................................3 1 Introduction....................................................................................................................3

2 Concepts........................................................................................................................3 2.1 Other approaches and comparison..................................................................................5 3 4 5 5.1 5.2 5.3 5.4 6 Communication Protocol..............................................................................................6 Client secure WMS application.....................................................................................7 Server component.........................................................................................................9 Server Technology...........................................................................................................9 User/Password/Role Database........................................................................................9 WMS Server List and Authorization Privileges...............................................................10 Logging / Accounting.....................................................................................................12 Conclusion...................................................................................................................12

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

2/12

Secure WMS

Secure WMS Documentation White Paper 1 Introduction

OpenGIS Web Map Service (WMS) implementation specification does not currently cover security aspects to control access to data based on layers, attribute or geometry criteria. Some vendors have implemented access control but it doesn't usually work with plain WMS client. This white paper presents a software solution to control access to WMS data, which works transparently with any existing WMS compliant client, with a SSL tunneling system between server and client. While other approaches exist for securing WMS, this one has the following advantages:

Based on standards from OGC for WMS or HTTP. No proprietary protocol is used. Fine granularity for access control (filtering at the layer level for instance).

Concepts
This schema shows the traditional WMS usage. The user is using a WMS client application and accesses a publicly available WMS server.

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

3/12

Secure WMS Users are anonymous (only their IP address can be known), and can access the whole WMS service unrestricted. The communication between the client and the server is not encrypted, so that the content could be eavesdropped. The following schema shows the secure WMS solution:

This schema is similar to the previous one, but users are not anonymous any more. This enables the server to limit access to the service according to the identified user. The yellow boxes show the components of the secure WMS framework. They are separated into two parts: 1. Client side This component acts as a proxy between the WMS client and the secured WMS server. It is able to encrypt the communication channel and authenticate the user using a login and password. On Bob's computer, this component is not used. This is because Bob's WMS client is able to do the encryption and authentication itself, without needing the Client component. This is possible because Standards are used to manage encryption and Authentication:

Standard SSL protocol is used for encryption. HTTP Basic Authentication is used to send the user credentials.

2. Server side The server secure WMS component sits between the secure WMS client and the normal server WMS service. It will perform the following tasks:

Decrypt the encrypted SSL stream. 4/12

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

Secure WMS

Authenticate the users according to the user database. Handle resources restriction according to the user credentials and the policy file. Logging of requests.

The server component will forward the modified requests to the unsecured WMS service, and filter back the response before sending it encrypted to the client. Each of these tasks are described in bigger details later.

2.1 Other approaches and comparison

GDI NRW WAS/WSS/WSC Other efforts exist for secure WMS. For instance, the Geodata Infrastructure NorthRhine Westfalia initiative defined specifications that encapsulates OGC services to add authentication and security. These specifications (WSS, WAS and WSC) aren't OGC standards and provide a distributed architecture for for authentication. The next schema shows the architecture composed of the following parts:

WSS server component which translates the encapsulated request into a WMS request. WAS server component to handle authentication tickets using OASIS SAML specification. WSC client component which requests authentication from WAS and encapsulates the requests to the WSS service.

WMS Server

WMS Server

WSS

WAS

WSS

WSC

WSS aware WMS Client

WMS Client

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

5/12

Secure WMS

This approach is similar to the secure WMS solution proposed here. However, protocols involved are not yet standardized and the architecture is more complex to implement as it uses more services. Proprietary solutions Other proprietary solutions are available on the market. These solutions often require a specific WMS server and WMS client software that implement the defined authenticated communication protocol. The secure WMS solution proposed here differentiate from such approaches by being vendor neutral relying on open standards.

Communication Protocol
The following schema shows the communication channel between the secure WMS client and server.

SSL

Client

HTTP BasicHTTPAuth+WMSProtocol

Server

The communication is encrypted between the client and the server using SSL (also known as Transport Layer Security). This protocol ensures that the connection is secure, offering the following guarantees:

Nobody is capable of decrypting what is being transfered between the client and the server. This makes the users credential and WMS requests and response invisible to somebody intercepting the connection. Using certificates, attacks of type Man in the Middle can be prevented 1.

Inside the SSL layer, the HTTP protocol is used. This is what is used in the non secured standard WMS exchange. Inside the HTTP exchange, the user credentials are sent using the Basic Authentication specification. This type of authentication transmits the credentials in clear text, which is not an issue because they are encrypted inside SSL and thus not
1 This is true only if the client verifies that the certificate is signed by a trusted third party (a certificate authority for instance). The current client version does not check the certificate authority for easier deployment.

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

6/12

Secure WMS visible to third parties.

Client secure WMS application

The client is implemented in Java, using the Java Web Start technology. This technology fulfills the following goals:

Lightweight size and easy to download from a Web Page. Installation is easy, a shortcut can be made on the user's desktop. Because it is Java based, it can run on common operating systems, like Windows, Macintosh or Linux.

Before running this client application, you have to Install a Java virtual machine. Java software can be installed by visiting http://www.java.com. The client was developed to be easy to use by non experimented users. It shouldn't require a lot of training to use. The client may be used either with the graphical user interface or in command line modus. The client works either directly connected to the internet or behind a proxy. The following picture shows the main client window:

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

7/12

Secure WMS

The user can enter its credentials and the secured WMS server address and click connect. A proxy server can be configured in the dialog opened when the Proxy button is pressed. The client will run a tiny local HTTP server. The opened HTTP address can then be used directly in any non secured WMS client. Technologies used in the Java application:

Java Web Start Jakarta Commons HttpClient library for HTTP, SSL and Basic authentication Swing Java GUI

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

8/12

Secure WMS

Server component
The following schema shows the server software architecture:

The visible features are described in the next sections:

5.1 Server Technology

The server application is developed as a Java Servlet application. The servlet architecture has the advantage to be a standard, which several server software implements. This means the application can run on any Servlet compliant containers. In the documentation and the examples, the Tomcat Servlet container is used. Tomcat is very widespread and fully implements the Serlvet standard.

5.2 User/Password/Role Database

The data model is based on the common Java User/Password/Role semantic. A user can belong to zero or more roles. The authorizations are then specified using roles instead of user names. This allows adding a user to a role without changing the policy file. The Servlet specification offers a storage neutral interface for storing the User/Password/Role information. In the implementation, this storage is possible through two different options: 1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

9/12

Secure WMS 1) Container specific storage: When using Tomcat, this database is stored in the conf/tomcatusers.xmlconfiguration file, and looks like:
<?xmlversion='1.0'encoding='utf8'?> <tomcatusers> <rolerolename="role2"/> <rolerolename="tomcat"/> <rolerolename="role1"/> <rolerolename="role_bob"/> <rolerolename="role_alice"/> <userusername="alice"password="alice" roles="tomcat,role1,role_alice"/> <userusername="tomcat"password="tomcat"roles="tomcat"/> <userusername="role1"password="tomcat"roles="role1"/> <userusername="both"password="tomcat"roles="tomcat,role1"/> <userusername="bob"password="bob"roles="tomcat,role2,role_bob"/> </tomcatusers>

2) DBF File: The database can be stored inside a .DBF file. This can be useful if your application is already able to export this database in this format for interoperability.

5.3 WMS Server List and Authorization Privileges

The Authentication is performed by Tomcat, to restrict which roles can access a given WMS service. The authorization policies can be defined for each service with a fine granularity. The policies are declared in XML documents, and the filtering implementation is based on the Deegree Java library. This library has been modified to add more capabilities to the filtering and role management. The following parameters can be used for the filtering:

BBOX restriction: If a role matches the given BBOX restriction the response will be denied if the requested BBOX is outside of the restricted area (it is also possible to deny the response only if the requested BBOX is completely outside of the limited BBOX).

Layer restrictions: These restrictions can define what role is allowed to access a set of layers, and what layer is made available by the WMS service.

Map size: This can restricts the maximum requested map size image. Maximum feature count (used in GetFeatureInfo): The maximum amount of returned objects can be limited Format restriction:

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

10/12

Secure WMS Only allow a given set of formats Here is an example of policy restriction document: <?xmlversion="1.0"encoding="UTF8"?> <OWSPolicyservice="WMS" xmlns="http://www.deegree.org/security"> <Security></Security> <Requests> <GetMap> <PreConditions> <Parametername="bbox"> <Value>93,25,66,53,EPSG:4326</Value> </Parameter> </PreConditions> <PostConditions> </PostConditions> </GetMap> <GetFeatureInfo> </GetFeatureInfo> <GetCapabilities> <PreConditions> </PreConditions> <PostConditions> <Parametername="layers"> <!IMPORTANT:ordermatters. Firstmatchedoneistaken> <Rolename="role1"> <Any/> </Role> <Rolename="$default$"> <Value>tiger:giant_polygon</Value> <Value>topp:tasmania_cities</Value> </Role> </Parameter> </PostConditions> </GetCapabilities> <GetLegendGraphic> </GetLegendGraphic> </Requests> </OWSPolicy> In this example, the BBOX is restricted, and only the role role1 can access all layers. Other roles will be restricted to the layers tiger:giant_polygon and topp:tasmania_cities .

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

11/12

Secure WMS

5.4 Logging / Accounting

The server implementation logs all the requests made to the service, with the user identifiers. The logging format chosen is CSV, similar to what is used in the Apache Web server or in other daemons. This format is simply enough so that a parser can be implemented in most languages in a few lines. This accounting information can be used to build statistical analysis of the service, or can be used for billing purposes.

Conclusion
The Secure WMS Framework makes it possible to add security over existing WMS services and WMS clients. Its architecture is modular, and was designed to be extensible to other OGC services or protocols. All information can be found on the Project Website, with detailed documentation for the client component or the server component.

1.1 / 23.04.2008 /
2008 camptocamp SA / whitepaper_documentation_v1.1.odt

12/12