A Service Oriented Infrastructure to Facilitate Trust in
Collaborative Working
1
1
2
1
Pete Burnap , Alex Gray , John Miles , Omer .F. Rana
1
School of Computer Science, Cardiff University
2
Cardiff School of Engineering, Cardiff University
{p.burnap, w.a.gray, o.f.rana}@cs.cardiff.ac.uk, milesjc@cardiff.ac.uk
Abstract
There is currently a significant interest in the use of a pay-per-use charging model for
using software services. A primary concern for a software or resource owner when
considering this approach to software exposure is security, and in particular – trust. The
resource owner must be confident in the knowledge that users accessing their software
have fine-grained access restrictions applied to them controlling the varying levels of
access to the software a user may be granted. Similarly, a client executing a service on a
remote site must trust the administrator of the site to deliver a timely and accurate result
(and possibly proprietary data sent to the site). Existing Virtual Organisation (VO)
management tools use centralized servers that handle role management, user
authentication and access control, essentially this is the trusted centre of a VO. Resource
owners trust this central server and its manager to allow access to their machines and
resources based on role privileges assigned within the VO. In this paper, it is proposed
that a distributed and automated software management application based on a service
oriented infrastructure would allow software owners to provide a Web Services interface
to their own software, suggesting an alternative and distributed approach to role based
management across organisational boundaries.
1.
Introduction
Existing VO management tools such as the
Community Authorization Service created by the
Globus Alliance [1] and the Virtual Organisation
Management (VOM) Portal developed by the
London e-Science Centre at Imperial College,
London [2], use centralized servers that handle
role management, user authentication, access
control,
resource
communication
and
management are the trusted centre of the VO.
These servers are not necessarily managed by the
resource owners themselves, standard practice is
for the resource owner to grant the VO a predefined set of access privileges according to their
local policy. Subsequently, a VO manager
distributes access rights to VO members based
on their own delegation hierarchy. Resources
and resource owners/managers trust this central
server to allow access to their machines based on
role privileges assigned by the VO manager.
When controlling access to a computational
resource, for instance, it is acceptable to assign a
role to a particular VO and trust the elected
member of that VO to manage and maintain a
central VO management server, assigning roles
and privileges to VO members which control
access to those resources. Then, if a user from a
VO requests access to a resource and has been
granted the required privileges, access will be
allowed to that resource. However, with the
emergence and growing adoption of the Service
Oriented Architecture, and the security
infrastructure that the Grid environment brings
with it, it is becoming common to share
information and methodological processing
using Web services and Grid services in smaller,
dynamically formed VOs. Here, the VOs share
more intricate resources (i.e. proprietary
software) – essentially this requires the extension
from resource sharing to service sharing.
This paper aims to illustrate the need for a
more constrained access procedure for invoking
proprietary software via Web Services interfaces.
This is achieved by developing a distributed and
dynamic resource management application that
will act as a 'gatekeeper' interface to an exposed
Web Service, and allow the owner of the service
to assign access privileges to each of the
methods exposed within the service to individual
users or groups of users, suggesting an
alternative approach to role based management
across organisational boundaries.
In this paper we describe the software
architecture for the proposed system and the
mechanisms involved in enforcing and binding
the suggested infrastructure.
The paper is organised as follows: in Section
2 we discuss the background information and
existing applications that have led to the
identification of the need for an alternative
approach to user management and trust
establishment
in
collaborative
working
environments. Section 3 outlines the software
architecture and system integration mechanisms.
Conclusions and further work follow in Section
4.
2.
Background on user management in
Virtual Organisations and trust issues in
collaborative working
Take an example of a simple survey result
calculating web service. The service may expose
3 methods; getResults(), setResults() and
processResults(). Using standard Web Services
Description Language (WSDL) [3] techniques,
the service requester would have access to all 3
methods but the service provider may not want
users of their service to be able to control the
setResults() method and adjust the result data,
even though they are happy for others to use
their results and do some processing on them
using the other methods. In a situation such as
this, it may be ideal for the service provider to
set access privileges to each method in the
service when instantiating it and only allow
access rights to the methods they wish to be
accessed. The access rights may differ from user
to user for each individual service. This paper
suggests that it is possible to expose such
operations via a Web Service-based wrapper, and
define fine-grained access restrictions to the
existing software allowing partner companies,
suppliers and clients to gain restricted access to
the software. The policy for such restrictions is
completely decided by the software owners
themselves. Most importantly, what this paper
suggests is that it is possible to provide
networked access to intricate levels of computer
code where the code itself is always kept behind
the owners’ firewall on a secure machine code.
2.1 Existing VO Management Approaches
There are numerous efforts to host and
manage VOs, the London e-Science centre
(LeSc) at Imperial College London have
implemented
a
Virtual
Organisation
Management (VOM) [2] portal that “provides
user authentication and authorisation, resource
access control and usage logging services based
on existing web and grid standards”.
They use grid (X.509) security certificates
for user registration and authentication and gridmap files for resource access control. A grid-map
file is a means of mapping the user details
extracted from a security certificate to a local
user role held within a local database. It is held
on the resource server.
This approach is
becoming increasing adopted as a standard
authentication technique for web based
applications.
The LeSc VOM provides these services
through a portal – effectively, a grid service that
is used to download and upload information into
the VOM database. There is indeed, a need for a
GUI to allow administrators to manage users,
however for the purposes of the creation of
dynamic VO it is proposed to remove the need
for a central portal and database. It is the belief
in this work that by having a central portal and
user database, the application is not pure peer-topeer or fully distributed and is easily fallible
should the central server fail, become corrupt, go
off-line or become unavailable for any other
reason. The approach taken by the work
proposed in this document will be to enforce grid
security infrastructure using a distributed service
based approach, where the grid-map file is
relevant for individual users for each single web
service, and is dynamically produced at service
deployment time rather than maintain a single
grid-map file for an entire VO where user roles
are predefined for all VO activity.
Services will be made available from within
the VO by members of the VO who deploy their
own services into the VO environment, with
their own user access control policies to control
access to their services. These access privilege
roles are created and deployed implicitly with no
reliance on extra human set-up tasks. VO
members are then able to access any service that
they have access privileges for.
An advantage of the evolving Web Service
Resource Framework (WSRF) [4] activity also
allows the proposed work to query the service
data at any time or at timed intervals in order to
save and preserve service data to allow reinstantiation of the service and grid-map file
should a service fail, or if the VO wishes to
disband and reconvene with the same VO set-up
at another time. This contributes to making the
proposed architecture fault tolerant and scalable.
The Globus community have built their own
VO management tool using the Globus Toolkit
and Grid Security Infrastructure (GSI).
Community Authorization Services (CAS) [1]
allows resource providers to maintain authority
over their resources without the hassle of day-today policy administration tasks (adding and
deleting users, modifying user privileges)
A CAS server is initiated for an individual
VO, and a community representative will acquire
a GSI credential to represent the community as a
whole and then run a CAS server using that
community identity. Resource providers grant
privileges to the community and verify that the
holder of the community credential represents
that community and that the community’s
policies are compatible with the resource
provider’s own policies. Once a trust relationship
has been established, the resource provider then
grants rights to the community identity using
local mechanisms (e.g grid-map files, file
permissions, disk quotas etc). Using this
approach, the question over the level of trust the
resource provider needs to give to the CAS
representative arises. Initially there is a policy
comparison between the resource provider and
the CAS community to verify that the policies
are compatible. After this point, what is to stop
the CAS administrator changing the policy and
the level of access given to its members? This is
a trust issue, which can be solved by removing
the third party CAS administrator.
PERMIS
[5]
is
an
authorisation
infrastructure that relies on an access control
policy document to define user roles and
privileges and the resources that these are related
to. This policy document is defined by the
resource owner and PERMIS controls access to
resources by making access control decisions
based on this document. Resource owners can
define user roles and assign these roles to users
and can take this a step further and establish
agreements with other service providers, so that
VO members can use the resources of others.
This work intends to use a similar principle
to PERMIS in that a policy defined by the
resource owner will be used to make access
control decisions but will introduce the ability to
allow those policy decisions to be made in realtime and instantaneously affect the access
control policy for a service exposed to a VO by
an individual member/company within the VO
through a visual, easy to use interface.
Shibboleth [6] is slightly different. It is an
information exchange mechanism rather than a
strict access control management tool.
Shibboleth controls access to resources based on
the information supplied by a user about
themselves rather than a unique identity. This
preserves privacy but limits individuality within
VOs. For example, a resource such as an
internal library of research group findings may
only be accessed by a student from Cardiff
University. This means that the user needs only
to verify that they are affiliated with Cardiff
University and does not need to disclose their
individual identity. This information is
embedded in the user’s web browser and sent at
access-request time. The access control can be
scaled up depending on the amount of
information users wish to release about
themselves. The reason that Shibboleth has been
related to this work is that the architecture that
Shibboleth is built on, the single-sign on
capability and the software itself have been
widely accepted and utilised. The software we
are proposing to develop through this research
could be integrated into the Shibboleth
infrastructure to perform a more strict role-based
access control using the single sign on capability.
These existing approaches provide the
motivation and requirement for the alternative
approach that we propose in the following
section of this document.
3.
Software Architecture
Integration Mechanisms
and
System
For coherency reasons, it should be made
clear that throughout this section the word
‘deployed’ is used to refer to the exposing of a
resource/service owner’s service to the rest of the
VO by making available the resource locator of
the service. In the regular web services sense of
the word, the service itself is previously
‘deployed’ into that person’s service hosting
container.
An existing VO hosting environment
extends the capability for a VO member to
invoke the gatekeeper service, which displays an
interface through which the user can provide the
resource locator of the service they intend to
deploy (the resource locator can be located
through a pre-existing web browser interface that
lists all the services deployed on the hosting
server).
From this, the gatekeeper service
sources a list of users in the VO (from the VO
hosting environment) and a list of methods
available in that service (from the web service
description document), and displays this to the
service owner. The user interface is utilised to
select each user from a list of the usernames of
the VO members and set access privileges to
each method in the services. This approach
capitalises on the object-oriented approach,
extracting the methods from a selected web
service or legacy objects (for example a
Java/C++/C# class) and displays each of them to
the resource owner in the user interface.
Once the service is deployed and access
privileges are set, each user in the VO can then
attempt to communicate with the deployed
service via the gatekeeper service interface.
They will use a resource locator made available
by the service owner to make a standard request
for the WSDL of the service. This would
currently be done by adding a suffix to the end of
the locator (a character string “?wsdl”), and the
WSDL would be returned with interface
descriptors for all the methods in the service. In
this system, the request will not be directly to the
web service, but to the gatekeeper service,
together with some additional security
information pertaining to identity (this is where
the Shibboleth work is relevant, and could be
incorporated).
Each time the gatekeeper service is invoked,
it is instantiated as a single service instance.
This has the advantage of giving each gatekeeper
its own service locator, and it is this service
locator that is displayed to each user of the VO
as an interface to the service that has been
deployed into the VO by the service owner. It
also means that each gatekeeper can be
individually controlled, queried, destroyed etc,
without affecting the access control management
other services in the same VO or the same
hosting environment. These are some of the
noted benefits of employing a service-oriented
architecture.
If the user is verified by their security
information and has been given access to the
service, the gatekeeper service will provide a
dynamically created WSDL that contains only
the interfaces to methods that the user has been
given access to.
The user creates client stubs to interact with
the service based of the information in the
WSDL. The users are never actually aware of
the ‘actual’ address of the service they are
interacting with as they only ever contact the
gatekeeper service, this service being the service
endpoint address that the users are given with the
WSDL, effectively masking the ‘real’ address of
the web service it is protecting. The gatekeeper
service routes the requests for service methods to
the web service itself. Users are also unaware
that they may not be accessing all of the
functions available in this service due to the
transparent enforcement of the service owner’s
policy upon requesting the WSDL for the
service. The structure of this approach enforces
trust across inter-operating VOs and removes
some of the worry about the safety of
information across organisational boundaries.
4. Conclusions and Further Work
In this document we have illustrated the
motivation behind the proposed work. At
present, the software itself is in the development
stage but we have outlined the benefits and
advantages to the VO community, and other
resource sharing communities for that matter,
that this architecture and distributed, dynamic
approach will bring. We acknowledge the lack of
actual performance results supplied in this
architectural overview, in the not too distant
future (by winter 2005), we aim to produce a
working prototype.
References
[1] Pearlman, L., et. Al. ed. 2002. A Community
Authorization Service for Group Collaboration Proceedings of the IEEE 3rd International
Workshop on Policies for Distributed Systems
and Networks (POLICY'02) Available at
http://www.globus.org/research/papers/CAS_200
2_Re vised.pdf
[2] Saleem, A. ed. 2004. Using the VOM portal
to manage policy within Globus Toolkit,
Community Authorisation Service & ICENI
resources -Proceedings of the UK e-Science All
Hands Meeting 2004 Nottingham Available at
http://www.allhands.org.uk/proceedings/papers/1
64.pd f
[3] WSDL - Web Services Description Language
(WSDL) Version 1.2, W3C Working Draft 3
March 2003, World Wide Web Consortium.
http://www.w3.org/TR/2003/WD-wsdl1220030303
[4] Information on WSRF -http://www106.ibm.com/developerworks/library/wsresource/
[5]
Information
on
PERMIS
http://sec.isi.salford.ac.uk/permis
[6]
Information
of
Shibboloeth
http://shibboleth.internet2.edu
–