Information Technology Reference
In-Depth Information
End user: this role represents any authenticated user who is going to access
the end user
interface of WS-PGRADE/gUSE (this role is de
ned by
Power user: this role represents any authenticated user, who is going to access
all
the portlets provided by WS-PGRADE/gUSE (this role is de
ned by
WS-PGRADE/gUSE).
The above example roles are the basic set of roles available in a WS-PGRADE/
gUSE-based e-Science gateway. The gateway administrator has the freedom to add
any new roles as necessary.
In the Liferay portlet container used by WS-PGRADE/gUSE, the different
portlets placed on the user interface have a visibility property, which describes the
set of user roles that can actually view, and thus use the portlet. This method offers a
flexible way to set up a single e-Science gateway instance for users with different
roles and even for different scienti
c domains.
For example, let us assume that an e-Science gateway is set up for astrophysi-
cists and biologists. In this case the e-Science gateway administrator can follow
these steps to properly con
gure the gateway for the different communities:
“
”
“
”
1. Two new roles have to be de
.
2. All the portlets for the astrophysicist and biologist communities can be deployed
onto the gateway.
3. The portlets targeting the different science domains should be set up such that
they are only visible for the targeted science domain role (for example, portlets
targeting the astrophysicist community should be visible only for users pos-
sessing the
ned: for example
astro
and
bio
role).
4. Any new users registering to the gateway should have the proper role assigned.
“
astro
”
6.4 Securing the Services
In a publicly available e-Science gateway, securing the services building up the
gateway is an important task of the gateway administrator. If the gateway is based
on a single service (that is, it is not built based on the SOA concept), then securing
the gateway is really simple. However, if the gateway relies on the cooperation of
multiple services (for example, a job submission service or a workflow interpreter
service), then the communications between the different services must also be
secured ensuring that no sensitive data is leaked from the gateway. In this section
we present three best practices that can be followed to make a service-oriented
e-Science gateway secure.
The
first rule of thumb of securing a service-oriented e-Science gateway is to
make the service communicate through a secure channel. For this, the different
interfaces exposed by the services should be accessible only through a secure
protocol, preferably relying on client authentication as well. Making use of a secure
Search WWH ::
Custom Search