This section describes what the requirements are to setup a secure web service.

To start with the good news - if you already familiar with developing BioMoby web services (and if not I advise you to have a look here) you can keep this knowledge as basically nothing will change !

This tutorial will now explain step by step how to realize the two aspects of security as mentioned above.

1. SSL - save data transfer

To have a save data transport you need to setup your webserver to be able to process HTTPS requests. This tutorial will not explain at all how to setup your webserver to work with SSL, as this depends heavily on the type of webserver and which version you are using. To do so please have a look at your webserver documentation and/or contact your system administrator.

In the case that you have also the servlet container/application server visible to the public and use it as direct access to your web services, you need to setup the servlet container to handle SSL connections. Again please see the documentation of the application server/servlet container and/or contact your system administrator.

 2. Access control

This section now focuses how to enable your system that the servlet container / application server provides the access control. 

Before we start we like to clear things first:

"Authentication is any process by which you verify that someone is who they claim they are. This usually involves a username and a password, but can include any other method of demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints. Authentication is equivalent to showing your drivers license at the ticket counter at the airport." (source).

Often authentication is falsely equates with authorization, but:

"Authorization is finding out if the person, once identified, is permitted to have the resource. This is usually determined by finding out if that person is a part of a particular group, if that person has paid admission, or has a particular level of security clearance. Authorization is equivalent to checking the guest list at an exclusive party, or checking for your ticket when you go to the opera." (source).

So to access a restricted resource you need to identify yourself (authentication) and then the system checks whether you are allowed to enter (authorization).

Finally we can see what access control is:

"[...]access control is a much more general way of talking about controlling access to a web resource. Access can be granted or denied based on a wide variety of criteria, such as the network address of the client, the time of day, the phase of the moon, or the browser which the visitor is using. Access control is analogous to locking the gate at closing time, or only letting people onto the ride who are more than 48 inches tall - it's controlling entrance by some arbitrary condition which may or may not have anything to do with the attributes of the particular visitor." (source).

But that's enough theory for now - lets see it in real ...

2.1 Tomcat

Find out how to setup the access control in Tomcat.

2.2. JBoss

Find out how to setup the access control in JBoss.

3. Secure web service implementation

3.1. Implementation

As mentioned before the implementation step is identical to the one if you are implementing a non-secure web service. The only difference is that if you register your web service you have to enter of course the https url to the web service.

So e.g. if your web service would normally be located at

http://www.mydomain.com/axis/services/MyWonderfulService

You have to register the service now as

https://www.mydomain.com:PORT/axis/services/MyWonderfulService

where PORT is optional if you have https running on a separate port.

This URL above might not be applicable to your system (depending on the SSL installation and/or if you access your application server / servlet container directly over the internet or only via your web server), but nevertheless the service has to be registered with the correct URL which points to the secure web service.

Everything else is the same as described in the jmoby-step-by-step tutorial.

3.2.Who is calling the web service

In any case you provide a web service which returns different data based on the user who has called the service, you need to know who of the trusted users has actually called your service.

This information can be retrieved in your web service by using the following construct:

String user = getServletRequest().getRemoteUser();

This allows you to distinguish between the users on the web service level and therefore provide different kind or different views of your data.

Have fun playing :)