This action might not be possible to undo. Are you sure you want to continue?
Dynamic security perimeters for inter-enterprise service integration
I. Djordjevic a,∗,1 , T. Dimitrakos a,1 , N. Romano b , D. Mac Randal c,© , P. Ritrovato b
a Security Research Centre, British Telecom, Adastral Park, Martlesham, Ipswich IP5 3RE, UK b CRMPA, Universit` a di Salerno, DIIMA, via Ponte Don Melillo, Fisciano, 84084, Italy c CCLRC Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire, OX11 0QX, UK
Received 16 November 2005; received in revised form 3 July 2006; accepted 16 September 2006 Available online 21 December 2006 We would like to dedicate this paper to the memory of Damian Mac Randal, who passed away prior to the publication of the paper.
Abstract Levaraging the convergence of Grid and Web services technologies, we anticipate the emergence of new business and scientiﬁc computing paradigms that are based on dynamic Virtual Organisations (VO). These VOs span across organisational boundaries and enable the enactment of collaborative processes that integrate services, resources and knowledge in order to perform tasks that the VO partners could not undertake on their own. Such a dynamic and complex structure opens several challenging problems relating to VO security. In this paper, we summarise a novel architecture supporting Grid-enabled collaboration for the purposes of Application Service Provision. We then focus on the underpinning security architecture that enables the federated management and distributed enforcement of dynamic security perimeters for virtual communities of services, and on resources that span across administrative and enterprise boundaries. We highlight how this architecture, realised in the context of a European research project developing a Grid platform for application serviced provision, addresses the outstanding challenges that underlie the automation of trust and security management in scalable, multi-institutional, and dynamic Virtual Organisations. c 2006 Elsevier B.V. All rights reserved.
Keywords: Access control; Application service provision (ASP); Distributed systems; Grid computing; Information security; Virtual Organisations; Web services
1. Introduction Application Service Provision (ASP) is a business model, originally derived from the idea of using the Internet or other wide area networks to provide online application services on a rental basis — commercially delivering computing as a service. The ASP model takes advantage of several technological breakthroughs that have made it feasible to sell computing as a service rather than a product. The traditional ASP model can be understood as an evolution of outsourcing — clients enjoy the beneﬁt of ofﬂoading complex and expensive IT infrastructure to the ASPs while maintaining control and visibility of the
∗ Corresponding address: British Telecommunications Security Research Centre, pp2a, Rigel House, Adastral Park, IP5 3REIpswich, Suffolk, UK. Tel.: +44 7918192909; fax: +44 1473649546. E-mail address: email@example.com (I. Djordjevic). 1 Editing authors. © Deceased author.
business processes. However, performance, security, reliability and maintenance are still bound by the constraints of solutions originally designed for specialised in-house implementations. More recently, a new form of ASP has emerged (called IBSP — Internet Business Service Provider in ), based on a Business Model that better exploits the wide adoption of the Internet and the Web. The IBSP model focuses on ASPs providing applications that are Internet-enabled by design and network-centric (e.g. being themselves a bundle of loosely coupled Internet-enabled services). IBSPs and Independent Software Vendors (ISV)  target economies of scale, in addition to economies of skill. They run their services in a multi-tenancy model, supporting thousands of customers on a single code basis; they reduce hardware and administration costs by partitioning and distributing resources, while reducing client-side development and maintenance investment by using standard Web technology at the client side interface as well. In parallel to IBSP, utility computing has emerged as a paradigm where shared infrastructure can be provided on
0167-739X/$ - see front matter c 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.future.2006.09.009
I. Djordjevic et al. / Future Generation Computer Systems 23 (2007) 633–657
demand to multiple customers . The business model lets companies pay for IT services as needed, charge customers peruse or by metered use, following an analogy to the “electric company” paradigm: “when usage spikes, so does the bill”. Supporting this charging model requires dynamic allocation of resources and integration of services. Leveraging the convergence of Grid and Web services technologies, we anticipate the emergence of new business and scientiﬁc computing paradigms that are based on dynamic Virtual Organisations (VOs). These VOs span across organisational boundaries and enable the enactment of collaborative processes that integrate services, resources and knowledge in order to perform tasks that the VO partners could not undertake on their own. Such a dynamic and complex structure opens up several challenging problems related to the VO security. (See  for an indicative overview of these challenges.): - collaborating services and resources may be based in different security domains; - on-demand collaboration implies trust has to be established in real time on a P2P basis; - collaborators need protection from other VO members, as well as from outsiders; - the same service or resource may participate in different VOs, and hence different (potentially conﬂicting) security policies may apply; - security conditions for a service or resource may differ throughout the life of the VO; - no centralised administrative point implies a devolved policy management scheme combined with distributed enforcement at a peer level. A suitable architecture must provide a security and trust management infrastructure that meets these requirements. We will introduce the basic elements of such an architecture, the underlying model of which has been analysed in [4,5,11], and gradually explain how it aims to address the above requirements by means of dynamic security perimeters. According to , a security perimeter is deﬁned as “the boundary of the domain (introduced by space or logical architecture of the system) in which security policy or security architecture applies”. Correspondingly (and in a context more applicable to the IBSP and ISV business models), dynamic security perimeters contain communities of agents, services and resources that collaborate in order to enact a business process, and may span across several organisational (security) domains. Each perimeter contains only those network entities that are involved in the enactment of a speciﬁc task at a time. Its lifetime is bound between the initiation and completion of that activity, and its membership may expand or shrink dynamically as the new services and resources are pulled-in and others (which are already in) are released after fulﬁlling their tasks, or are expelled for misbehaving. In the context of each perimeter, a network entity is allowed to perform actions and communicate in accordance with the roles that it may assume, as agreed by the contributing Organisations. The results reported in this paper have been produced in the context of the European projects GRASP (www.eu-grasp.net)
and TrustCoM (www.eu-trustcom.com), and are a part of a novel VO security solution that is currently in an advanced stage of prototype development. The remainder of the paper is structured as follows: in Section 2, we summarise a business motivation and give an overview of a VO ecosystem used for prototyping the security solution presented in this paper. In Section 3, we describe the security models underpinning this security solution, and examine its architecture from various viewpoints: the underlying logical model, the underlying interaction and communication models, the life-cycle model of a “dynamic security perimeter” during the enactment of a collaborative activity, and the enforcement of both message-level security and access control decisions. In Section 4, we describe our experiences with a ﬁrst prototype implementation that has been developed in the context of the EU project GRASP, and provide a more elaborate description of how the security protocol and enforcement mechanisms described in previous sections of the paper have been realised over a.NET based Web/Grid services platform. In Section 5, we review related work and we compare our work with the current “state-of-the-art” of Grid and VO security solutions. In Section 6, we conclude by summarising the main results and plans for future development. 2. Overview of a VO ecosystem for on-demand service composition Before presenting the dynamic security perimeter solution, we provide a brief overview of the environment within which it is realised, focusing only on the services of interest for the purposes of this presentation. For a more comprehensive description of such an environment, including services for service location, orchestration, contract performance monitoring, and accounting, the reader is referred to papers [7,8,10]. The common objectives of the projects from which the security solution presented in this paper has been developed, include: - The design and prototyping of a platform for securing the distribution of an application service in a collaborative execution environment that spans across enterprise boundaries. - Service composition through the orchestration of service instances that are provided by different enterprises — where service composition is realised by enacting a collaborative business process speciﬁcation that encapsulates the application logic. - Discovery of suitable component services on the basis of Quality of Service (QoS) provision requirements (in conjunction with the usual requirements about the service functionality), as captured by means of Service Level Agreement (SLA) templates. - Accounting and billing schemes that follow the service (de-)composition pattern. One of the key architectural elements of the Framework being developed is the distinction between the Application Service delivered to a client and the component services that are combined in order to implement an instance of
NET ). The platform builds on top of existing OGSA (Open Grid Service Architecture) compliant middleware.Locator: pre-ﬁlters results for those HEs that can meet a speciﬁed QoS and SLA. In the rest of this section. it exploits the power of the underlying Web Services and Grid technology (including dynamic deployment of service instances. Service orchestration makes use of the Microsoft BizTalk 2004 server. As these basic building blocks are not sufﬁcient for realising business-oriented Grids. Fig. Accounting/Billing. First. realising the Open Grid Service Infrastructure (OGSI)  (in the GRASP prototype implementation. to support provisioning of application services. 3 A migration of the platform from OGSI towards the Web Service Resource Framework (WSRF) is underway (as a part of our ongoing work). where services and resources can be made available on demand and be shared among different HEs for securely enacting an activity associated with the execution of an application instance. on top of them additional components are provided including: . mapping of monitored data to SLA concepts. load-balancing. 2 shows the high-level architecture of a platform developed in the context of the GRASP project. each of the above subsystems is designed to contribute to the overall security of the applications and HEs. Instantiation and Orchestration of Grid Services provide the foundation for a HE: . Such an environment can be understood as a VO ecosystem. Service Location.I.Application security: securing complete Application Services (multiple component Grid Services on multiple HEs). The latter supports the introduction of a location transparency at a HE level: the actual location of a service instance may change between hosts in the same HE without any noticeable difference from the perspective of their consumers. Each HE can be understood as a single administrative domain. which create instances of security and network management policies for a HE based on conﬁguration settings that have been deﬁned by human administrators.Billing: merging different costing methods and applying pricing algorithms. . . Security. each of which provides one or more Factory services that are able to realise potentially transient service instances consuming resources in that particular Host and contributing to the enactment of a common activity in collaboration with other service instances in the same or different HEs. and message security enforcement) to accommodate the GRASP services. such component service instances are contributed by different Service Providers. and direct communication and conversation between services) in order to actually deliver the overall Application Service. / Future Generation Computer Systems 23 (2007) 633–657 635 that Application Service. During the project. initiates SLA (Service Level Agreement) management and Accounting & Billing services.Orchestration: orchestrates potentially transient Grid services. Each HE has at least one Gateway node that is a primary access point for the services provided within that environment. it was found necessary to develop a number of OGSI extensions (for service destruction and manageability. GRASP high-level overview. including security token services (which automatically create security tokens following pre-deﬁned templates) and policy services. including inclusion and expulsion of component Grid service instances that collectively execute the application. monitoring of services to ensure compliance.Instantiator: selects an appropriate host – with respect to QoS and other relevant pre-set criteria – and invokes the appropriate OGSI Factory(-ies). Fig.Accounting: collection of raw performance/resource data (shared with SLA monitoring). This architecture enables those responsible for a HE to control the operation of. the key functionalities of Location. At the same time. whose security is managed by a dedicated HE administrator (HE-Admin). 1. 1). event-based notiﬁcation. .2 A HE consists of a number of hosts. we summarise the functionality of these building blocks in order to establish a better understanding of . Finally.SLA management: SLA templates used for selecting an appropriate HE. Djordjevic et al. Typically. and interacts with the Security Manager service that is responsible for securing the group of GRASP services executing an Application Service. therefore simplifying the job of building Grid-based Application Services (see Fig. this is OGSI.3 The main GRASP software consists of components for managing Service Level Agreements. handling securely the VO lifetime. and returns the endpoint for the Instantiator to create this service. and gain access to. the services that are deployed on their HE as it is necessary in a commercial environment. . they run on different Hosting Environments (HEs) – which may or may not be owned by these Service Providers – and each HE may consist of several Hosts where the service instances are actually executed. . The basic business functionality that Application and Service Providers require is built into the infrastructure. 2 The concept of a HE-Admin serves effectively as a logical abstraction of a collection of persistent administrative services. Instantiation and Orchestration.
2. We have extended this concept to building dynamic applications out of distributed services in accordance with a service composition ﬂow that is encapsulated in the speciﬁcation of a collaborative business process. and it also forwards the request to other known Service Locators.1. The instantiation subsystem The Service Instantiator is a Grid service that is responsible for handling all requests for instantiating a new service in a HE. In the case of a request for creating a new service.636 I. The orchestrator subsystem As outlined in Section 1. SL. and returns to Service Instantiator a valid reference to this instance (ServiceLocator. such problems would be manifested through a violation of an obligation in an SLA instance for which such countermeasures have been foreseen.g. Notably. the environment within which the security solution presented in this paper has been realised. For the ﬁrst .1. but also persistent Web Services (e. 2. If the service does not yet exist. 2.Some problems during the operation of a composite Application Service instance necessitate that some component services must be either replaced or supported by additional services. It also allows each HE administration to control who can deploy service instances within this HE. the request is intercepted by the Filter service forwarding the request to the Container (performing a SL* to SL mapping). Upon receipt of such a request. The Instantiator generates a modiﬁed SL in order to hide the real reference.1. the IBSP model assumes that applications are built from several distributed components. or these would be default countermeasures for reacting to violations about which no speciﬁc countermeasure has been foreseen in the corresponding SLA instance. and calls the Container to update a table maintaining the mapping between SL and SL* (modiﬁed SL). Such dynamic applications include not only transient Grid service instances. This additional intermediate SL allows the HE administration to replace or move a service instance within the HE in a way that is transparent to the requestor and enables implementing local solutions for load balancing and resource use optimisation without affecting the virtualisation concept. .2. and it may allow reconﬁguration.A new composite Application Service is being set-up. in OGSI terminology). The external reference (SL*) for the new service instance is then returned to the requestor by the Service Instantiator. / Future Generation Computer Systems 23 (2007) 633–657 Fig. The client of the Service Locator can specify the characteristics of needed services including pricing and QoS requirements. Typically. we have assumed that the ASP Provider is one party within a VO ecosystem. A ﬁlter is present at the start of the standard server pipeline in order to elaborate the incoming requests and to forward them to the right process. Ideally. it can also ﬁlter this information depending on its own policy and/or the SLA it has agreed with the requestor. If the service requestor invokes an already existing service instance. the Service Locator queries the Service Directories it has access to for potential Service Providers who can meet these requirements. 2. the Service Instantiator chooses the appropriate factory within the HE and invokes it. GRASP high-level architecture. and the ASP is seeking appropriate component services to integrate. Djordjevic et al. the access rights of the requestor are veriﬁed and the GRASP Service Container is queried if the service already exists. within which several other Service Providers (SP) co-exist. The Factory creates a new service instance. for checking the credibility of a credit card). this requires a service orchestration engine that is capable of orchestrating Web and Grid services in a dynamically changing workﬂow. The locator subsystem The functionality of this subsystem serves two conceptually related objectives: . and they offer advertised services.1. Since the Service Locator also acts as a broker that collects information in response to a request.3. It will then process the responses and respond to the client who made the request with a list of Service Providers who offer services that could be integrated into the composite Application Service at hand.
and for managing dynamic location and instantiation of the Grid service instances that will replace these “proxy” logical references when the process is being enacted. The central idea in the Manageability subsystem is that a controlling a Grid service instance is different from using a Grid service. Such QoS is negotiated between a service provider and a service consumer. Each security enforcement component segregates the service instance from those not involved in the enactment of a given activity. However. which is supported by the HE-Admin of the HEs that contribute service instances to the Group. / Future Generation Computer Systems 23 (2007) 633–657 637 version of our prototype (in the context of the GRASP project). the relationship between the “business” interface of a Grid service and the “management” interface is one of meta-level/object-level. there is an ASP that possesses the application logic captured in a description of a business process. . .g. to control a Grid service also requires using an interface. On the other hand. using Agreement Services. a commercial usage of SOA (Service Oriented Architecture) is closely connected with a demand for assured QoS. at present BPEL and most BPEL compliant workﬂow engines are not capable of handling the on-demand service location and instantiation and the transient nature (lifetime) of Grid service instances. for every grid service running on behalf of a client.1. SPn . accounting (etc.1. WSLA) and a monitoring capability in each HE that allows extensions regarding QoS prediction by implementing native resource utilisation projection/QoS prediction mechanisms in each HE.4. aims to satisfy two apparently contrasting requirements that are indicative of the security challenges that are representative of such VO ecosystems. 2. We are encouraged by the fact that the ﬁrst draft of WS-Agreement introduces a similar approach. traditional BPEL speciﬁcations are provided for the service orchestration. On the one hand. the ASP may require the creation of new instances of the involved grid services (or activate idle ones). support for an external SLA language (e. it is necessary to share a common understanding of which management capabilities are available on a generic grid service instance (these capabilities are the main goal of the management subsystem). We call this shared common understanding a Manageability Model. During the operation phase. and the aggregation effectively permits only controlled interactions within the security perimeter. . In a typical scenario. The security infrastructure The security solution. GRASP uses a combination of workﬂow templates and Web Service proxies for managing the dynamics of Grid service invocation. In particular. SPn ) is within a different HE. This scenario can be reformulated to illustrate an indicative application of the architecture presented in this paper: Each actor (ASP. The SLA subsystem Typically.1. 2. . The management service is a meta-level interface that allows external agents to query and manipulate the managed service instance. each of which is attached to the service instance it protects. we exploit the dynamics of the grid by instantiating an accompanying SLA grid service (which contains and validates a speciﬁc SLA instance to be fulﬁlled by the related grid service instance). Such a security perimeter can be virtualised as an aggregation of security enforcement components. 2. Manageability model In order to achieve monitoring. . we need to segregate the administrative services managing each HE and the rest of its resources from the service instances contributed to the enactment of a speciﬁc collaborative task. the option of stateful Grid services may require a different organisation of workﬂow. In some sense. Furthermore. in order to enact the application instance that is being provided to the ﬁnal user. These speciﬁcations are accompanied by ﬁlled-in templates that offer the required meta-data for automatically enriching the standard BPEL ﬂow controls during workﬂow enactment. based on an extended collection of ﬂow controls. the SLAs have to be supervised on a perservice basis. All Grid service instances created by Factories within a HE come equipped with management interfaces that realise a common Manageability model. in order to integrate them into their application. A SLA aggregator service correlates monitoring and compliance assessment information within a group of related SLAs. However. Regarding negotiation. one can distinguish two general types of such groups that differ in their objectives and the kinds of entities they bring together: . Separate services that need to collaborate during the application’s execution are put together in a Group that spans across multiple HEs. Regarding the fulﬁlment of a single SLA. and orchestrate them according to the business process describing the application logic. the basic architecture considers a Locator capable of supporting service discovery based on SLA templates. using “proxy” logical references where the potentially unknown Grid service instances are to be invoked at enactment time.6. a standard BPEL4WS workﬂow engine has been chosen. To address this. which we elaborate in the rest of this paper. SP1 .I. we need to allow a dynamic establishment of a virtual security perimeter across the group of services and resources that contribute to the enactment of a composite Application Service by performing a collaborative activity across multiple HEs. metering. Each security perimeter is coordinated by a dedicated administrative service. These contain only instances that collaborate for the enactment of a speciﬁc task of the business process describing the application logic. When a new ASP customer asks for execution of an instance of the application.) of functionalities on a grid service instance.5. Such Groups of service instances need to be protected by an agile security perimeter that spans multiple HEs. and is speciﬁed in SLAs. Djordjevic et al. . Firstly. which decides to rent different grid services from a number of Component Service Providers SP1 . An appropriate SLA management system must support the set-up process by allowing an automated negotiation and parsing of SLAs.
The goal of this package is to install GRASP services and conﬁguration tools on each host involved in a HE. simplifying the setup of the HE itself. Fig.e. security policies are controlled centrally . the Host option installs the tool (HostSecurityConﬁguration) to apply security settings to all services on the host (see Section 4. is a trusted certiﬁcate authority.NET. effectively temporarily delegating the control of their assets to that entity. the number of organisations that contribute to the VO is typically small. .Gateway machine: it installs all services that have to be deployed on the Gateway Machine . Hence. These are always distinguishable from the services offered by the HE to virtual collaborations. Deployment considerations The main prerequisites for installing GRASP. Linking the GRASP PKI security infrastructure to an organization’s existing non-X. 3 shows three HEs.Additional components: it installs the Service Locator on the machine In particular.A Service instance group (SIG) that includes the service instances that one or more HEs contribute for enacting a speciﬁc collaborative activity as a part of the execution of an instance of some distributed application service. the success of a speciﬁc joint experiment and/or the advancement of science) and many key assets of the supporting infrastructure are offered by trusted third parties. the Gateway Machine option allows the deployment of the Security Manager service for the HE (HE-Admin) and its related conﬁguration (HESecurityConﬁguration). As an example. GRASP V2. Djordjevic et al. / Future Generation Computer Systems 23 (2007) 633–657 Fig. we have provided an installation package. . generated using Visual Studio 2003. Overview of a Grid application service provision environment with CG and SIG.2. Very often.I3. Instantiator. Although the number of users may be large.509 security infrastructure is possible.0 uses the Microsoft CA provided with .I1. [I2. other than one or more servers with the necessary system software (SQL Server.I4]). 3.NET) installed.g. OGSI. They have worked together in the past. and they are all committed to a common goal (e. 3.509-based CA would be equally acceptable. To simplify the access to the GRASP functionalities.6 for further details).Host: it installs all services that have to be deployed on a generic host . centralised user identity driven security models have been sufﬁcient. they have a strong interest in the overall success of the collaboration.A Core group (CG) that includes all the persistent and temporary administrative and infrastructure support services within a single HE (e.638 I. for enacting two distinct collaborative tasks. but is out of the scope of GRASP. which can be downloaded from the GRASP Web site.I2]. [UA. The dynamic security perimeter architecture Traditional Grid environments emerged in the scientiﬁc domain where simple. the stakeholders in an analysis process of high-energy physics data sets have built a VO in order to ease their collaboration.g. HE-Admin. etc). service instance Factories. The installation package offers the following options: . 2. from the GRASP-SI viewpoint. such as government agencies or funding bodies. each of which has a CG and contributes to one or more SIGs (i. but any X. and they are prepared to accept unconstrained sharing of access to resources amongst the members of the VO and/or to recognise the authority of some trusted entity to set and to enforce VO-wide security policies.
g. .Relationships between VO participants are bound through some form of agreement against which their performance is being assessed. These roles are distinct.digitally signed security tokens can be attached to the message header of the messages exchanged. In the longer term.g. Of course.In our case.Security policy roles aggregating access rights and obligations are deﬁned not only for users but also for service instances.an explicitly referenced context is used to correlate message exchanges into potentially long-lived conversations between services. . . which provides the rules upon which security decisions about controlling the use of its assets are made at run-time. the format of the security token and the way it is attached to the message header follow publicly accessible and standardised proﬁles. the security attributes possessed by each interacting service and the security policies of that HE.service operations are realised via potentially asynchronous message exchanges. the rights and obligations of a service instance are not ﬁxed in its proﬁle but speciﬁc to the context of each collaborative activity that it contributes to. they may offer several different services in the context of the same VO. . etc. Such roles abstract the rights and obligations that have been foreseen for securely enacting the corresponding collaborative activity. By using limited resources.Each HE makes security decisions and enforces security actions based on the speciﬁc security context within which the service-to-service interactions take place.Distinct and possibly independent security contexts are created and managed for the User. and its own (private) security policies about how secure communication (i. All of the above impose a set of new technical requirements that drive the security architecture we present in this paper: .e. supported by a dedicated Group Manager for coordinating interactions between the HE-Admin services when needed (e. insertion or exchange of security tokens and contexts. . and meta-data referring to such contexts is attached to the header of the corresponding messages exchanged. The presence of such a security context deﬁnes a logical Group of service instances that are allowed to interact in order to enact the collaborative activity. a dedicated administrative service.Each organisation deﬁnes its own (typically public) security policy dictating the way that consumers can access the services and resources that this organisation contributes to the VO. . . which build on the approach of the Web Services Architecture where . the VO participants provide services that are integrated on demand into a custom-made solution. which are provided by the HE infrastructure and administered by the HE-Admin. ASP provider. e. . Security actions are performed by a set of message interceptors. but explicitly associated with the business roles that a service assumes during the enactment of a collaborative activity in the context of executing a composite application service. . / Future Generation Computer Systems 23 (2007) 633–657 639 and the sharing models are very basic. Djordjevic et al.Remote Procedure Calls (RPC) encapsulate operation calls as meta-data in the bodies of messages exchanged between service instances. is created for coordinating the distribution of the security context that is associated with this Group. . intermediaries may perform actions on the message parts that are made available to them including the inspection. Consequently.). or to operate on limited resources without violating agreements of greater importance). called a Group Manager. It also deﬁnes its own (typically private) security policy. which encapsulate the role(s) that a service instance may assume within that security context.g. the main interest of each organisation that persists across its participation in VOs is to optimise its own utility. and . However. The Group Manager also coordinates the distribution of commonly recognised security attributes.The membership and security attribute distributions in such a Group may change dynamically during the enactment of a collaborative activity. . updating Group membership. . policy decisions and policy enforcement points. for validating of security claims. . depending on the state of this activity. transport-level and message-level security) is enforced and how access is controlled. . security policy decision making or the enforcement of security related actions. we have observed the following fundamental differences. and/or offer the same service to several VOs. these policies need to be consistent with the agreements that constrain the relationships between VO members.a message path with multiple hops via different intermediaries can be pre-deﬁned. . a distinct security context is created to enable interactions amongst the participating service instances.Each HE has its own (public) security policies about how the services it hosts can be accessed.different parts of a single message can be selectively secured for different recipients (using standardised XML encryption and digital signature techniques).For each such Group.For each collaborative activity that contributes to the execution of a composite application. Service Provider and the HE. which are more relevant to applications of Grid computing for Enterprise integration in a commercial context.Communication is secured based on the widely accepted (WS-∗ ) industry standards for web services. . an organisation may intentionally violate an agreement and suffer the penalties deﬁned for such a violation in order to serve its own business objective (e. no access/full access or access based on the rights of the user account on behalf of which a task is performed. Compared to the above.I.. The environment presented in this paper is addressing a different set of requirements.The application speciﬁc service instances deployed in a HE are not directly involved in actions relating to the distribution of security contexts. message exchanges among service instances are enabled only if such a security context is present. revoking security attributes. and they may change depending on the state of that activity. to maximise proﬁt.
managing the membership in a (potentially dynamic) Group. and the key-pair itself may be used for encrypting or signing parts of the messages it may exchange. a SAML HE registration assertion or a Public Key Certiﬁcate — PKC. subject to the security policy of the HE. Logical structure of the architecture As we have mentioned in Section 2. in which case they provide the dedicated functionality for managing a speciﬁc SIG.4. which has been extended by building on off-the-shelf implementations of WS-* security standards. These are always distinguishable from the services offered by the HE to virtual collaborations. etc). In particular. Group Managers can either manage a Core Group for a HE. These may include a request from one HE-Admin to validate claims signed by another HE-Admin. . or privileged HEs may have implemented a SIG Manager Factory pattern for dynamically instantiating a grid service that may act as a SIG Manager.g. At a Group-peer’s initial setup. Administering the actual enforcement of security policies is. . we have selectively combined aspects of group-oriented and attribute/role-based approaches. expand. This is presented whenever basic authentication of a peer is required. in which case they are HE-Admins. or across multiple HEs.2. we have built on implementations of WS-Addressing for (re)directing messages via multiple intermediary way-points. Such organisational roles deﬁne the default security settings (e. and for issuing and distributing security tokens that specify the privileges of each Group Member as commonly recognised security attributes. broadcasting updates and/or revocation of Group membership and/or of a Group Member’s privileges. 4.a peer-to-peer model for secure interaction among service instances that share a common security context.a coordination mechanism for deﬁning and distributing a security context that underpins all service–service interactions and deﬁnes a logical grouping of services within a single. In Section 3. In particular. Peers are the service/resource instances within a HE that are either supporting or contributing to the enactment of a collaborative activity. The rest of this section is structured as follows: In Section 3. (In particular. HE administrators (HE-Admins) are responsible for the population of Peers within a HE. We also distinguish several service types and interaction modes that we elaborate in the following paragraphs. and how messages are routed in order to secure end-to-end interactions between service instances. . We have further extended these by implementing our own coordination protocol for distributing security contexts and coordinating interactions between HE-Admin services to support the operation and life-cycle management of Groups of managed instances. HE-Admin assigns each peer to one or more organisational roles and provides it with security tokens proving that it can assume these roles. we distinguish two general types of service Group that differ in their objectives and the kind of entities they bring together: 4 WS-Trust currently supports tokens that include claims in the form of SAML assertions or X509 attribute certiﬁcates. and controls the enforcement of any security policy on any member of the Peer population for which it is responsible. HE-Admin.g.g. or manage a Service Instance Group (SIG Manager). Group Managers are responsible for activating and distributing the security context that underpins all message exchanges within a Group. . etc.) SIG Managers also coordinate the interactions between HE-Admins that is necessary for federating their security domains in order to accommodate the operation of the SIG. service instance Factories. WS-Security and WSSecureConversation for establishing conversations between services.640 I. we focus on the underlying interaction and communication models that explain which message exchange patterns are allowed. and how these contribute to protecting a service instance Group that spans across the HEs as a whole. and mechanisms for policy-driven security enforcement and ﬁner-grained access control with very limited human intervention. however.1. and their lifetime is bound to the life-time of the SIGs they manage. and based our solution on an integration of the following architectural elements: .1. not a . In Section 3. WS-Trust for issuing and validating security tokens4 and for attaching a security context to (g)SOAP messages. . and have summarised in Fig.6 and shown in Fig. selected HE-Admins may be authorised to assume temporarily the SIGM Manager role. described in Section 4 of this paper.a master–slave model for making security decisions and enforcing actions within a single HE. Instantiator. shrink and dissolve during the enactment of a collaborative activity. secure communication settings) of a peer and are bound to the administrative domain of its HE. 2. we focus on the lifecycle model of each Group of service instances that offers a dynamic view on how Groups of service instances are created. / Future Generation Computer Systems 23 (2007) 633–657 In order to meet these technical requirements.) as its proof of registration with the overall ecosystem.A Service Instance Group (SIG) that includes the service instances that several HEs contribute for enacting a speciﬁc collaborative activity as a part of the execution of an instance of some distributed application service. Djordjevic et al. In Section 3. and maintaining Certiﬁcate Revocation Lists (CRLs) when this is necessary.a federated community management model for relating the security domains of each HE.A Core Group (CG) that includes all the persistent and temporary administrative and infrastructure support services within a single HE (e.3. PERMIS  has been used for producing a “third party” policy decision point for access control within each HE. 3. by leveraging an OGSI compliant Grid infrastructure. we focus on the logical model of the security architecture that offers a static view of the main functionalities and their distribution. default authorisations. they are not necessarily recognised outside that HE. Each peer possesses an authentication security token (e.1. we focus on the enforcement model that explains how each HE enforces security actions for protecting the services it hosts. A HE-Admin sets the default security conﬁguration. These have been realised in the current prototype implementation.
Becoming a Group Member requires agreement from both its HE-Admin and the corresponding Group Manager (which assumes that the Group has been activated).I. and it must deﬁne the terms of SIG expansion. Djordjevic et al. This is performed by the corresponding HE-Admin of the contributing HE. 3. it ﬁrst needs to become a Group Member of a Group. 4 illustrates three main types of interactions that may be allowed: . This assignment is done by the SIG Manager.2. who has the control over the security enforcement agents within their HE. the message sender is required to embed different kinds of security context references and security tokens in the message. while having a “logical” role as Group Members. Interactions between administrative services (i. and (a Group) is created to include the services that contribute to the enactment of that activity. an agreement among the administrative entities needs to precede a group activation creation. Therefore. as we explain in the following section. Such a structure facilitates trust establishment in the environment. This is typically realised by the HE-Admin countersigning the tokens issued by SIG Managers for SIG Members that reside on its HE. In order for a Peer to interact with other Peers. which also contains those Peers. This . Group membership is realised by the provision to the Group Member of a security token that is issued and signed by the Group Manager and endorsed (countersigned) by the Peer’s HE-Admin. and only for message exchanges deﬁning interactions in the context of this SIG. Interaction and communication models By default. without the Group Manager’s mediation. it can interact directly with other Group Members. HE-Admin and Group Managers) support the creation of Groups. In addition to possessing security tokens to prove the organisational role that they may assume within their HE. a Peer can interact only with its own HE-Admin services. These roles are not necessarily recognised in any other SIG or in relation to different collaborative activities. more longterm security realm. On the other hand. shrinkage and dissolution. Group Members are informed of each others’ (logical) identity and location and their interactions are realised by means of (typically SOAP) message exchanges that carry a reference to a security context that is speciﬁc to the Group within which the interaction may take place. / Future Generation Computer Systems 23 (2007) 633–657 641 Fig. but overlapping administrative/security realms: HE-Admins and their (group) peers represent an administrative. which corresponds to an organisation offering speciﬁc set of services. The architecture itself introduces two logically different.e. SIG Managers and their SIG Members represent a more dynamic security realm that is formed for the purpose of enacting a collaborative activity. each SIG Member is assigned to one or more collaboration roles for each SIG in which it participates. Main roles and interactions of the dynamic security perimeters architecture. Fig. who issues a security token for the SIG Member as a proof that a member can assume that role in interactions with other members of that Group. Depending on the purpose of each interaction. The SIG Manager oversees the fulﬁlment of such an agreement. In order to perform and successful coordinate security enforcement. and in particular the administration of SIGs across multiple HEs. Once a Peer becomes a Group Member. for a SIG Member to possess such a security token legitimately.me2me (member-to-member): This is used for enabling direct communication between Group Members. The collaboration roles referenced in the tokens issued by a SIG Manager are bound to the SIG that it manages: these security tokens are recognised and can be endorsed only by the HEs that contribute to this SIG. the endorsement of its own HE-Admin is required. 4. Group Members are Peers that have joined a speciﬁc Group. part of the SIG Manager’s functionality. in two ways. services “physically” reside in the administrative realm of their HE-Admins. However. A Peer can be a Member of one or more Groups at any given time.
such as full namespace declarations. and not the actual format of the claims. . Messages sent from a Group Manager or an HE-Admin to a Member require the sender’s authentication token (e. 5. Consequently. They require a ma2ma token. We emphasise that the token elements mentioned in Fig. Messages sent from a Group Manager to a Member are always channelled via the Member’s HE-Admin. The ma2ma certiﬁcate references a security context that is shared among the group of HE-Admins of the HEs that contribute Group Members to a SIG. token validation. which was issued by the HE-Admin upon the Peer’s deployment and/or registration with the HE. In addition. and it includes a reference to the security context underpinning the Group’s operation. 5 highlight important segments of information contained in a security token. while binding between tokens assists traceability and orderly revocation (once a token is revoked or invalidated. which is issued by the Group Manager and endorsed by the sender’s HEAdmin. They are used to support group communication and to offer security attributes as inputs for requesting the authorisation of Group Members’ actions within the domain of a Group. There may be tokens containing several security attributes for each group member. which was issued by the Group Manager and endorsed by the Member’s HEAdmin upon joining a Group. are omitted for clarity. PKC).). 5 provides an example where an embedded X509 certiﬁcate is used. etc. For further details on how this can be achieved.me2ma (member-to-manager): This is used for enabling interactions between a Group Member and its HE-Admin or Group Manager about Group management (e.g. some details. and therefore allows for the realisation of multiple member/manager layers. set in a similar fashion as a Group token for a service. different types of PKI attribute certiﬁcate. etc.g.642 I. Example of a message header with embedded X509 PKC.). Messages sent from a Group Member to its Group Manager are always channelled via its HE-Admin and require the Member’s Group registration token. requires a (unique) Group token. Messages sent from a Peer to its HE-Admin require the Peer’s HE registration token (e.ma2ma (manager-to-manager): This is used for enabling direct communication between managers (including Group Managers and the HE-Admin) about security management (e. security context and token distribution. together with the privileges/roles . The security protocol described in the following section accommodates the possession of such external certiﬁcates by the administrative services involved in SIG management. Djordjevic et al. but only reference to a group (for authentication purposes). PKC). the reader is referred to . the “security tokens” used contain claims that may be realised as different types of Public Key Certiﬁcates. A description of the means for obtaining certiﬁcates for the HE-Admin by a commercial CA is out of the scope of the work presented in this paper. called “basic group token” is used only to include a new member in a group. group membership management etc. Such a token. This model provides the necessary elements for accommodating the creation of speciﬁc Groups dedicated to the management of SIG. Depending on the implementation. However some “out-of band” trust establishment will be needed for the top layer. forwarding Group related security tokens. all other tokens bound to it are revoked or invalidated). other tokens issued for that particular member (in the context of that particular group) contain a reference to the “basic group token”. request to create a new group or join/leave the existing one. SAML assertions. We recommend using commercial PKI Certiﬁcate Authorities for establishing trust at the top level. Fig. credential revocation. The digital signing of tokens supports establishing their authenticity and it is therefore required.g. / Future Generation Computer Systems 23 (2007) 633–657 Fig.g. . Some of these may not contain any speciﬁc privileges/roles.
“global” CRLs are redundant and become an optional tool to assist with “book-keeping”. If any of the claims have been revoked. For Group tokens and privilege tokens. For “registration tokens”. in conjunction with a coordinated Group of services that jointly administer a SIG. and to enable secure communication between a Peer and its HE-Admin. please refer to . Throughout the duration of a member’s participation in a group. only the “basic group token” needs to be revoked in order to break the chain used for the request veriﬁcation process.3. This requires the corresponding management service (HE-Admin or SIG Manager) to broadcast a notiﬁcation to the corresponding Group(s) of administrative services.) Once an authorised request for the creation . validation will fail.e.g. CRL information has to be maintained by the corresponding Group Manager. the Group Manager and the corresponding HE-Admin services of these. service instance). If. 6). 3.2 for more on me2ma tokens. 6. Consequently. depending on the information used for cross-referencing . Group dynamics: Life-cycle model In this section. To simplify the presentation we describe the main interactions following the life cycle model of a SIG (Fig. as regulated by revoking/issuing tokens encapsulating security attributes. by focusing on the basic interactions and security functionalities that underpin its dynamic behaviour. However. Validation includes validating the authenticity of the signatures and verifying the claims with the signatories. however. user agent. (Normally tokens encapsulating security attributes are presented alongside the request to claim the required authorisation/access rights. Maintaining CRLs at Group Manager/HE-Admin level may facilitate this process. of the member. There are several ways to perform binding between certiﬁcates. although it is strongly recommended that a “push” model for distributing Group Membership updates or revocation information is maintained. Set-up: A Peer is registered with the HE where it resides. This token chaining. identity and attribute tokens) is necessary for establishing the relationships between privileges and subjects (i. Snapshot of a SIG lifecycle. and CRL data are pushed by Group Managers to the corresponding HE-Admin as necessary. even if the Group Manager maintains a CRL. i. attributes and public/private key pair) and the non-repudiation mechanism for the owner (i.) Binding between different tokens (e. the HEAdmin services of the Peers that attempt to establish a secure conversation will validate the security tokens presented by these Peers. facilitates group management and contributes to the scalability of the revocation process. Possession of a me2ma token is used to prove that registration has taken place. For a more detailed description of the security protocol supporting these interactions. each HE-Admin can maintain a repository of up-to-date CRL data from all Groups that have an active resident of that HE in their membership. revocation may also happen once a secure conversation has been established.I. we further explain the security perimeter solution presented in this paper. and that those Group Managers ensure that the notiﬁcation has been acknowledged by the other administrative services associated with their SIG. where the “basic group token” is used as an anchor. Djordjevic et al. its role (or particular authorisations) may change. / Future Generation Computer Systems 23 (2007) 633–657 643 Fig. The use of WS-Trust and WS-SecureConversation.e. alleviates the burden of claim revocation: before a secure conversation session is established. Consequently.e. CRL information has to be maintained by the HE-Admin. a member is expelled from (or leaves) the group. (See also Section 3.
These include the request to join a SIG and to obtain the corresponding SIG tokens. Operation: Once a Group is formed. with respect to the HE in which it belongs. Dissolution: This is effectively the departure of the last remaining member of a Group. and highly automated ﬁne-grained attribute/role-based access control to service instance data and operations. and that all actions including method invocations are encapsulated as (meta-)data in the messages exchanged. message. hostile behavior. Dissolution is completed with the destruction/deactivation of the security context associated with the Group and. Group Manager) and a single intermediary (the HE-Admin of the Group Member). In the last two paragraphs of Section 3.) If validation fails. shrinkage entails revocation of the claims attributed to the departing member. Shrinkage occurs when a member leaves a Group. a service instance gets corrupted or exceeds resource limitations. Therefore all legitimate communication between Peer and SIG Manager is channelled via the Peer’s HE-Admin. unavailability. and vice-versa.g. a Group Manager is activated. end-toend message-level security. the Orchestrator — of a privileged HE) is received by a privileged HE that possesses a Group Manager Factory capability. (c) a peer being expelled from the Group. (Once a secure conversation has been established. These interactions are restricted to the Group members only. the message parts containing the request/response and the corresponding tokens are digitally signed by their sender. which may involve optional use of CRLs. etc. and the service instance groups (SIG) in which it participates (peer-SEA). or the Group Manager’s. (b) a peer being forcefully destroyed (e. The Host-SEA virtualises the Hostinstance of a distributed ﬁrewall that protects the whole HE and is administered by the HE-Admin. As with all Group management actions. in the case of a SIG dissolving. Conceptually. and they neither require nor entail any intervention by the Group Manager or HE-Admin. and it is enabled by using me2ma and ma2ma tokens as appropriate: interactions between Peer and Group Manager can be understood as happening within a secure channel with two end-points (Group Member. Inevitably.5 In each case. releasing the resources it occupies. Expansion can be initiated by any Peer wishing to join the SIG. A peer-SEA virtualises the security enforcement capabilities of that Peer with respect to the HE and groups to which it belongs. A security context is then created for that SIG by instantiating a predeﬁned template that contains rules constraining SIG lifetime and management and an “ontology” of commonly recognisable attribute values referring to the roles that can be assumed in the context of this SIG. the destruction/deactivation of the SIG Manager. Dissolution can be requested by an authorised service (e. and may be selectively encrypted. To ensure this.g.2 we explain how this is achieved in our solution and refer to possible extensions. Djordjevic et al. A Security Enforcement Agent (SEA) virtualises the security enforcement mechanisms that are attached to each Host (Network layer) or Peer (Application layer) within a HE . the HEAdmin cannot change the original content of the Peer’s. the message is destroyed and a failure notiﬁcation is sent to the 6 The use of Web/Grid services technology entails that all interactions reduce to message exchanges between peers. Fig. These are again direct interactions between peers at management level. completion of required tasks before the end of its Group membership token lifetime. as well as the introduction of new Group members and the departure or expulsion of existing Group members. application layer enforcement is specialised to the actual service instance.g. a user logs off. this extends the notion of a distributed ﬁrewall  by introducing further layers of control for member authentication. can necessitate interactions between the Group Manager and/or certain HE-Admin services. The HE-Admin is able to endorse/object and forward/reject a request from the Peer to the Group Manager. 7 depicts the security enforcement mechanism implemented for each service: while network/transport layer enforcement is common for the hosting environment (Host SEA).1.4. this step can be omitted. Communication is performed by means of (typically SOAP) messages that may be encrypted with session keys exchanged between SIG members at the beginning of a conversation session. enforcement of Group dissolution can only be initiated and coordinated by the Group Manager. and the corresponding HE-Admins are 5 Possible reasons for expulsion include: underperformance/non-compliance to a SLA. Security enforcement From an architectural perspective. by the Group Manager or by any HE. Validation of security tokens.644 I. . or the expulsion of or destruction request from all remaining Group members. the corresponding security context is identiﬁed and the recipient’s identiﬁer is validated against Group membership records. Legitimate messages must have an embedded a Group certiﬁcate (me2me). For every interaction between Peers. SIG destruction can be requested by the service Orchestrating the enactment of the collaborative activity with which the SIG is associated). 3. it is effectively realised by the corresponding HE-Admin services that have ultimate control over the Security Enforcement Agents (SEA) of each Group member.6 For an outgoing message. direct interactions at the Peer level are permitted only within already established Groups. interactions among the Group Manager and the corresponding HE-Admin services require the use of a ma2ma certiﬁcate. an update of the Group membership is issued by the Group Manager. or by the SIG Manager. changes to security policies.). / Future Generation Computer Systems 23 (2007) 633–657 of a SIG (typically originating from a Core Group member — e. However. notiﬁed. This can be caused by: (a) a peer reaching the end of its operational lifetime and about to be destroyed. As we explained in Section 3. security policy enforcement takes place at each end-point by means of a multilayer shell that effectively protects each Group-peer. the following permessage security checks are performed at a distributed security perimeter instance. By analogy with the interactions between SIG Members. Group Members may engage in direct interactions.
The differentiation between policy speciﬁcation. such as the European Integrated Projects TrustCoM (www. the message content is analysed against the security policies associated with the role and context claimed. Furthermore  indicates how obligation policies that underpin the enforcements of electronic contracts can be deployed through the same enforcement mechanism. These actions are carried out by the peer-SEA in the message-handling chain front-ending the service. so that analysis and correlation can be performed based on evidence/data collected by several interceptors. the packet stream is initially examined by the SEA instance protecting the Host that accommodates the recipient.0.eu-trustcom. we provide an overview of the technology choices underpinning this prototype — which we refer to as GRASP Security Infrastructure (GRASP-SI).com). If compliance fails. Then. and the HE-Admin is notiﬁed. If validation succeeds. For more details on the enforcement architecture as it developed over the years see [3–5]. At the end of this section. Implementation of the security infrastructure The prototyping the security infrastructure described in this paper has so far taken place in the context of the European project GRASP (www. we highlight some limitations of the current prototype and explain how we are addressing them in the abovementioned Integrated Projects. and certain parts of the message may be encrypted or signed. If validation fails.7 If compliance is conﬁrmed. Djordjevic et al.eu-grasp. in the peer-SEA. the appropriate tokens proving the peer security attributes and membership information are attached to the message. Unconstrained production of failure notiﬁcations is vulnerable to Denial-of-Service attacks. whereas a fault is logged and the HE-Admin is notiﬁed in the case of an unauthorised request.I.elegi. Invocations corresponding to authorised actions are realised. The prototype implementation of GRASP-SI described in this section is currently available as GRASP v2. Note that security enforcement on outbound communication protects the recipient HE from such attacks unless messages are sent from a hostile or compromised HE. If validation succeeds. / Future Generation Computer Systems 23 (2007) 633–657 645 Fig. Each intended action (encapsulated by a SOAP-RPC) is checked prior to its execution. policyrelated decision-making and policy enforcement has been a persistent key feature that brings ﬂexibility and scalability. 7. ELeGI (www. For an incoming message. In the rest of this section. which was . Parts of the security models presented in this paper are currently being re-examined and reﬁned in the context of other ongoing projects. 4.net). the message is sent via the SEA (Security Enforcement Agent) instance protecting the sender’s Host. Finally. A third dimension concerns the monitoring of process execution: trusted “monitor interceptors” that are distributed within the message path.mobilegrids.org) and Akogrimo (www. Group Manager. the message is destroyed and the HE-Admin is notiﬁed. then the compliance of the intended action is checked against the security policies associated with the sender’s claims in the speciﬁc security context. Overview of security enforcement activities. functional separation between the SEAs explained in this section. as a part of developing a platform for Grid enabled Application Service Provision. the intended action is replaced by a failure notice.com). The separation between the network and service/application layers of the security perimeter enforcement reﬂects the 7 The conditions and frequencies of such failure notiﬁcations depend on the HE policy. whereby a malperforming Group Member may repeatedly send incorrect or unauthorised requests in order to generate a large number of failure notiﬁcations for its own HE-Admin or the Group Manager. notify their HE-Admin or a trusted third party about events of interest. the context of the corresponding interaction is identiﬁed. and the sender’s certiﬁcate is validated. We also summarise results from the ongoing assessment of this prototype and lessons learned from prototyping GRASPSI. as required by the corresponding security policy.
Net container that manages their state and makes them accessible via SOAP over HTTP requests.Business application distribution and deployment: GRASPSI enables the creation of secure perimeters around cooperating service instances to protect their internal states from unauthorised access coming from services outside the perimeter. To do this. and makes the operations behind these interfaces available to any service. and so on). For example. it manages and coordinates the CoreGroup that includes all administrative and infrastructure support services of an HE. . all GRASP administrative and infrastructure support services (i.UserAgentFactoryService and UserAgentService: The UserAgentService represents a generic client. as well as security enforcement. to be developed via a “components reuse” pattern. However. which services to include. Djordjevic et al.e. unless human administrators wish to monitor or intervene as authorised.Net . the ASP’s HE can grant credentials and create an instance of a User Agent service for that end-user. which offers some basic security features by leveraging the Microsoft Web Service Enhanced (WSE) toolkit . For example. These services and the port types are the key components of the GRASP security infrastructure.eu-grasp. All the service instances running on any host in the HE are administered by the HE-Admin.Net container  released by the University of Virginia. In order to realise the security infrastructure presented in this paper. This mechanism allows reuse of a set of interfaces that group together common functionalities. the services involved in the management of location. all Group management infrastructure is automatically set up and the management of the security perimeters around each Group. as we explained in Section 3.2 and 3. On the top of these portTypes.NET portTypes: . and initially they possess only the authentication and “HE registration” tokens that enable hierarchical interactions with the HE-Admin. The UserAgentService acts as a super proxy: by using dynamic service binding. it exposes a setMe2MaCertiﬁcate interface that is invoked by the HE-Admin in order to deliver the me2ma token to a requestor in its HE. GRASP v2. The latter is deployed in the GRASP environment and acts on behalf of the ASP client. conﬁgured with a client proﬁle and acting on its behalf inside the GRASP VO. Common functionalities and baseline services GRASP-SI has been implemented as a set of Grid services coded in C# and deployed in the OGSI. the following Grid services are created: . SLA monitoring. The services are deployed in an OGSI. preferably by explicitly associating SIG life-cycle management with the BPEL4WS speciﬁcation of the service composition scenario.3 have been combined in two categories represented by the following OGSI. once an end-user is successfully registered with the ASP. Once the conﬁguration is completed. we have used the “portType” mechanism suggested by OGSI. potentially spanning several HEs. Service Instance Groups for each application instance A Service Instance Group (SIG).Group Management — This offers a set of operations for supporting group management. 4. as discussed further in Section 4. Several functionalities of the security protocol described in Sections 3. The persistent service UserAgentFactoryService is used to create a UserAgentService. For every SIG. and is available at www. .3.2. The business application developer has to conﬁgure policy templates and decide about a Group’s lifetime and composition (when to create the group. following the security protocol described in Section 3. SIGManagerService is used for supervising a SIG (i. . 4.e.SIGManagerFactoryService and SIGManagerService: The SIGManagerFactoryService is a persistent Grid service used to create instances of the SIGManagerService.net.End user interface: GRASP v2. upon the HEAdmin service’s request. we had to extend the security features offered by OGSI.1. but don’t allow any message exchanges among the instances in that HE. while GRASP-SI provides the back-end solution for securely distributing and enacting instances of composite application services that integrate on-demand services and resources from several Service Providers and HE. 4. which allows pre-deﬁned patterns of interaction between them for the purposes of supporting the corresponding administrative tasks. The end-user subsequently uses the credentials to authenticate itself to the ASP portal.646 I. / Future Generation Computer Systems 23 (2007) 633–657 released in March 2005. instantiation. . can be handled by GRASP-SI. there is a dedicated SIG manager service instance that is created on-demand. Furthermore. needs to be created for securely enacting a . orchestration.0 addresses. .1.5.0 does not address the security issues concerning the end user-ASP authentication and authorisation schema. the security requirements of an Application Service Provider who wishes to rent resources and to selectively integrate services offered by various service providers in order to provide an instance of an Application Service to its customer.HEAdminService: This is a persistent service that implements HE-Admin functionality described in Section 3. Further to that. it creates the proxy class to invoke the application speciﬁed by the client at runtime. from the following viewpoints. The ASP should implement its own front-end security solution for securing access to its service portal. it deﬁnes the createGroup operation that enables the creation of a generic Group.Group Membership — This deﬁnes a set of operations for managing the Group services membership. security and accounting within a HE) are grouped together within a Core Group.NET and WSE. a Group Manager). Setting-up a HE as a single trust domain A single HE is treated as a single administrative (security) domain. and its requests are mapped onto the User Agent instance.
However.A reference to the identity of the service that grants the token. establish long-running secure conversations. (2) Deﬁne the manager class that enables veriﬁcation of the signature. It simpliﬁes the development and deployment of secure Web services by enabling developers to more easily apply security policy. . and by a dedicated SIGManagerService instance in the case of a SIG. the ASP can provide full anonymity for end users (and could. All service instances that cooperate to deliver an application instance are members of a SIG. a Service Management Group (SMG) is created. / Future Generation Computer Systems 23 (2007) 633–657 647 collaborative activity contributing to the operation of an instance of a composite application service. and uses its private key to sign the me2ma token generated for each service running in the HE. representing a business client — the requester of the Application Service from an ASP.g. The User Agent instance is created by the provider of the Application Service at the client’s registration request. 9 WSE — Web Services Enhancements is a supported add-on to Microsoft Visual Studio . but developers can easily extend the corresponding GRASP port types in order to include other token encodings. with its members including different instances of their services for each different SIG and the corresponding business request. Therefore. for each type of the token (me2me. to the public part of a key-pair associated with that service. retrieve and validate security tokens. then this hostile entity may succeed in producing an authentic token with a false identity proﬁle. if so inclined. WS-Trust and WSSecureConversation. and provides the User Agent with the credentials representing the end-user. The tokens used in the GRASP-SI implementation are codiﬁed using binary mode. two classes are implemented. under the condition that they are responsible to the other participants in the VO for that User Agent’s behaviour. The me2me certiﬁcate is generated by the HE-Admin service in the case of the Core Group of each HE. Therefore. The GRASP system ensures only authorised information ﬂows to the User Agent. and their speciﬁcations are loaded in the WSE via the WSE pipeline conﬁguration. Typically. which we use as an active identity for the service instance and public key data. .An expiration date and an attribute that speciﬁes the token type. accept totally anonymous clients).I. Critical information that contributes to the registration of a new service instance needs to be transferred via a message exchange between the services involved in the creation of this instance and the HE-Admin. and if necessary encrypts/decrypts the message when this token is used. However. Each security token contains: . This is. SMG may have a longer duration. The ASP sets the incoming policy required for accessing the instance. one level up in a hierarchy.8 A distinct component within a SIG is the User Agent (UA). including WS-Security. Of course. and returns the credentials for the end user as registration output. offering an application service. In GRASP-SI.509 certiﬁcate issued by a commercial CA. Its membership includes the SIG group managers and security services (e. which is a member of the same SIG. where service instances can be created on-demand and security management is highly automated. since . 4. speciﬁcations.NET and the Microsoft . ﬁnding a secure and reliable method for producing and distributing me2ma tokens to new service instances has been identiﬁed as a substantial risk. Djordjevic et al. This includes its GridServiceHandler (GSH). me2ma tokens: The me2ma (and optionally the Group basic me2me) token is used as a proof of HE registration (respectively Group membership) and it also binds identity information. Direct communication between services within a SIG is possible only by using a SIG token. me2ma.e. HE Admins) from every Hosting Environment that contribute services to the application’s execution. a SIG is created for delivering an application service to the end user.4. that we have used extensively in this prototype. one application instance). beyond that it is the ASP’s responsibility. This group represents the administration of one application service and manages multiple SIGs corresponding to different application instances. End ASPs are expected to implement their own security services for protecting the information ﬂow between the end-user application (in the GRASP system) and the “physical” end user. the service instance Handle. it is preferable to establish and distribute such tokens using “out-of-band” means. Simultaneously to the above. and describe the token structure. Security tokens GRASP tokens are designed by leveraging the Microsoft WSE9 capabilities. Therefore. if a hostile entity manages to intercept this message exchange and/or to change data about the new public key and service instance handle. and the end user interacts with them via its User Agent instance. Since the ASP authenticates the end user. Now. (HE-Admin or SIGManager). such as which methods can invoke.NET Framework providing developers the latest advanced Web services capabilities to keep pace with the evolving Web services protocol speciﬁcations. which implement various WS-∗ security 8 Note that one SIG would include service instances corresponding to one business request (i. the HE-Admin will be on a different host than the one hosting the new service instance (and the service instance Factory creating it). viz.A unique token reference number — information that is needed in order to identify the service that is legitimately in possession of this token. once an instance of an application service is requested. In order to deﬁne a custom binary security token suitable for usage inside the WSE pipeline. impossible in a GRASP environment. and ma2ma). HE-Admin tokens: Each HE-Admin owns a X. the communication of the SIG members with external entities is prevented. we had to perform the following tasks: (1) Deﬁne a token class that extends the native SecurityToken class of Microsoft WSE. Tokens including the privileges assigned to each SIG member are also distributed. The credentials contain the data to authenticate the client and to validate its requests against a set of privileges (user proﬁle) which specify how the user agent can interact with the application instance. of course.
The creation of a new entry in the per-Host service registry with the Grid service handle and public key information does not require the transfer of any critical data over the wire. the frequency of success of such attacks is relatively low. When a new instance of a me2ma token is created. Upon this. this registry becomes a member of the Core Group of the HE since the initiation of the HE. but the cost of a successful attack can be very high. a new entry in this per-Host registry is introduced. WSE is an engine for applying advanced Web service protocols to SOAP messages. When a new Grid service instance is created. In this approach.Use of per-Host service instance registry: An alternative approach that we have been investigating involves the use of a (private) registry at each Host in a HE. and once the Handle and key-pair for this instance have been produced. with the HE-Admin as an intermediary waypoint in message exchanges.It allows the HE-Admin to authenticate the destination service: The HE-Admin service stores copies of all issued Temporary tokens. it cannot be used again after a me2ma token is provided and the service instance is registered with the HE. candidate’s HE-Admin and Group Manager) can establish a secure conversation between candidate and Group Manager. for a me2me token to be valid the HE-Admin needs to inspect the token and countersign it before the token reaches the candidate. on which we have based our enforcement implementation. either from the Service Instantiator of the HE or from the corresponding Factory of the Host where the service instance has been created. 4.It can be used only once by a service. 8). Security enforcement implementation The security enforcement point is implemented in the GRASP-SI security enforcement pipeline. me2me tokens: The me2me certiﬁcate is generated by the HE-Admin service in the case of Core Group of each HE. The registry stores the public key and GSH data of each service that is active on this Host. Then the Instantiator service passes to the HE-Admin service a reference to the corresponding data entry. we have decided to experiment with the following alternatives: . Provision of this information takes place in the context of a secure conversation between these two services. the public key of the new instance is encrypted using the HE-Admin’s public key for conﬁdentiality. and signed with the service Temporary (“one-shot”) token. since the Grid service Factory and the corresponding registry reside on the same Host. The properties of a Temporary token are: . the Handle can be provided to the HE-Admin service. In the current release of the GRASP prototype.648 I.e. Notably. Finally. For each Host. which contains OGSI. where public key information about all service instances active on this Host at the time is kept. All message exchanges in this scenario are done within secure conversations in a single HE. and it exposes a Web Service interface that allows the HE-Admin to access these data entries. . which will produce the me2ma token. then the public key and the identiﬁer of the new service instance (Handle) need to be delivered securely to the HE-Admin service. the HE-Admin service signs the segment of the SOAP message containing the me2ma token with its X. and by a dedicated SIGManagerService instance in the case of a SIG. each such per-Host registry. we plan to introduce the alternative of using per-Host service instance registries and compare the resiliences of the two approaches. WSE extensibility features are used to create this security enforcement pipeline. First. If the service instantiation is successful.509 private key and encrypts it with the public key of the destination service. and Core Group member services such as the HE Instantiator that are responsible for coordinating the creation of new service instances in each Host. The generation and delivery of me2me basic and attribute tokens do not present any particular challenges because the corresponding services (candidate Group member.Use of “one-shot” token: The public/private key-pair of a service instance is generated at the start-up of the instance. This includes embedding metadata and amending metadata already embedded in the headers of outbound SOAP messages. the private key of the service instance is not disclosed or transferred over the wire at any time.It comes from a pool of temporary tokens built into a HE during the set-up of the environment. WS-Security/SecureConversation and WS-Trust support the token structures and service–service interactions required to support this approach. In future releases. the HE-Admin compares it with its list and matches the Handle of the requestor with the value inside the token. . Djordjevic et al. As a result. In order to assure a secure transfer. . / Future Generation Computer Systems 23 (2007) 633–657 these message exchanges take place within a single HE. include speciﬁcations: .Net and GRASP handlers for SOAP messages (Fig. The most relevant features of WS-* implemented by WSE. the per-Host service registry is one of the infrastructure services of a HE that is installed on each Host when the environment is set-up.Net SOAP pipeline in order to complete the security policy enforcement. When a SOAP message contains a temporary token. and assures the appropriate identity check at the subsequent request of a new service instance. a secure conversation can be set up. After considering a number of potential solutions to this problem. at any time. a new service instance needs to provide a new public key to the HE-Admin in order to obtain the me2ma token and complete the registration. and the input ﬁlters process the headers of the messages and check their validity. we have implemented the “one-shot” token approach. The HE-Admin can then obtain this data by accessing the corresponding registry and produce the me2ma registration token for a new Grid Service instance. between the HE-Admin. i. This functionality is implemented by a pipeline of ﬁlters: the output ﬁlters produce or amend the headers of the messages.5. and we leverage the conﬁgurability of OGSI. as well as processing the metadata embedded in the headers of inbound SOAP messages.
The version of OGSI. we have replaced the last ﬁlter in the OGSI.Net pipeline. We have used this ﬂexibility to provide the OGSI. which forwards the message to the dispatcher of the OGSI container. the Web service method is invoked.Net uses its own mechanism to check the policy assertions of incoming SOAP messages.Net framework with all the necessary support needed to implement the GRASP security model. which is shown in Fig. . uses Microsoft extensibility features to dispatch the SOAP message to the Grid service loaded in its container. (b) OGSI.) In order to resolve this OGSI. The OGSI. which take advantage of a richer set of WSE features and give us more ﬂexibility in controlling security enforcement. could be realized using the WSPolicy implementation of WSE. exploits the conﬁgurability capability of the OGSI. Djordjevic et al.Net SOAP Pipeline) to dispatch SOAP messages to the service instance. If all the checks are successful. . (In fact. The design of our GRASP SOAP pipeline.I.WS-Addressing. . at ASP.509 certiﬁcates and username tokens. as shown in Fig. which then invokes WSE to check security headers in the message. as shown in Fig.Net SOAP Pipeline. the WSE is not able to parse it. This engine uses the basic Web Services SOAP engine provided by Microsoft. to establish a secure context among a set of services.10 This policy validation component can recognise only X. 8(b). An OGSI. We have also modiﬁed the OGSI.NET SOAP pipeline. and an error is sent to the requestor. If this method is successful. 8(c). If security headers include tokens whose type differs from the accepted proﬁles. to reroute SOAP message to a different receiver. 8(a). Although WSE natively supports X.WS-Security.NET pipeline with our own custom ﬁlters. WSE invokes a SOAP method on the Grid service. it is ﬂexible enough to allow the deﬁnition of custom security credentials for signing and encrypting SOAP messages.Net SOAP pipeline. / Future Generation Computer Systems 23 (2007) 633–657 649 Fig. and uses PERMIS to validate the attribute certiﬁcates in the security tokens presented by requestors. as shown in Fig. A ﬁrst ﬁlter is created at IIS level. SOAPMessageHandler. OGSI. or else it is not able to parse the token. to deﬁne and to check the service access policies. Furthermore. (a) Microsoft SOAP pipeline.Net framework provides a custom SOAP engine (OGSI.Net level. which implements all additional features required for the GRASP security protocol. and authorises the requested access. it intercepts the request for a Grid service and redirects it to another custom ﬁlter. which invokes WSE to check the headers included in the message.509 and username/password credentials.WS-Policy. . on whether the incoming SOAP message contains the credentials required to invoke the service. The dispatcher starts SOAP message forwarding through the OGSI.Net design problem. 8. which allowed us to override the SOAPMessageHandler with our own GRASPSOAPMessageHandler. In particular.WS-SecureConversation. 8(c).Net pipeline in order to conﬁgure WSE with the information required for a correct elaboration of GRASP tokens. . this ﬁlter conﬁgures WSE by specifying how GRASP tokens have to be validated when included in the headers of SOAP messages.Net used for GRASP can parse only X. (c) GRASP SOAP pipeline. to authenticate and to validate the security token in the SOAP message.509 and username credentials and conﬁgure the WSE pipeline accordingly. The HTTP request containing the SOAP message is intercepted by the Internet Information Service (IIS) and forwarded to the ASP. This pipeline provides outgoing and incoming enforcement agents. because its SOAP engine does not exploit all the WSE capabilities. 10 The same check.NET pipeline to the last node. GRASPSOAPMessageHandler implements the security enforcement point that runs the GRASP access policy enforcement process.
Group membership: When a message is received. At initial setup. validation takes place in the context of the following two application scenarios: (i) Virtual E-Learning Lab. which have a high computation demand. If this validation is successful. If the incoming message violates these requirements.0 implementation. The HESecurityConﬁguration tool is executed on the Gateway Machine. all the required headers are added to the SOAP message. the Gateway Machine already contains an X. This virtual laboratory enables the simulation of complex real scenarios to assist a student’s learning process. PERMIS can retrieve and apply multiple policies to one authorization request. on which the Technical University of Barcelona. This test is realised by invoking PERMIS. GRASP-SI is being validated as a part of the larger GRASPv2.6. may wish to apply different policies to service access. and the HESecurityConﬁguration tool is used to set policies concerning all Hosts and default Groups within a single HE. Spain. for the requestor role. The Authentication phase generates me2ma certiﬁcates for each persistent service in the HE domain. System performance evaluation The evaluation of GRASP-SI has been performed during the validation phase of the GRASP project. encrypted.Group privileges: The requestor has to provide an attribute certiﬁcate as a proof of credentials to invoke a speciﬁc method on the destination service. the HE-Admin. the group membership credentials of the sender are validated. and the message is encrypted and signed with the correct tokens. Set-up and security conﬁguration For each HE. it is parsed by the incoming enforcement pipeline that runs the following tests: . running on the Gateway Machine. Similarly.509 certiﬁcate issued by a commercial CA. but these policies need to use the same meta-data from the Security Enforcement Point. If the validation is successful. the SIGManager and the service provider. The University and the Computer Centres share heterogeneous resources (hardware capacity. The HostSecurityConﬁguration tool is used to deﬁne local security settings for each service running on the hosts embedded in the HE. and to create a policy template ﬁle with the HE-Admin reference. The administrator deﬁnes the list of the core GRASP services running on the host and the Core Group. they can be executed by a human administrator via an intuitive GUI. The HostSecurityConﬁguration tool has to be run on each host within the HE domain.650 I. the outgoing enforcement pipeline checks if the outgoing communication is allowed. while the Core Group Creation phase creates the GRASP core group to include all the administrative services running in the HE domain. this consists of the role or roles held by the requestor. The solution to this is to use a service-speciﬁc ontology to map such meta-data to the more abstract terms used in different policies. and associated management infrastructure are automatically being set up. by providing the requestor’s identity alongside the claimed role. it is blocked and an error is reported to the requestor. the various stakeholders in the SIG. Symmetrically. otherwise the message is blocked and an error message is sent to the requestor. we offer two administrative tools for conﬁguring the security properties of each HE as a whole. the agent invokes WSE to verify whether the token used to sign the message is correct and if the message can be decrypted. Access control is thus enacted at the role and target method level of granularity. but currently GRASPV2. the public key of which is stored on each Host involved in the HE. etc). triggering the Authentication and the Core Group Creation phases. the requested action is invoked on the service. in the form of the target service and the method being invoked.Authentication and encryption veriﬁcation: Each SOAP request has to be signed and. The tools are designed as graphical executables. The tool also enables the administrator to conﬁgure the enforcement agents for the selected services. and executes similar controls on the incoming enforcement pipeline concerning group membership and credentials. it would be possible to provide other authorisation checks. If successful. Currently. When a large number of students are accessing the VLab service portal.7. Security subsystem evaluation and lessons learned 4. the action can be invoked on the service.1. 4. otherwise it is blocked and an error message is sent to the requestor. . . an instance of the HE-Admin service is deployed as a persistent service. if required. and we simultaneously evaluated its performance.11 At runtime.Authentication and encryption validation: In this phase. In the GRASP V2. on the other 11 Copies of the Policy Template File are distributed at each host in the HE. in the GRASP-SI prototype. It would be relatively straightforward to operate at a ﬁner level of granularity by providing a mapping function from the parameter values provided with the method call to a sub-category of the method — for example to particular sets of record in a database lookup. Finally. The Computer Centres. as evidenced by the attribute certiﬁcate provided and the action being requested. / Future Generation Computer Systems 23 (2007) 633–657 When a SOAP message is received. . piece of software. this ﬁle is ﬁlled with the details concerning the group’s composition and the identity of the manager responsible for each group.7. . forming a Virtual Organisation to provide the VLab service. offers a Virtual Laboratory service in ASP mode to all its Technical Colleges. data. with the access rule given only for the services running on that host. the message is forwarded to next agent in the pipeline. The authorization carried out by the PERMIS Policy Decision Point is based on the data provided by the Security Enforcement Point above. Furthermore. Djordjevic et al. the University cannot cope with the demand and it is not cost effective to invest in expanding this infrastructure as demand widely varies over the academic year.0 has not implemented this feature.0 platform. 4. if the validation is successful.
which allows us to create component services instances at the right moment. When a service is destroyed. the group’s composition is updated. and during the runtime creation of SIGs. where the Ofﬁcial Association of Medical Doctors of Barcelona (COMB) has been offering some administrative services in ASP mode to small Primary Health Centres (CAP).XeonTM CPU 3. including the UA. 2. Performing controlled experiments in both versions of GRASP allowed us to assess the impact of the security prototype implementation on the system. such as a syndication service for buying drugs and medical equipment together in order to optimise the medical expenses and achieve a reduction of CAP costs. Furthermore. as this varies widely depending on the application and on encryption algorithms used. over widely distributed and potentially heterogeneous datasets. or creating several application instances and invoking several methods on each of them. and subsequently COMB is weighing up the possibility of offering new services. Our prototype offers the necessary level of security by protecting message exchanges. which adds a further complication to the analysis. / Future Generation Computer Systems 23 (2007) 633–657 651 hand. and the group is removed. this instance is added to the UA SMG group created during the step (1). at the Core Group creation phase. From the security viewpoint.Numbers of messages exchanged: SOAP messages are generated during all the communications of the preliminary security conﬁguration steps: at the Authentication phase.0 on the same tests.00 GB RAM . resulting in the group reaching the end of its operational lifetime. (3) Business application creation: A Service Instantiator endpoint is selected and the creation of the application instance is started. Djordjevic et al. Historically. Due to this additional management-related message exchange. Security aspects are of special interest in this testbed. The system supports the capability of creating an application instance and invoking several methods on it. we were able to evaluate the performance of the overall system and compare it with the performance of the previous GRASP version (v1. the business application creates a new security perimeter (SIG) and invites all new (successfully created) component service instances.Sizes of messages exchanged: Digitally signing and encrypting a SOAP message adds headers to the message.0). (4) Business application interaction: The end user invokes a method on the application (outer request). and allowing CAPs to control access to their own data while interacting with others within the several secure collaboration groups that are formed in this scenario. the overall number of SOAP messages in GRASP v2. and supports a fairer pay per use charging scheme. running Windows XP Professional and Windows Server 2003 operating systems. This avoids creating services that are idle for a long time before their effective use. we use an on the ﬂy instantiation pattern. all the group tokens are revoked. A new security perimeter (SMG) is created to manage the instance. Each HE engages several hosts with different hardware and software conﬁgurations. Servers with the following speciﬁcations. It has not been possible to produce reliable statistical data about the increases of size of the messages exchanged. allowing for the auditing of the trail of message exchanges.06 GHz. To provide the invocation result. when the need arises. which does not have GRASP-SI integrated.Pentium R 4 CPU 3. After the inner request is dispatched to the component service instance. steps (3) and (4) can iterate inﬁnite number of times. to become members of that group. we provide the infrastructure for creating and deploying a Virtual Organisation consisting of the University and the Computer Centers. . So far.0 increases up to 15% compared to the values obtained for GRASP v1. with testing to uncover critical situations such as the communication between HE-Admin services in different HEs but within the same SIG. where several entities selectively share parts of critical data. The testing involved the following steps: (1) User Agent instance creation: An instance of the User Agent is created and conﬁgured with a client identity. the result is elaborated to create the outer result. . 2. The optimisation cost calculus algorithm cannot be performed over a centrally stored dataset. have between them the available resources to address such demand. On creation. Some important aspects of our ﬁndings are highlighted here: . CAPs have been managed by the Public Health Service (Social Security). (2) Negotiation phase: The client speciﬁes its service requirements and the ASP queries the Service Locator (inside the GRASP VO) for the endpoint reference of a Service Instantiator that can create an application needed to satisfy these requirements. the application sends an inner request to a speciﬁc component service. have been used: . preliminary tests of the infrastructure have involved the conﬁguration of two HEs to check the runtime composition of SIGs that span across different HEs.20 GHz.00 GB RAM . selectively encrypting message content. 1. GRASP-SI addresses the secure aggregation of cooperating services and resources from the different Computer Centers. Before instantiating any component service. In fact. WS-Security and XML encryption allow for the selective encryption of message context. which are public institutions in Spain and have the closest contact with the patient. increasing its size.00 GB RAM All the involved services have been marshalled in the HEs according to the need to stress the infrastructure. A distributed variant of this algorithm has to be implemented instead. which of course may not be available. During these tests. because CAPs are not willing to share or transfer sensitive patient data. and therefore does not implement any security features. but recently the local governments have promoted self-managed CAPs.80 GHz. (ii) Medical Attention Management. The Service Locator may return more than one endpoint reference. In theory. (5) Business application destroy: This step destroys the application instance and all of its component services.I.XeonTM CPU 2. In this scenario.
but was still not optimal. but of course. arising from the use of WSE and the basic security functionalities offered by OGSI. which appears too speciﬁc to the application at hand. The main known issue relates to the trustworthiness of the Administrators (both HE and SIG) at set-up time — for example an Application Provider deliberately subverting the user authentication process for SIG membership. On the other side. This performance penalty is considered acceptable as. On the user side. It has not been possible to obtain reliable estimates on the message elaboration overhead.Service distribution and marshalling: We have also tried to characterise optimal services marshalling on the host in the HEs to improve performance. or strengthened using two factor authentication and/or a Shibboleth-like mechanism. This phase is performed by the human administrator in charge. . and we anticipate an overhead of up to 15% on SOAP message exchanges as a result of the using this security prototype. all the security aspects inside the HE can be comprised. In a setup with one HE containing one host.Net (such as certiﬁcate creation functionality). and the extent to which one is willing to sacriﬁce performance to protect the transport and the integrity of the data in the messages exchanged. This is built on top of the Microsoft .8. Security considerations The initial step in the setup of the GRASP-SI functionality is the conﬁguration of the Hosting Environment (HE).1.NET and WSE platform.3). We expect to continue our research and produce a second generation of such prototypes. so service providers need only worry about the security issues within their applications (for example. taking into account both the principles of distributed systems design. / Future Generation Computer Systems 23 (2007) 633–657 . no further human intervention is required.1). as is the security of the channel between the User Agent and the (human) end-client (see Section 4. based on the tests performed so far. If an unauthorised or malicious administrator runs this step. For both of the above cases.0) carry the requestor’s credentials with the encrypted body. Normally. and thus inherits the strengths.2. These requirements increase the size of the message and its elaboration time. each service has to be hosted on a GRASP-enabled Host and delivered as a Grid Service. the segregation and integrity of different clients’ data). depending on the capabilities of the end user and the consequences of a successful impersonation attack. and the security of all the interactions rely on the correctness of the implementation and design strength of the GRASPSI infrastructure. and is critical for setting up the security environment. 4. Subsequently. if the conﬁdentiality of exchanged messages is not mandatory. When the services engaged in the test are loaded on different Hosts inside the same HE. which (in the GRASP v2. In conclusion. the network communication overhead was modest and the test execution time improved. the elaboration time of SOAP messages is reduced (as this avoids the encryption/decryption tasks). In terms of the security strength of GRASP-SI on the conceptual level. The creation of the User Agent is the responsibility of the ASP provider. it enables sensitive applications in areas such as eHealth and eFinance to beneﬁt from the ASP business model. The actual elaboration overhead has been hard to assess. which will implement most of the features included in the design presented in this paper and take into consideration the results of the evaluation of our current prototype. Limitations of the current prototype and further work GRASP-SI is the ﬁrst prototype that has been developed as a “proof-of-concept” example for the security solution outlined in this paper. we summarise some limitations of the current prototype and present some aspects of our plans for further experimentation in this direction. since varying results are obtained if selective encryption of parts of the message body is applied. and any potential security vulnerabilities. this causes the performance of the GRASP-SI to improve. the ASP would use certiﬁcatebased authentication and SSLs to protect this channel.7. but the execution time was optimal. we conﬁrmed that the security solution is more suitable for securing the enactment of widely distributed applications across several different hosts and in several distinct administrative/security domains. the architecture choices and the security protocols have been challenged throughout the design process. Most of the strength of the GRASP-SI infrastructure rests on the way this basic functionality is used to provide the layered dynamic security perimeter for service collaboration.Message elaboration times: The enforcement agents accept SOAP messages. with all the services up on that host. The GRASP security is implemented in the message handling pipeline before the messages are delivered to the service. The security of that indirection and the authentication of the remote service/application would be the responsibility of the service provider. but the test execution time varied widely depending on the hardware speciﬁcation of the Host. 4. Again. . however. the network communication overhead was higher. The GRASP-SI infrastructure protects the VO enacting the Application Service and the interactions between the participants. as well as the limitations of the technologies and platforms used for prototyping. given the level of security provided. The main goal of this phase is the speciﬁcation of the X.652 I. that of the providers of the speciﬁc services. and any attempt to access other information would be easily detected. the boundary of this protection is the User Agent.509 certiﬁcate identiﬁer that will be accepted by all the services inside the HE. this could be replaced by a simpler username–password mechanism. Djordjevic et al. In this section. However. As an indication. we have observed that the signature validation and the decryption of the message body can generate an overhead of up to 20% CPU time. the service provider could just place a proxy on the GRASP Host and invoke a remote service (or legacy application) elsewhere (see Section 2. because decryption and the credential’s validation are time-consuming tasks. the network communication overhead was optimal. the extent of the damage that a compromised Client/Service could do would be limited to the data that that entity should properly be able to access. When the test involved different HEs.
its enforcement agents are embedded in the OGSI. Securing business process enactment As we explained in Section 4. more recent versions of BPEL4WS and the current WSBPEL standardisation effort within OASIS foresee the segmentation of a BPEL speciﬁcation into scopes. Security policy management The current prototype depends on a loose integration with PERMIS in order to enforce policy decisions by offering a policy enforcement point that can interact with a PERMIS policy decision point.8. and exploring more complex authorization scenarios. the challenge is the referencing and manipulation of resource states without modifying the basic WSA architecture. Furthermore. we are currently working towards providing mechanisms for enforcing obligation policies in a dynamic VO context. Use of security proﬁles Although the current implementation takes advantage of the WS-* speciﬁcations implemented over Microsoft .NET requires modifying security port types according to WSRF. funded by JISC for two years starting from September 2004.0. and enforcement. Service authors create ASP.NET attributes to transform them in WSRF.Net port type constructs. We anticipate addressing this limitation in future implementations in the context of the TrustCoM integrated project. In the context of the TrustCoM project.1. policy-decision-making and policy-enforcement loops to allow. in the context of the TrustCoM.3. Such an integration is not sufﬁcient. it provides functionalities for discovering. However. to a large extent.Net platform — because it is highly coupled with its schema for managing port type concepts. we are developing more comprehensive solutions for VO security policy speciﬁcation. as well as modifying the enforcement agents to insert them in to the new SOAP engine.NET platform. a UK advanced development project. based on widely accepted industry standards and also including the capability to deﬁne adaptation policies to allow a system to adapt its conﬁguration automatically to changes in the environment.8.e. 4. distribution. such as WS-Trust.2. for WSRF.8. The Microsoft SOAP pipeline. The implementation designs for the GRASP-SI prototype can be reused with some adaptation in order to ensure that the service interfaces exposed to realise the operations deﬁned in the design comply with WSRF conventions. Djordjevic et al. GRASP-SI as a package – i. Migration from OGSI to WSRF The Web Service Resource Framework (WSRF)  was proposed by IBM and the Globus Alliance as a set of new speciﬁcations for re-factoring many of the concepts in OGSI to be more consistent with Web Service model. which was used for describing the service composition scenarios in GRASP. 4. However. This falls short of the approach described in Section 3. Re-factoring the GRASPSI source code according to WSRF. In the W3C’s Web Service Architecture (WSA). including the source code of the current prototype – is reusable. prevented the implementation of further decompositions of that SIG. policydistribution. The security model and architecture described in this paper are. but only in the context of Grid services loaded on the OGSI. 7(a). correctly interpret and update security policies (including policies that PERMIS would accept as input). ELeGI and Akogrimo projects we are currently examining the dependencies between these speciﬁcations at a conceptual and architectural level in order to optimise the use of industry standard web services speciﬁcations. we expect to take advantage of the WS-Coordination speciﬁcation as a baseline for rebuilding our SIG coordination and membership management mechanisms on top of token management. 4. GRASP-SI administrative services to process.4. as exempliﬁed in the concept of “stateful resources”. querying and manipulating stateful resources via Web service interfaces. Finally. and for allowing a choice of security token proﬁles for SIG formation at run time. Furthermore.I. In particular. independent of the implementation platform and can be realised on several platforms that extend W3C’s Web Services Architecture or the GGF Open Grid Services Architecture. / Future Generation Computer Systems 23 (2007) 633–657 653 4. In addition. Although the dynamics of SIG lifetimes support its adaptation to certain changes of the VO context. From this perspective. where we associated the formation of a SIG with each collaborative activity that contributes to the enactment of a composite application.Net SOAP engine. because it does not close the policy-speciﬁcation.NET Web services (which are the “normal” Web Services exposed via IIS on a Windows machine) and the toolkit annotates them with metadata via . we anticipate that a more general solution may contribute to future versions of this security solution becoming more autonomic.NET and WSE. WSSecurity and WS-SecureConversation. . Limitations of scope creation for distinct business activities within the version of BPEL4WS. the current prototype does not support the enforcement of obligation policies that use an Event–Condition–Action mechanism in order to trigger an action from a managed service. is used to elaborate SOAP messages and all security headers will be parsed by WSE pipeline. etc. We also anticipate taking advantage of WS-Policy mechanisms for formalising the correlation between the service composition speciﬁcation and the different security contexts that may co-exist during its enactment. although possible in the conceptual design. for example. However. such as changes to SIG membership.3.NET  is the ﬁrst publicly available toolkit for implementing WSRF-compliant Web services that is implemented on top of the Microsoft .. is currently working towards a better integration of GRASP-SI with PERMIS. at present the prototype implementation creates a single SIG for each composite application instance.NET services. then a SIG may be created for each business activity scope in that speciﬁcation. WSRF. services are either stateless or any reference to state in the client–server protocol is an application-level concern. in the context of the TrustCoM and Akogrimo projects. if the service composition scenario is viewed as a workﬂow speciﬁcation.8. and secure message exchange mechanisms based on emerging industry standards for web services. shown in Fig. The central theme of WSRF is the manipulation of state.2.
This is accomplished by deﬁning extensions to X. . Resource administrators can grant coarse-grained access control policies to a community as a whole (e. For communication between system components.The need to support “single sign-on” for users of the Grid. the attributes are not issued by a community server but rather come directly from individual attribute authorities.509 certiﬁcates.509 public key certiﬁcates for authentication. we summarise related work and compare some of the more advanced approaches to Grid and VO security with the approach we described in this paper. The system assumes that group and role information is reported in a format natively understandable to the authorised resource.g. Akenti uses standard X. The proxy is a time-limited credential that can be used to authenticate a user to remote processes on a user’s behalf. / Future Generation Computer Systems 23 (2007) 633–657 5. and proprietary XML certiﬁcate structures for the binding of attributes to users (e. which contains information vital to identifying and authenticating the user or service. In VOMS. knowledge of resources. Although administration is partitioned between community and resource administrators. which is a standard API for security systems promoted by the Internet Engineering Task Force (IETF). the relevant authorisation information is packaged directly with the identity information used for authentication. The Grid Security Infrastructure (GSI) is used by the Globus Toolkit for enabling secure authentication and communication over an open network. and subject attributes allow for the use of community privileges. Authorisations are independent of local identities at the resources. Therefore. twelve hours. Enforcement in PRIMA is provided by POSIX operating system extensions (available for common platforms) that extend standard ﬁle permissions and regulate resource usage through access control lists. The outcome is that users no longer need to enter a password for every resource they plan to access but can use their proxy for the lifetime of the proxy — by default. Authorisation to access a resource is controlled by a mapping between the user’s distinguished name and a local UNIX id via a grid-mapﬁle controlled by the local system administrator. GSI is based on public key encryption. . Extensions to these standards have been added for single signon and delegation. Authorisation requests are evaluated by rendering attributes of the resource and of the requester against the applicable resource policies speciﬁed in XACML. and perhaps conﬁdential) between elements of a computational Grid. SAML and XACML are used for message formats and SOAP is used as .g. It provides a way to express and to enforce an access control policy without requiring a central enforcer and administrative authority. Required attribute values are assessed. Cardea exposes web service portTypes as external interfaces. it still assumes this information is known before the authorisation decision can occur. a Virtual Organisation) and community administrators then decide what subset of a community’s rights an individual member will have. and pushed to the requesting resource. The Globus Toolkit’s implementation of the GSI adheres to the Generic Security Service API (GSS-API). Mutual authentication and possible encryption is handled using SSL.The need for secure communication (authenticated. The Akenti authorisation system [30. and evaluated according to the Akenti policy language. every user and service on the Grid is identiﬁed via a certiﬁcate. the Virtual Organization Membership Service (VOMS) [26. including mutual authentication and single sign-on. Attribute and use case condition certiﬁcates are collected during the authorisation decision process (in a pull fashion). the subjects authenticate with their own credentials (in contrast to a limited group credential in CAS).27] (developed by the EU projects DataGrid  and DataTAG ) also performs authorisations according to community membership privileges. It employs standard attribute certiﬁcates to bind rights to users and enables the high-level management of such ﬁne-grained privileges. In GSI. narrowing the individual’s rights to a subset of the rights the community has at the resource. The GSI enhances SSL. Djordjevic et al.509 Certiﬁcates to carry restriction policies. use condition statements). The PRIMA system [28.31] (developed at Lawrence Berkeley National Laboratory) allows multiple stakeholders to impose use conditions on a particular access control request. which may be freely delegated. Similarly to the CAS. The Community Authorization Service (CAS)  is an enhancement of the Globus GSI (Grid Security Infrastructure) .654 I.29] (developed at Virginia Polytechnic Institute) focuses on the management and the enforcement of ﬁne-grained access rights. however. GSI provides a number of useful services for Grids. and combined. group membership) and to resources (e. It is similar to VOMS in the sense that the subjects authenticate with their own credentials (in contrast to a limited group credential in CAS) and subject attributes allow for the use of community privileges. A (communitycentric) VOMS server encodes this information into noncritical certiﬁcate extensions that may be presented to the resource. The primary motivations behind the GSI are: .The need to support security across organisational boundaries. which requires the use of specialised data formats and APIs. X. by providing single sign-on capabilities for users by the generation of a proxy certiﬁcate. Related work In this section. and is implemented in Java. including the delegation of credentials for computations that involve multiple resources and/or sites. traded. with the distinction that in PRIMA. and the Secure Sockets Layer (SSL) communication protocol. collected and presented to a PDP by the PEP with the request. Group members authenticate to a resource with a group credential that has restrictions applied to it (limited proxy credential ). thus prohibiting a centrally-managed security system. It separates the administration of resource speciﬁc issues from those that are community speciﬁc. although the system distributes management responsibilities between resource and VO administration. Thus. roles. user identities. The focus of the Cardea system  (developed as a part of the NASA Information Power Grid ) provides support for authorisation scenarios that span multiple administrative domains. community access rights and group memberships must be established before authorisation can occur.g.
GRASP-SI separates authentication tokens from authorisation tokens (which can be explicitly associated with the former) and its conceptual model relativises roles within communities (Service Groups) that are explicitly associated with a unique security context. . However. 6.In our case. .Each organisation deﬁnes its own (typically public) security policy dictating the way that consumers can access the services and resources that this organisation contributes to the VO. The urrent GRASP implementation provides limited functionality for security policy management and enforcement. Djordjevic et al. services and resources. Community-speciﬁc security policies of relevance to a service or resource are interpreted in custom ﬁlters that implement the enforcement agent’s tasks. and in their current versions they tightly couple authentication information with access rights. . and a mechanism allowing an autonomic reaction to contextual changes. and they may change depending on the state of that activity. Relationships between VO participants are bound to some form of agreement against which their performance is being assessed.a federated community management model for relating independently managed security domains. Messages are secured using the XML Digital Signature speciﬁcation. the VO participants provide services that are integrated upon-demand into a custom-made solution. VOMS and CAS are both based on a community centric paradigm. These are issues that we plan to address in the next generation of prototypes that we are developing in the context of European projects. The security solution that we have been presenting in this paper is addressing a different set of requirements. it is dependent on a proprietary access control language. . but explicitly associated with the business roles that a service assumes during the enactment of a composite application service. . Direct P2P interactions between the members are supported with authorisation tokens that are issued by the community administrators and endorsed by the security administrators of the corresponding members.NET takes advantage of SOAP messaging and the WS-Security and WS-Secure-Conversation protocols. Cardea does not directly address community membership management but offers support for authorisation across multiple administrative domains through an interesting combination of SAML and XACML-based solutions. . Akenti has achieved decentralised access control enforcement and supports abstractions such as groups and roles. Consequently. / Future Generation Computer Systems 23 (2007) 633–657 655 a transport mechanism. administrative/security domains. Its current implementation (made available in January 2005 as a part of the GRASPv2. and deﬁnes a logical grouping of services within a single. but are speciﬁc to the context of each collaborative activity that it contributes to. the rights and obligations of a service instance are not ﬁxed in its proﬁle. The interaction model of the proposed architecture .NET. which are more relevant to applications of Grid computing for Enterprise integration in a commercial context. Most of these Grid security solutions aim to solve one of the following two problems: . . Similarly to the other tools evaluated.Using widely accepted (WS-∗ ) industry standards for web services we have been developing: . It builds on top of OGSA.a coordination mechanism for deﬁning and distributing a security context that underpins all service–service interactions. PRIMA appears to be making better use of the concept of attribute authorities.a master–slave model for making security decisions and for the enforcement of actions within a single security domain. enables the dynamic formation and self-management of security perimeters protecting communities of users. where the WSE SOAP elaboration pipeline parses the incoming and the outgoing SOAP messages. The security policies of communities are managed in a federated fashion (between security administrators and community managers). but suffer from the absence of an expressive policy description language (e.Security policy roles aggregating access rights and obligations are deﬁned not only for users but also for service instances.A large community of end-users is attempting to use a potentially large number of resources distributed in different sites. It also deﬁnes its own (typically private) security policy providing the rules upon which security decisions about controlling the use of its assets are made at run-time. using limited resources.a peer-to-peer model for secure interaction amongst service instances that share a common security context. and/or offer the same service to several VOs. . our current prototype. The design of the required certiﬁcates and security tokens takes advantage of WSE’s extensibility. they may offer several different services in the context of the same VO. The enforcement agent’s task is based on a rule veriﬁcation process applied to the SOAP message. one that exploits the concept of role). we have observed the following fundamental differences. services and resources. In summary. across administrative domains.A user submits a batch job that is then broken down into smaller jobs and distributed to different execution environments where jobs are executed on behalf of the user. Compared to the above.I. which allows the use of custom security tokens as security headers in SOAP messages. or across multiple. and enforced by each community member through the master/slave model (between security managers and enforcement agents). a disadvantage of GRASP-SI is the absence of a powerful policy description language. GRASP-SI came later than VOMS and CAS and has the capability to combine loosely coupled community membership management mechanisms with role-based policies for controlling access. Conclusion In this paper we have presented a novel solution enabling the dynamic formation and self-management of security perimeters protecting communities of users. GRASP-SI.0 environment) on . which is in turn realised on Microsoft . These roles are distinct. but still lacks an expressive policy language and a ﬂexible distributed access control enforcement mechanism.g.
Kesselman.Net. La Jolla. Category: Informational. Wulf. Market Strategy Report.  R. Open Grid Service Infrastructure WG. services. Bresnahan. H. D. web site: http://www. P. distribution and management in a federated environment. Machiraju. Tuecke. 5–8 October 2003. September 2002. van Moorsel. CHEP03. SpringerVerlag.login: The Magazine of USENIX Association (1999) 37–39.cern. Also.virginia. of London. Matthews. IEEE Press. Pearlman. 17 November 2003. Yuan. I. November 2004. Wasson.  K.aspx. Mac Randal. Attribute-based programming for grid services. K. March 2003. S. C. Dimitrakos. Czajkowski. Dimitrakos.  http://www. Trust. in: Proc. in: 2nd International Conference on Trust Management. in: Proceedings of the IEEE Policy Workshop 2002.usenix. D. S. Tuecke. V. Djordjevic. Wesner. Wesner. integrates a layered peer-to-peer model (between the managers administering network entities and between the administered entities). S. WA. USA. N. Siebenlist. CA. Foster. S. Bicarregui. July 2002. It supports the on-demand creation and management of dynamic virtual collaborations.  R. A ﬁrst prototype of the proposed security solution has been implemented within the European project GRASP [7. This Web Services-based implementation.cs. T. Graham. I. M. Ritrovato.S. Welch. Serhan. Pearlman. Ritrovato. HPL-2002-66. Brisbane. Managing dynamic user communities in a Grid autonomous resources. IETF. Vambenepe. Contract performance assessment for secure and dynamic virtual collaborations. and integration of network/middleware policy management capability. Grid service speciﬁcation. Phillips. J. we plan to expand it to meet the full functionality described in this paper. N.edu/∼gsw2c/wsrf. Laria. Ritrovato. varbusiness. T.  L.cs.D. Lorch. IFIP/IEEE NOMS. Morgan. References  Summit Strategies. C. HP Laboratories Palo Alto. Traditional ISVs: Moving along the software-as-services curve. Foster. December 2000. Welch. IL. D. F.656 I. in: Workshop on Designing and Building Grid Services. I. 2004. LA. Kesselman.) that are independent of network topology and span across multiple administrative domains.  T. 2004. We are particularly thankful to Giuseppe Laria. 2004. RFC3820. et al. Foster. substantially alters the present security capabilities of both OGSI. Rolia.permis. The Ninth Global Grid Forum. Sehran. P. pdf. May 2000.  PERMIS. USA. Welch. Dimitrakos. M.edu/∼humphrey/GCG/ogsi. Market Analysis Report. RFC 2828.  T. Distributed ﬁrewalls.ibm. http://www. S. http://www-106.com/developerworks/library/ws-resource/ws-wsrf. Laria. Graham. Mac Randal. C. S.NET and Microsoft . Dimitrakos. R. Architecture for dynamic and secure group working. McCabe. in: eChallenges Conference. S.  I. G. I. authorization and enforcement in Grid environments. in the form of secure communities of peers (user agents. of Conference for Computing in High Energy and Nuclear Physics.NET: OGSIcompliance on the .  L.C. New Orleans. W.509 public key infrastructure proxy certiﬁcate proﬁle. V. March–April 2004. Phoenix. Software Technology Laboratory. Meder. Category: Standards Track. Alﬁeri.net. Park. Milosevic. Dimitrakos. March 2003. Ferguson. Inc. L. C. Pearlman. The PRIMA System for privilege management. . K. Sandhu. Quality of business driven service composition and utility computing. leveraging Microsoft . IEEE Press. An architecture for dynamic security perimeters of virtual collaborative networks. P.  G. Frohner. IOS Press. G. I. 2004. I. I. Gaeta. of 4th Int..com/webservices/building/wse/default. Frey. in: Proc. D. G. Global Grid Forum.  V. D. http://edms. D.html. 2003.M. C. M.  T.  J. . Thompson. Although the current state of the implementation provides a limited functionality for security policy speciﬁcation and analysis and for integrated distributed security enforcement management. J. security and contract management challenges for Grid-based application service provision. USA. Snelling. CA. including the cross-referencing of application and network level security policy statements and the coordination of their enforcement.cs. June 2004. C. A. etc. S. SpringerVerlag. IETF. OGSI.org/. Rathi. Tuecke. Bassem Serhan and Francesco Verdino for their contribution in coordinating the development of the GRASP platform and in reviewing the contents of this paper. The WS-resource framework. AR.html. CHEP03. in: ACSAC 2000. Shah. Seattle. Humphrey. Workshop on Grid Computing — Grid 2003. 16–19 September 2003. T. http://www. Laria.microsoft.NET/WSE.10]. Bellovin.  S. Serhan.  G.  A.. Beekwilder. Sedukhin. Czajkowski. La Jolla. Towards a platform enabling Grid based application service provision. Phillips. in: LNCS. I. The community authorization service: Status and future. in: Proceedings of iTrust2004: The 2nd International Conference on trust Management. Dimitrakos. Djordjevic. Shirey. J. OGSI. Tuecke. edu/∼gsw2c/OGSIdotNet. Kesselman.net. Engert. in: Proceedings of the 7th IEEE International Enterprise Distributed Object Computing Conference. Acknowledgements The authors wish to thank all partners of the GRASP and TrustCoM consortia for their useful comments towards improving this paper. execution environments and enterprise boundaries.  I. USA. June 2003. Dimitrakos. Tuecke. 7th IEEE International Enterprise Distributed Object Computing Conference. June 2004.com/sections/strategy/strategy.  http://msdn. A.virginia. Foster. L. / Future Generation Computer Systems 23 (2007) 633–657  T.  S. Summit Strategies.NET  and Microsoft WSE. 15 March 2002. Romano. in: Proc. Kesselman. B. http://www. EU Deliverable. Chicago. Ph. Djordjevic et al. J. M.html. Univ. M.ch/document/344562. in: LNCS. Australia. Djordjevic. Internet security glossary. Draft.virginia. DataGrid Security Design Report.  S. D. Out of the box: Top nine net-native software-as-services design differentiators.  http://www. Gawor. C. Phillips. B. B.  V. Adams. Frey. S. in: Proc of 12th IEEE International Symposium on High Performance Distributed Computing. March 2003. resources. Djordjevic. D. Thesis. Jøsang. 8. Czajkowski. Policy-driven access control over a distributed ﬁrewall architecture.org/publications/login/ 1999-11/features/ﬁrewalls. A. Mac Randal. Z. J. Security for Grid services. An emerging architecture enabling Gridbased application service provision. USA. Wesner. Djordjevic. Koneni.  I. Towards dynamic security perimeters for virtual collaborative networks. Binding identities and attributes using digitally signed certiﬁcates. Humphrey. Kafura. improvement of the systems for security token instantiation. K. J. of EDOC’03. in: Conference for Computing in High Energy and Nuclear Physics.  M. B. Wasson. Foster.  S. we thank the anonymous reviewers for their comments and suggestions for improving the paper.jhtml?articleId=18813132& printableArticle=true. enforcement of event driven obligation policies and improvement of the integration of the Security and SLA subsystems based on a common underlying policy deployment model. with a centralised community management model (between community members and their local security managers) and a master/slave model (between security managers and enforcement agents). 2002.M. e-2004. Internet X.NET Framework ccGrid ’04. F. The ongoing work includes efforts aimed at: introducing mechanisms for autonomic security management.
USA.gov/security/ Akenti/.  Akenti Page (publications & source code). web and grid services. Djordjevic et al. Lorch. http://dsd. TrustCoM. ELeGI. and has been involved in several EC IST collaborative projects (BEinGRID.  R.D. working on SOA/Web Services security design.lbl. November 2003. GRASP. The main focus of her work relates to the security issues in Grid environments. and lecturing at the University of London on the same topic. working on “Distributed Architecture for E-Learning Platform”. degree in Computer Science at the University of Salerno in 1992.  DataTAG Project home page. and has been involved in several other EC collaborative .datatag. In the last ﬁve years.D. GRASP.R. London.D. Most recently. He has authored over twenty ﬁve scientiﬁc publications in international conferences and journals. Thompson. 181–193. ACM Transactions on Information and System Security (TISSC) 6 (4) (2003) 566–588. of 3rd Int.  Information Power Grid.lbl. Nadia Romano obtained the B. Akogrimo and e-LeGE projects funded under IST. Pierluigi Ritrovato obtained the B. business process support.edg. British Telecom. http://www. and Dipl. He holds Ph. Theo is the scientiﬁc coordinator of the FP6 Integrated project TrustCoM. He has a Ph. he has been involved in Smarthomes. The work of his team focuses on the solutions for Grid and Web Services Security. Damian has been scientiﬁc coordinator for several large multinational EU projects and overall coordinator of several national and international research consortia. Akogrimo). A. ambient computing. Grasp.gov. prior to that he was with Logica UK.  DataGrid Project homepage. working on the security and membership management services for Virtual Organisations. services orchestration and security. Essiari. She collaborates with CRMPA since 2002. iTRUST. Supporting secure ad-hoc user collaboration in Grid environments. Dr Theo Dimitrakos is leading the SOA Security team of the Security Research Centre.Eng in Telecommunications from the Faculty of Electronic and Electrical Engineering. (1998) from Imperial College. Lepro. ELeGI). CCLRC.S.S. working on e-commerce messaging and EDI products. LBNL-49512.I. computer aided design. SWAD-EUROPE. Ph. and has contributed numerous publications in international conferences and journals. as well as the service requirements for managing Virtual Organisations (VO) and Virtual Learning Community (VLC) according to the OGSA speciﬁcation. http:// www-itg. Also. Currently. Ivan Djordjevic. working in the areas of intelligent user interfaces. on Secure Collaborative Working from University of London (2004). 657 projects (TrustCoM. in: Proc. Workshop on Grid Computing — Grid 2002. S. http://www. CORAS.  M. SLA usage and Workﬂow — Technical Group for the EU FP6 Grid projects.ipg. 18 November 2002.org. he was with CCLRC. At present he is Researcher in Engineering & Computer Science at University of Salerno and Responsible for International Research Cooperation and Technology Innovations for the CRMPA. during which period she has been involved in several EC IST collaborative projects (GRASP. He has edited four books in the areas Trust & Security and Grid Computing and authored over forty scientiﬁc publications in international conferences and journals. He is the Chair of the Service Orchestration.gov/security/Akenti/Papers/ACMTISSEC.. / Future Generation Computer Systems 23 (2007) 633–657  M. CISSP is at the SOA Security team of Security Research Centre. iTrust). Baltimore. degree in Computer Science at Salerno University in 2002. on Foundations of Software Engineering. CORAS. pp. He is editor of the book Towards the Learning Grid: Advances in Human Learning Services. Before joining BT. NASA Advanced Supercomputing (NAS) Division. he has been working on the design and implementation of commercial systems for business process support and webbased e-learning systems. Ivan was an ERCIM Research Fellow at Rutherford Appleton Laboratory. Kafura. she is a holder of a research contract at the Department of Computer Engineering and Applied Mathematics of the University of Salerno. Prior to joining BT.nasa.org. Damian Mac Randal has been contributing to the research at national and international level for over 20 years. University of Belgrade (1999). http://www.pdf. Cardea: Dynamic access control in distributed systems. he has been focusing his scientiﬁc research on Grid technologies and their use for business taking into account aspects related to the operational management of Virtual Organisation. NAS Technical Report NAS03-020. Certiﬁcate-based authorization policy in a PKI environment. Mudumbai. D. ELeGI. BT. leading R&D programme on Web Services and Grid Computing. Akogrimo.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.