WS-PGRADE/gUSE Security - Science Gateways for Distributed Computing Infrastructures - page 82

channel ensures that the communication between the client and the server cannot be
decoded. On the other hand, relying on client-side authentication ensures that only
allowed clients can use the service. For example, in case of WS-PGRADE/gUSE,
the workflow interpreter service (WFI) sends jobs for execution to the DCI Bridge
service. In this case, if the administrator wants to enable job submission through a
secure channel, then the DCI Bridge s services must be made accessible only

through the HTTPS protocol. Additionally, if the gateway administrator wants to
make sure that only the WFI component of the given gateway is able to submit jobs
to the DCI Bridge, then the administrator has to create a client certi

'

cate for
the WFI service, which will be used to authenticate to the DCI Bridge service.
These two steps make sure that the communication channel cannot be intercepted,
and that a given service (the job submission component, DCI Bridge in our
example) can only be used by dedicated clients.
The second rule of thumb of securing service-oriented e-Science gateways is to
make service components publicly available if and only if it is really necessary. For
example, in case of WS-PGRADE/gUSE, the web interface (front-end) is a com-
ponent that has to be made publicly available, but it is not necessary to make the
back-end components (WFI, WFS, DCI Bridge service) publicly available. Of
course, the front-end and back-end components should be able to communicate
with each other. Such a requirement can be ful lled, for example, with the fol-

lowing setup:

All of the gateway services should reside on an internal network, where they can
freely communicate with each other, but they are not necessarily accessible from
a public network.

￿

All of the front-end components should additionally placed onto a network
accessible from a public network as well.

￿

Following this setup, only the components really important for public operation
are publicly available, but they can still communicate with the back-end compo-
nents as well.
Finally, if the e-Science gateway technology is not built on widespread web
servers (for example, Apache), then it is desirable to put it behind one. For example,
WS-PGRADE/gUSE makes use of the Apache Tomcat servlet container, which is
connected to an Apache web server using AJP [AJP]. This setup enables use of the
web server ' s features while con guring the WS-PGRADE/gUSE access. For

example, host certi cates can simply be added to the front-end service.

An important example for the need of securing the services is the storage
component of WS-PGRADE/gUSE. This service is used by other components to
up- and download files belonging to workflows. However, the storage service

'

doesn le

path to upload or download. This means that, if the storage service is publicly
available, then everyone in the world can fetch or modify data stored on the
gateway, which the Storage service has access to. Thus, it is recommended to close
access to this service. However, in case of accessing cloud services directly
(Chap. 4 ) or BOINC-based desktop grids, access to the storage service from the

t make use of any authentication, and enables the client to specify the