deegree3 Security Subsystem Documentation

1. User Rights Management

1.1. Preface

The user rights management is handled similarly with each deegree3 web service. The following chapters each focus on a different service, describing the details and some distinctive features. The structure is more or less the same for all of them, so a more general inrtoduction shall be given here.

The table in each chapter rudimentarily explains the implemented user rights. The example shows three users with access to different operations for the different services. There are two main columns (User and Request).

User columns: The first user column (Authentication) contains the username and her password. The second and third column encapsulate the information on whether the username/password were provided correctly (marked as green checkmarks) or with errors (marked as a red cross) which implicitly covers wrong input as well as no input at all.
Request columns: indicate the activated user rights settings for the different available service requests and users.

Each user providing the correct username and password combination will get access to her requestable operations. If the user enters the correct username but a wrong password then there is no possiblity to get access to the data. In this case it doesn't matter if a wrong or no password were provided. In case the user sends a wrong or no username, the user can send a correct, wrong or no password. Either way there will be no access to the data.

User credentials: (user name, password)

• User1, pass1
• User2, pass2
• User3, pass3

The user has three trys to authenticate to the service. If the third try doesn't fit with the stored credentials then she will get a HTTP 403 FORBIDDEN message as response.
For better readability in the tables the response code HTTP 200 OK is marked as OK and HTTP 403 FORBIDDEN is marked with a minus (-).

1.2. WMS with Basic Authentication

This is an implementation that integrates security aspects into a Web Map Service. The implementation is explained on the basis of an example.

The picture below displays the example after a successful authorisation. This is integrated into a common OpenLayers client where you can see the orientation bar on the left side and on the right side there is the layer navigation. The datasets are taken from Haiti which are based on four different administrative boundaries regarding to their granularity. There is also a landform layer provided. For better visability this layer is displayed in blue. The last layer on the map shows the medical facilities (highlighted in green).

• User1 has the ability to request GetCapabilities, GetFeatureInfo and GetMap.

• User2 is allowed to request just one operation (GetFeatureInfo) on the WMS. All other requests will be refused.

• User3 has the right to request all operations implemented in this WMS.

You can reach the example and test the service with the above mentioned user/password combinations.

(In case you are wondering: the DescribeLayer operation has not been implemented yet.)

1.3. CSW with Basic and SOAP Authentication

Because of the unpopularity to request the above mentioned WMS in XML or SOAP there is a Catalogue Service implementated to demonstrate these security mechanism and how it is possible to handle with these kinds of requests.

The picture beneath displays a client with which it is possible to request a CSW in XML or SOAP format and of course in KVP, as well. In the picture there is the XML representation of a describeRecord operation shown. To get the right answer from the server you have to type in the username and password into the fields designed for that.

There are three possible szenarios:

1. KVP request: if you type in the request for GetCapabilities like:
   http://authie.lat-lon.de/csws/services?REQUEST=DescribeRecord&VERSION=2.0.2&SERVICE=CSW&typeName=csw:Record&namespace=xmlns(csw=http://www.opengis.net/cat/csw/2.0.2)
   you have to type in the right credentials to get access, otherwise there will be a HTTP 403 FORBIDDEN response.

2. XML request: in the client there are some request examples provided for testing. In that szenario you have to type in the right credentials into the textfields besides the SEND-button, as the credentials are sent in the http-header.

3. SOAP request: there are some examples already provided in the client. But in contrast to XML the security information can be send in the SOAP-header. If you do so, it doesn't matter what is typed into the textfields. The textfield content will be ignored for SOAP because there are credentials in the SOAP-header already. In this step the credentials are provided in plain text. The response message in case of a fault in the SOAP-request is defined in OASIS specifications. At the moment there is the failed authentication implemented, so you get a SOAPFault-response for that exception.

The table below describes the possibilities for each user.

• The anonymous user (so this is everyone) has the ability to request the capabilities of this service. That means the GetCapabilities operations is free for all.

• User1 has the ability to request DescribeRecord and GetRecordById, additionally.

• User2 is allowed to request just one operation (DescribeRecord) more on the CSW in addition to the GetCapabilities. The other requests will be refused.

• User3 is able to request DescribeRecord, GetRecordById and GetRecords.

• Nobody is able to do a transaction operation.

You can reach the example and test the service with the above mentioned user/password combinations.

---

CategoryDeegree3