leveraging the Web Services technology, public agencies have implemented various ..... token request, it verifies the digital signature of the token included in the ...
Orchestration of Secure Web Services within an E-government Interoperability Platform Emilio Penna, Martín Steffen, Laura González, Guzmán Llambías Instituto de Computación, Facultad de Ingeniería Universidad de la República Uruguay {emiliopenna, martins1930}@gmail.com,{lauragon, gllambi}@fing.edu.uy Abstract—The Uruguayan e-government agency has made available an Interoperability Platform (InP) with the purpose of facilitating the implementation of e-government services. By leveraging the Web Services technology, public agencies have implemented various atomic services which are usually hosted at the agencies but have to be accessed through proxy services in the InP. Given that the implementation of e-government processes involves invoking multiple services, the mechanisms to implement service orchestrations are increasingly required. Although there are well-known solutions for orchestrating Web Services, their application within the InP presents challenges, in particular, regarding the integration with its Security System. This paper proposes alternatives for implementing orchestrations of secure Web Services within the InP. The proposal consists of a base architecture that can be configured to implement different solution alternatives, enabling its application in other similar scenarios. The proposal was completely prototyped which allowed evaluating some operational aspects of the solution. Keywords—service orchestration; web services; soa; esb; wssecurity; ws-trust; saml; e-government; interoperability; ws-bpel;
I.
INTRODUCTION
E-Government Interoperability Platforms are a key tool to support the development of e-government in many countries. In Uruguay, the Electronic Government and Information Society Agency (AGESIC, Agencia de Gobierno Electrónico y Sociedad de la Información: http://www.agesic.gub.uy/) has designed, built and made available an Interoperability Platform (InP) within the Uruguayan E-Government Platform [1]. The InP, which comprises a hardware and software infrastructure along with legal and technical frameworks, aims to facilitate the implementation of e-government services and their access, giving the support for building an statewide service-oriented architecture (SOA). Hence, leveraging the Web Services technology, public agencies are able to provide its government functionality through software services that can be described, invoked and combined in a platform independent way. During the last five years, public agencies have implemented and made available through the InP a considerable number of simple or atomic services. These services are usually hosted on servers located at the agencies and exposed through proxy services deployed in the InP. This way, all service invocations pass through the InP which allows, for example, that the Security System of the platform can apply
authentication, authorization and auditing controls to them. It also allows that the Middleware Infrastructure of the platform, in particular an Enterprise Service Bus (ESB), can apply different mediation operations (e.g. intelligent routing, message transformation) to service invocations. Given that the implementation of e-government processes usually involves the invocation of various atomic services from more than one public agency, the mechanisms to implement compositions (i.e. orchestrations) of these services within the InP are increasingly required. Although there are well-known standards and tools for orchestrating Web Services (e.g. WSBPEL), their application within the InP presents challenges regarding, for example, the integration with the Security System of the platform which requires the use of advanced security standards like SAML, WS-Security and WS-Trust. This paper proposes solution alternatives for implementing orchestrations of secure Web Services within the InP which, in particular, solve the integration with the Security System of the platform. The base architecture of the proposal comprises a WS-BPEL orchestration engine, deployed within the InP, and leverages the mediation capabilities provided by the ESB of the platform. Over this base architecture, different solution alternatives can be implemented by configuring a set of modules. The alternatives differ from one another, for example, due to variations in the required security token which provide, in turn, flexibility characteristics to the proposal. This way, even though the solutions were proposed in the context of the Uruguayan E-government Platform, they may be applied in similar contexts or scenarios. The proposal was completely prototyped using Apache ODE, as the WS-BPEL engine, and JBoss ESB. Over this prototype, a case study within an e-government scenario was also implemented. This allowed evaluating some aspects of the solution, for example, in terms of its behavior in the presence of attempts of unauthorized accesses, concurrent flows support, capability to propagate additional security tokens to services and some performance issues. These results along with the analysis of the different alternatives are currently the base of a production implementation which is under development. The rest of the paper is organized as follows. Section II presents background and analyzes the requirements for orchestrating Web Services within the InP. Section III presents the solution approach. Section IV describes implementation
and evaluation issues. Section V presents related work. Finally, Section VI presents conclusions and future work. II.
BACKGROUND
This section provides background on Web Services and ESB, SAML, Web Services security standards and WS-BPEL. It also describes the InP and the requirements for orchestrating Web Services within this platform. A. Web Services and ESB The Web Services technology is based on various standards, notably, the Simple Object Access Protocol (SOAP) [2] and the Web Services Description Language (WSDL) [3]. SOAP specifies a messaging format and mechanism in order to support the standardized exchange of XML messages between software programs [4]. SOAP messages comprise an envelope containing a header and a body. The header part of a SOAP message can contain various header elements specifying additional information regarding, for example, security or addressing. SOAP messages are usually transmitted via HTTP; however, other transport protocols may be used. WSDL is an XML format for describing network services as a set of endpoints operating on messages; operations and messages are described abstractly, and then bound to a concrete network protocol and message format [3]. WSDL is not restricted to specific message formats or network protocols; however, the standard specifically describes how to use WSDL in conjunction with SOAP and HTTP. There are other Web Services standards that extend SOAP and WSDL to support more advanced features. In particular, WS-Addressing [5] is focused on expressing characteristics about messages regarding their runtime processing and delivery and on providing an agnostic way to reference Web Services. To this end, it defines a set of header blocks which allows specifying these characteristics independently of which transport protocol is used to transmit SOAP messages [4]. For example, the “wsa:to” element establishes a SOAP header that specifies the target address of the message recipient. Similarly, the “wsa:from” element indicates the address and endpoint information about the sender of a message. In turn, an Enterprise Service Bus (ESB) is a standardsbased integration platform that combines messaging, Web Services, data transformation and intelligent routing to reliably connect and coordinate the interaction of diverse applications [6]. ESBs provide a middle integration layer, with reusable integration and communication logic, to facilitate resolving mismatches between applications regarding message formats and communication protocols, among others [7]. Within an ESB-based platform, services and applications communicate by sending messages through the ESB. These messages may be processed by mediation flows which apply to them mediation operations [8]. Although these operations are not formally restricted in what they can do, there are a set of mediation patterns that are commonly supported in ESB products [7]. In particular, transformation patterns deal with the runtime transformation of messages (e.g. data model or data format transformation) [9]. Also, routing patterns dynamically
determines the message path according to different factors. For example, the content-based routing (CBR) pattern determines the message path based on its content [9]. B. SAML The Security Assertion Markup Language (SAML) [12] is an XML-based framework for communicating user authentication, entitlement and attribute information. It allows business entities to make assertions regarding the identity, attributes and entitlements of a subject (e.g. a human user) to other entities (e.g. a partner company or another application). SAML defines three types of statements that can be made within an assertion: authentication statement, attribute statement and authorization statement. SAML defines the SubjectConfirmation element to suply information that allows the subject to be authenticated. Some of the commonly used methods are [13]: i) bearer: it is a "keyless" assertion mainly used as a supporting token and to provide more information about a client which has already proved his identity to the service, ii) holder of key: a subject confirmation method which contains information about the key that must be used to verify the client's identity (e.g. a symmetric key), and iii) sender vouches: a subject confirmation method that is used when a message is sent by an intermediary entity on behalf of the subject of the assertion, that is, the service provider trusts the message sender and accepts requests made by this sender on behalf of other identities. When an entity acts as an intermediary between clients and services, there are different models to handle the required assertions [14]: impersonation, forwarding and delegation. With an impersonation model, an entity acting on behalf of a subject is able to obtain and use an assertion indistinguishable from one that would be issued directly to the subject. A forwarding model is a form of impersonation in which an assertion is directly reused by an intermediary to impersonate a subject from whom an assertion was obtained. Finally, the delegation model adds information to the assertion explicitly specifying all the parties through which the transaction flows (client and all the intermediaries). The identification of an intermediary can be done with the SubjectConfirmation element or with the Delegate element introduced in SAML 2.0. C. Web Services Security Standards Given that HTTP is the main protocol for transporting SOAP messages, using HTTPS in order to provide security characteristics to Web Services interactions is a possible alternative. However, this transport-level approach, which is also applicable with other transport protocols, presents limitations in some scenarios (e.g. if SOAP messages have to pass through not trusted intermediary nodes) [10]. These limitations are addressed by various Web Services security standards, notably WS-Security and WS-Trust, which focus on providing security characteristics at the (SOAP) message-level. WS-Security specifies a set of SOAP extensions in order to be able to provide integrity, confidentiality and authentication at the message level. It is designed to support multiple security tokens (e.g. username token, X.509 certificates, SAML assertions), trust domains, signature formats and encryption
technologies. In particular, message integrity is provided by leveraging XML Signature and message confidentiality is provided by leveraging XML Encryption [8]. In turn, WS-Trust provides methods for issuing, renewing, and validating security tokens as well as methods for establishing and brokering trust relationships between Web Services [11]. It describes a service, called Security Token Service (STS), which exposes a generic interface accepting security token requests (RequestSecurityToken) and returning security token responses (RequestSecurityTokenResponse). An STS client has to include in the request the type of the required security token and a probe of its identity (e.g. by attaching a WS-Security header to authenticate itself). If authentication is successful, the STS returns the requested token. D. Web Services Business Process Execution Language WS-BPEL defines an XML-based language for specifying business processes based on Web Services [15]. The language leverages various standards like WSDL, SOAP, XML Schema and XPath. A process in WS-BPEL is broken down into a series of steps called activities, which can be of various types (e.g. invoke, receive) [16]. The activities can be combined according to business rules using an additional set of language keywords (e.g. sequence, while, switch). The language also allows using variables and data manipulation. There are nowadays multiple WS-BPEL engines (also known as orchestrations engines or BPEL engines) where WSBPEL process definitions can be deployed and exposed as a new Web Service with its own WSDL description. E. The Uruguayan Interoperability Platform The Interoperability Platform (InP) aims to facilitate the implementation of e-government services and their access. This section describes its main components (i.e. the Middleware Infrastructure and the Security System) and presents the required steps to invoke a service through it [1]. The Middleware Infrastructure (MI) has the goal of promoting the interoperability between public agencies, providing the required mechanisms to facilitate the development, deployment and integration of applications and services. These mechanisms, which include execution environments, a service registry and an ESB, are also the foundation to implement an statewide SOA. Leveraging the MI and by means of proxy services, the InP provides location transparency which means that client applications do not need to know the real network address of the services they want to invoke. More precisely, the invocation of services is performed by invoking proxy services deployed in the platform and specifying a logical address which identifies services within the InP. The mapping between logical addresses, which are specified by means of WSAddressing headers, and real addresses is handled at the ESB by leveraging its content-based routing capabilities. In addition, the Security System provides the mechanisms to enforce authentication, authorization and auditing policies
according to the established security requirements. Public agencies can delegate to this component the verification of the compliance with these requirements. The main component of the Security System is the Access Control System which provides the mechanisms for applying access control policies when accessing services, by using a Role Based Access Control (RBAC) schema. The Access Control System has three components: Security Token Service, Security Policy Manager and XML Firewall. The Security Token Service (STS) has the responsibility of supporting the implementation of a federated security solution following the WS-Trust standard. Services trust the STS, so each client that wants to invoke a service has to present a security token issued by this component. In order to issue security tokens, the STS trusts the authentications performed at the public agencies. In particular, it verifies the authenticity of the requests through digital signature mechanisms. When an application running in a public agency wants to invoke a service which is published in the platform, it first has to request a security token to the STS. This WS-Trust request has to include a security token specifying the user role with which the service is going to be invoked. The security token has to be specified using SAML (v1.1 or v2.0) and it has to be digitally signed by the public agency. When the InP receives a security token request, it verifies the digital signature of the token included in the request, in order to confirm that the request comes from a trusted entity. The platform also verifies that the user role specified in the security token is a valid one. If all the verifications succeed, the STS issues a security token which is specified using SAML v1.1 and is digitally signed by the platform. This security token includes, among other data, the user role. The communication between public agencies and the STS is performed over HTTPS with mutual authentication. The Security Policy Manager acts as a Policy Decision Point (PDP), given that it is in charge of authorizing the requests for invoking services in the platform. To this end, it stores security policies that define which roles can invoke each operation of a service. When the platform receives a request (i.e. a SOAP message) to invoke an operation of a given service, it obtains from the WS-Addressing headers the logical address of the service and the operation to be invoked. It also gets the user role from the SAML token which is included in the message following the WS-Security standard. With this information, the platform can ask the PDP if the role can consume the invoked operation of the given service, in order to authorize, or not, a given invocation request. The XML Firewall acts as Policy Enforcement Point (PEP) enforcing the decisions taken by the Security Policy Manager (i.e. the PDP). To this end, for each service published in the platform, a proxy service is deployed in the firewall. When a client application wants to invoke a service, the invocation has to be done through its corresponding proxy service. In case the firewall authorizes the invocation, it routes the request to the MI which finally sends the request to the service. Otherwise, an error message is returned to the client application. The communication between client applications and the proxy services is performed over HTTPS with mutual authentication.
Fig. 1. Steps in the invocation of a Web Service within the InP [1]
Fig. 1 presents the required steps to perform a service invocation within the InP. In the first step, a client application within a public agency requests a security token to the STS, including a token signed by this public agency. This token has, among other data, the user role to be used to invoke the service. If the signature is verified and the user role is a valid one, in the second step the STS returns a security token signed by the platform, which also includes the user role. In the third step, the client application invokes the service through its proxy service, including in the invocation the security token obtained from the STS. The XML Firewall allows or denies the invocation based on the decision taken by the Security Policy Manager. If the invocation is allowed, in the fourth step, the XML Firewall routes the request to the Middleware Infrastructure which finally, in the fifth step, routes the invocation to the service. F. Requirements for Orchestrating Services within the InP The main purpose of this work is to explore solution alternatives to be able to orchestrate services within the InP, with the goal of providing higher level services by composing the existing atomic ones. There are three main requirements posed by the InP: i) in order to orchestrate Web Services, the WS-BPEL standard has to be used, ii) the proposed solution has to be integrated with the security mechanisms provided by the InP and iii) the proposed solution has to use the WSAddressing routing service of the platform. These two last requirements imply that the orchestration engine has to perform the invocations through the proxy services deployed in the platform. In addition, the invocations have to include the SAML security tokens required by the platform, following the
WS-Security standard, and use WS-Addressing for routing service invocations. Next, these and other requirements are analyzed in more detail. Authentication and identification: As stated before, orchestrations have to invoke the services through the proxy services. This involves performing the authentication required by the platform: mutual authentication at the transport-level and signed SAML tokens at the message-level. The identity of the requester (username and role) has to be also propagated to the service provider, by means of the security token. In addition, it may be also possible that one or more services of the orchestration require additional security tokens (e.g. a username token), so this fact has to be also considered. These additional tokens should be sent by the client and propagated by the orchestration only to the service that requires them. Authorization: The access to the atomic services from an orchestration has to pass through the access control components of the Security System of the InP. This involves setting up the rights of clients to be able to invoke the orchestration and the rights of the orchestration engine to be able to invoke the atomic services. It is important to note that although clients may have the rights to invoke an orchestration as a whole, they may not have the rights to invoke, in a direct way, the atomic services composing the orchestration. In addition, it is also advisable to perform an authorization checking before the execution of the orchestration starts, in order to verify that the requester has the required rights to invoke every service operation composing the orchestration. Confidentiality and integrity: The interactions between public agencies may have end-to-end confidentiality and
integrity requirements. Therefore, it has to be analyzed if it is possible to fulfill these requirements in the context of an orchestration. Auditing: The solution has to allow performing the security auditing of the invocations passing through the platform. This includes the invocations to the orchestrations and the invocations to the services composing the orchestration. Security Tokens: The orchestrations will be exposed as new services within the InP. Consequently, in order to invoke these services, clients will have to include a SAML token in their requests, in the same way as they do when invoking atomic services. Given that the STS issues tokens to invoke specific services, a token that a client sends to invoke an orchestration is valid only for invoking this orchestration and it cannot be used to invoke the atomic services. Consequently, the solution has to consider the interaction with an STS, by using the WSTrust standard, in order to obtain valid tokens to be able to invoke the atomic services from the orchestration engine. III.
SOLUTION APPROACH
This section presents the solution approach for orchestrating secure Web Services within the InP. First, some considerations that guided the proposal are described. Then, the base architecture of the solution is presented and different solution alternatives are analyzed. Later, other aspects of the solution are described. Finally, a sample configuration, a summary and a discussion are presented. A. General Considerations Given that the orchestration of Web Services has to be performed using the WS-BPEL standard, one of the main components of the solution is a BPEL engine. This engine provides the execution environment for the implemented orchestrations. Something that was considered appropriate for the solution was the use of a standard BPEL engine without modifications. First, it was decided not to modify the BPEL engine given that modifications will be difficult to maintain in new releases of the product. Second, it was also decided not to use features of the products which were not part of the WS-BPEL standard. This way, the solution will not be tied to a specific engine and it will be able to use other WS-BPEL compliant products. The only exception to this is the use of the mechanisms to copy SOAP headers. However, this is not considered an issue given that most of the current BPEL engines provide this feature. Considering that, on the one hand, the orchestration engine is used without modifications and, on the other hand, it does not have support for some of the operations required by the solution (e.g. the capability to request security tokens using WS-Trust), an additional component to perform these not supported operations is required. B. Base Architecture Fig. 2 presents the base architecture of the proposal which extends the Middleware Infrastructure by including a BPEL Engine and a component called BPEL Gateway (BPEL-GW), i.e. the aforementioned additional component.
Fig. 2. Base Architecture of the Proposal
The BPEL-GW acts as a wrapper for the BPEL Engine and can be considered as a two-way proxy given that it intercepts all the incoming and outgoing messages of the engine. This component was built on top of the ESB of the platform, more precisely as an ESB service, leveraging the mediation capabilities provided by ESB products. In the proposed solution, orchestrations are exposed as other services of the platform (i.e. via proxy services) and clients invoke these services in a similar way as they invoke atomic services (i.e. by specifying in the request the logical address of the service and the operation to invoke, via WSAddressing). The solution uses a content-based routing component which detects the requests invoking orchestrations and routes them to the BPEL-GW. The BPEL-GW includes a component (pre-processing chain) which processes the incoming invocations to the engine and another component (post-processing chain) which processes the invocations performed by the engine to the atomic services. These chains are implemented as mediation flows, where each step in the flow is an action or module which performs a specific message processing. Fig. 3 presents in more detail these two components.
Fig. 3. Pre-processing and Post-processing Chains
After the pre-processing, requests are routed to the BPEL Engine in which the specific business logic of each orchestration is executed. As stated before, while executing an orchestration, the invocations performed by the BPEL Engine to atomic services are routed to the BPEL-GW.
In addition, the security headers sent by the client are propagated to the services by adding activities in the WSBPEL process definition, which copy the headers before invoking a service. These activities can be automatically added, at deploy time, using a utility tool that was developed to facilitate this task. The outgoing invocations from the BPEL Engine, to the atomic services, are routed to the post-processing chain of the BPEL-GW. In this chain, various actions are performed, for example, a security token exchange is carried out in order to be able to invoke the atomic services with a suitable token. Finally, after obtaining this token, the BPEL-GW invokes the atomic services routing the requests to the proxy services deployed in the XML Firewall of the platform. The interactions between the BPEL-GW and the BPEL Engine are performed using SOAP over HTTP. C. Solution Alternatives This section analyzes different solution alternatives that can be implemented on top of the base architecture described in the previous section. The alternatives differ from each other mainly due to variations in the required security tokens and access control model. Next, before analyzing the different alternatives, some aspects to be considered in the solutions are analyzed. First, Table 1 presents a simplified version of the main elements of a security token (SAML assertion) used for accessing atomic services within the InP. TABLE I. Element Subject
EXAMPLE OF AN INP SECURITY TOKEN Value user1-role
Audience
http://egp.uy/SimpleService1
Attribute
User=user1
Attribute
PolicyName=urn:tokensimple
Signature
InP STS
Description Application role of the user The Web Service that can be invoked using this token Username Token category Signature of the STS
The assertion presented in the table includes an Authentication Statement, where the subject specifies the role of the client, and an Attribute Statement, where the user name of the client is specified. The Policy Name attribute specifies the name of the processing policy in the Security System of the platform. Currently, the only allowed value for this attribute is “urn:tokensimple”. In addition, the assertions used in the InP has audience restriction (saml:AudienceRestrictionCondition), limiting in this way the context in which they can be used [12]. In particular, this element is currently used to specify (and restrict) the service for which the token can be used. In the case of orchestrations, there are various services which have to be considered. On the one hand, the orchestration is exposed as a service in the InP and, on the other hand, the BPEL engine executes orchestrations by
invoking existing atomic services. Given that it is expected that orchestrations can be consumed in a way similar to atomic services, clients have to invoke them with a valid token for the orchestration. To this end, a similar token to the one presented in Table 1 has to be used but with an audience restriction specifying the service exposing the orchestration. This restriction makes that this token cannot be used to invoke atomic services; therefore, a new valid token to be able to access these services is required. This fact illustrates one of the problems that arise in this scenario: the definition of a suitable token to invoke atomic services from the orchestration engine and the mechanisms to obtain it and include it in these invocations. The Access Control System of the InP checks in each request that the subject of the request has the required rights to invoke the specified operation of a given service. Considering that the execution of an orchestration may imply the access to various operations of one or more services, the way in which these rights are assigned to be able to access these operations and services have to be evaluated and defined. Next various solution alternatives are analyzed to solve these and other issues. 1) Obtaining a New Token In this alternative the orchestration engine, before invoking an atomic service, obtains a new SAML token, valid for that service, and includes it in the WS-Security headers of the service request. Given that orchestration engines do not usually support the interaction with a WS-Trust compliant STS, a new component to solve this integration is required. To this end, the ESB mediation capabilities are leveraged by implementing and using a TokenExchangeMediation action, which is executed within the post-processing mediation flow of the BPEL-GW. In the outgoing invocation from the orchestration engine, the SAML token sent by the client is propagated and the TokenExchangeMediation performs the exchange of this token for a new one (by interacting with the STS of the InP). This new token is similar to the one presented in Table 1 and it has a suitable value for the Audience element in order to invoke a specific atomic service (e.g. http://egp.uy/SimpleService1). The TokenExchangeMediation component was designed as a reusable and configurable ESB component, providing a generic solution to perform an exchange of security tokens with WS-Trust. Fig. 4 presents a sequence diagram specifying the main interactions in the token exchange process. Regarding access control, the first thing to consider is that the client has to have the rights to invoke the service corresponding to the orchestration. Then, when the BPEL engine invokes a service, this request has to pass through the Access Control System of the platform. So, it is also required that the client has the rights to execute all the operations invoked by the orchestration (these requests are performed by the BPEL engine with the identity of the client). This fact presents an issue to solve, given that in some scenarios may be required to detach the rights to invoke an orchestration from the rights to invoke the atomic services it uses. That is, a client may have the rights to invoke an orchestration but may not have the rights to invoke the services it uses, or vice versa.
Fig. 5. Identifying the Delegate
This way, a service can know in a standard way that a request was not performed in a direct way by the client, but it was performed by a delegate or intermediary acting on behalf of the client. In this specific case, the service can know that the invocation was performed in the context of an orchestration. 3) Using a New Role
Fig. 4. Sequence Diagram of a Token Exchange
An alternative to solve this issue, in a nonstandard way, is leveraging the PolicyName attribute of the assertions used in the InP. In particular, the proposal is using a different value for this element (e.g. urn:bpel-gw) to explicit that the token is being used within an invocation performed by the BPEL engine. This way, it is possible to know if the client is invoking a service in the context of an orchestration or directly. Finally, to be able to perform a preliminary authorization checking, a mediation component is used in the pre-processing chain of the BPEL-GW. This component, called CheckProcessAuthz, leverages an API provided by the InP in order to verify that the client has the required rights to invoke all the operations within an orchestration, before starting its execution. This preliminary checking prevents errors during the execution of an orchestration due to access control issues. 2) Identifying the Intermediary This solution alternative differs from the previous one by incorporating standard mechanisms to identify the BPEL Engine when requesting tokens and performing invocations. In the previous alternative, the BPEL engine invokes services using the identity of the client. This engine can be seen as an intermediary between clients and services, which acts impersonating the clients. When the BPEL-GW requests a new token to the STS, it specifies that the token is requested to act on behalf of the client by using the element OnBehalfOf defined in WS-Trust. However, the use of the PolicyName element in the SAML assertion in order to specify that the invocation is performed in the context of an orchestration can be seen as a nonstandard way to indicate that. A standard way for identifying an intermediary acting on behalf of a client, is the delegation mechanism provided by SAML. This allows specifying, within an assertion, the acting intermediaries or delegates. This mechanism can be leveraged, in this way, to identify the BPEL Engine as an intermediary. In order to use and implement this mechanism, the requests performed by the engine have to include an element, within the SAML assertion, which identify the engine as a delegate, as shown in Fig. 5.
This solution alternative differs from the previous ones by using a role associated with each orchestration, with the goal of simplifying control access management tasks. The previous solution alternatives require that the role of a client has access for each one of the service operations which compose the orchestration. This can be difficult to maintain if there are a considerable number of clients and/or operations involved in the orchestration. In order to simplify the tasks related to access control management, this solution proposes to create a new role for each orchestration. This role will be used to perform the invocation to the atomic services. In a simplified way, this process can be seen as a dynamic assignation of a new role to the client. In order to apply this solution, as in the previous alternatives, the role of the client has to have the rights to invoke the orchestration. In addition, the rights to invoke the atomic services have to be configured only for this new role (the one associated to the orchestration), instead of configuring them for each possible role who may want to invoke the orchestration. This clearly simplifies the access control management, for example, if a new role wants to invoke the orchestration or if the orchestration has to invoke a new service operation. In addition, this solution also allows fulfilling the requirement of not allowing the direct access to atomic services to clients that may only have the rights to access the orchestration as a whole. In addition, this solution also prevents errors during process execution due to access control issues, given that clients only need to have the rights to execute the orchestration. This fact, also removes the need for the preliminary authorization checking. This solution also implies some changes in the SAML assertions. As stated before, the role of the client is used, within the InP, as the subject of the SAML assertions. With this new solution, this subject has to include the role associated to the orchestration, which can be seen as a “virtual role” for invoking atomic services. This change introduces the need to find a new way to propagate the original role of the client to the service providers. This can be solved by using an additional nonstandard attribute (e.g. ConsumerRole). Another requirement posed by this solution is the need to provide more information to the STS, so that it can generate the required assertion: the original assertion of the client is not enough. To address this issue, the BPEL-GW can generate an auxiliary assertion which specifies the new subject and the
additional attribute with the identity of the original client. This assertion has to be signed by the BPEL-GW, so that its request can be authenticated by the STS and it can also be identified and declared as a delegate in case of using the delegation mechanism. 4) Multi-audience token This solution alternative differs from the previous ones by reducing the number of tokens that the BPEL-GW has to request to the STS in order to invoke atomic services. The previous solution alternatives require that the BPELGW has to request various SAML tokens: one for each one of the services to invoke. These tokens differ from each other only in the target service specified by the audience element. An alternative to reduce the number of requested token is to use a single token which can be valid to invoke all the atomic services within an orchestration. This is allowed by SAML given that the element AudienceRestrictionCondition may include multiple audience elements. The advantage of this solution is that when an orchestration is executed, only one request is performed to the STS by the BPEL-GW and the obtained token is used for all the invocations that the BPEL Engine has to perform. In order to apply this solution, it is important to consider various aspects, in particular, regarding security issues. First, issuing a multi-audience token may require some modifications in the STS of the InP as well as in the token validation procedures of the Control Access Sytem. Second, given that the InP uses bearer tokens, someone who gets one can impersonate itself as the subject of that token, which presents a risk. Tokens are sent to service providers in the invocations, so it has to be considered the scenario where a provider, in a not legal way, may want to use one of these tokens. This risk is mitigated with the audience restriction which restricts the use of a token for the specified service. This way, a malicious provider may have a token which could only be used to invoke itself. However, when using tokens which are valid for various services (multi-audience tokens), the risk that a malicious provider could use a token to invoke any of the services specified in that token arises. Hence, some actions have to be taken in order to prevent a possible misuse of this kind of tokens. An alternative to address this issue is that the Access Control System verifies the origin of the request when these types of assertions are received. For example, in this case, the Access Control System may only admit this type of assertions when they come from the BPEL-GW. As explained in Section II.B, SAML contemplates this kind of situations by providing the SubjectConfirmation mechanism, in order to confirm that a message comes from the subject specified in the assertion. Some possible ways to use this mechanism are: i) specifying in the assertion the origin IP address by using the Address attribute of the SubjectConfirmationData, and ii) using a key (holder-of-key) to verify that the subject is the one that is sending the message: the subject has to probe that it holds a key, for example, by signing the request.
D. Other Aspects of the Solution This section presents and discusses some other aspects of the solution that were not addressed in the previous sections. 1) Propagation of other Types of Security Tokens The proposed solution also supports sending additional tokens, besides the SAML token of the platform, to the atomic services that may require them. To this end, the client has to include these tokens when invocating the orchestration and the solution propagates each additional token to the right service. More concretely, the BPEL engine propagates all the tokens sent by the clients and, in the post-processing chain of the BPEL-GW, a new component called TokenPropagationFilter examines the security headers and filters the ones not required by the invoked service. In order to be able to perform this filtering, the solution has to know the tokens to be sent to each service. To this end, it maintains information regarding which token (specified using XPATH) is required by each service. In addition, the “Actor” attribute defined in WS-Security can also be leveraged by clients to specify the target of a specific security header. Table II presents how the security tokens to be propagated for a specific service (ServiceA) are specified. In this example, all the security headers with a value “ServiceA” in their actor attribute, as well as the custom header called “CustomHeaderA” are propagated. TABLE II. Service
SPECIFYING ADDITIONAL SECURITY TOKENS Element to Propagate
Service A
//Envelope/Header/Security/@actor=”ServiceA”
Service A
//Envelope/Header/Security/CustomHeaderA
2) Confidenciality and Integrity As identified in Section II.F, the interactions between public agencies may have end-to-end confidentiality and integrity requirements. This section analyzes how these end-toend requirements, between a client which invokes an orchestration and a service composing it, can be fulfilled with the proposed solution and the message-level mechanisms provided by WS-Security. Regarding integrity, if a client sends a signed element when invoking an orchestration, this element has to be propagated to the corresponding service without any modification in order to preserve its integrity. In addition, the security headers associated with the signature (e.g. signature element, additional security tokens) have to be also propagated to the service. Indeed, the propagation of the signed element can be specified when designing the orchestration as part of the WS-BPEL definitions. Bear in mind that the propagation of the security headers can be performed as explained in the previous section. With respect to confidentiality, if a client sends an encrypted element (for a given service) when invoking an orchestration, this element has to be propagated to the corresponding service without modifications. Note that the BPEL Engine will not be able to handle the content of this
element given that it is encrypted. In addition, the security headers associated with the encrypted elements have to be also propagated to the service. The propagation of these elements and headers can be performed as in the case of the signed elements previously analyzed. E. Integrating all the Components of the Solution Throughout this section, different components and solution alternatives have been presented in order to deal with issues arising when orchestrating secure Web Services, in particular, within the InP. Taking as a basis the architecture proposed in Section III.B, these components and alternatives can be combined to build solutions with different characteristics. These different solutions can be achieved by adding or removing modules in the processing chains of the BPEL Gateway or by configuring certain aspects of these modules. As a summary, Fig. 6 describes, as an example, a possible configuration which addresses the requirements posed by the InP and presents the concrete actions that were used in the preprocessing and post-processing chains of the BPEL-GW. These actions implement the following solution alternatives: •
Obtaining a suitable SAML token for the invoked service using the TokenExchangeMediation component to interact with the STS
•
Identification of the intermediary by using delegated SAML assertions
•
Usage of a new role for orchestrations (as seen in Section III)
•
Propagation of additional security tokens using the TokenPropagationFilter component.
In addition, this configuration uses a module that generates an auxiliary SAML token that is used in the request sent to the STS. This token is used with authentication purposes and as a way of communication information regarding: i) the identity of the intermediary, ii) the identity of the original client, and iii) the role that was used in the invocation.
so that it does not have to be generated in every invocation of the BPEL Engine. The ServiceLocationMapper component is a type of content-based routing which according to the logical address of the service (specified in the request) obtains its real address and performs the corresponding routing to a BPEL Engine. This mechanism allows that orchestrations can be deployed and executed in different engines, providing some scalability characteristics to the solution. Finally, these two components show the flexibility and extensibility of the base solution, i.e. different capabilities can be incorporated by enabling, configuring or implementing components in the actions of the pre-processing and postprocessing chains of the BPEL-GW. F. Summary and Discussion The solutions proposed in this work address the orchestration of secure Web Services within the InP. Although, some characteristics of the solution are specific to this context, some of them may be also applied to other scenarios. The proposed general architecture provides a basis over which a standard BPEL engine can be complemented with mediation and integration capabilities. Also, the mediation flow design of the (pre and post) processing chains, included in the BPEL-GW, provides a solution where loosely coupled components can be used to solve different integration aspects (e.g. a token exchange with an STS). This leads to a flexible solution which can be configured by adding or removing components, in order to fulfill different types of requirements in diverse scenarios of secure Web Services orchestrations. Regarding deployment alternatives, although throughout the paper the solution was presented as deployed within the InP, it may be also placed outside of it (e.g. in a public agency). The proposal can be seen in this way as a more general solution to orchestrate Web Services which require security tokens using WS-Security and WS-Trust. In this sense the proposal provides solutions for two main general issues: • Invocation of secure Web Services by the orchestration engine: The proposal provides solution alternatives to deal with scenarios where the BPEL engine has to invoke services requiring security tokens which may be dynamically obtained at runtime using WS-Trust. In this scenario the proposal also analyzes and supports different types of security tokens (e.g. delegated assertions, multi-audience assertions).
Fig. 6. Integrating all the Components
The Cache component was introduced as a way to enhance the performance of the solution, avoiding unnecessary requests to the STS, in case that the orchestration uses more than once a specific service. It can also be used to store the auxiliary token
• Propagation of security information from the client to the services: The proposal also provides the mechanisms to propagate the identity and role of the client to the services. In addition, it also provides solutions to propagate additional security tokens to the specific services that may require them. This may be necessary, for example, in case encrypted or signed information is propagated to the service when there are end-to-end confidentiality or integrity requirements. These scenarios are supported by a component of the proposed solution (i.e. TokenPropagationFilter) as well as WS-Security specific mechanisms.
IV.
IMPLEMENTATION AND EVALUATION
This section provides details regarding the implementation and evaluation of the proposal. A. Implementation The proposal presented in this work was completely prototyped leveraging various specific products [17]. The prototype comprises two main components: the BPEL Engine and the BPEL Gateway. In addition, a utility tool was developed in order to facilitate some of the design and deployment activities. Finally, in order to be able to evaluate the solution as a whole, various components of the InP (e.g. the STS) were emulated. The BPEL Engine component is based on the Apache ODE product, which was mainly used with its default configuration and on top of the Apache Tomcat application server. Although, as stated before, the proposal is not tied to a particular BPEL engine, Apache ODE has some features which could be leveraged in the prototype. For example, ODE allows configuring the HTTP location where service invocations are sent. This was concretely used to route the requests, performed in the context of an orchestration, to the BPEL Gateway. Apache ODE also support the dynamic handling of SOAP headers [19]. This feature was leveraged to copy all the security headers sent by the clients before invoking each service of the orchestration. Note that these headers are then filtered in the BPEL-GW. The BPEL Gateway component was built on top of the JBoss ESB product. In particular, the pre and post processing chains were implemented as ESB services which allow specifying a mediation flow in terms of an actions pipeline. This way messages are processed by the specified actions in a sequential way. The main actions that were implemented are: • TokenExchangeMediation: This action was designed and implemented as a reusable component that can be used for token exchanges using WS-Trust. It gets the original token from the SOAP message and replaces it with a new token obtained from a STS. The design of this component was based on [18] and allows its design time configuration by specifying a set of properties (e.g. an address specifying the location of the STS, an XPath expression specifying the location of the original token in the SOAP message).
using information orchestration).
stored
when
deploying
Finally, a utility tool was also implemented with the aim of facilitating some design and deployment activities, which have to be carried out in order to use the proposed solution. Existing graphical tools (e.g. Eclipse BPEL Designer) can be leveraged to design an orchestration and generate its definition file. Then the utility tool (at deployment time) takes as input this definition file (.bpel) and enriches it by adding some tasks required by the proposed solution (e.g. a task to propagate the security tokens before invoking services). The tool also stores additional information of the orchestration, which is then required at execution time by the solution, and finally performs the deployment of the orchestration on the BPEL Engine. B. Evaluation In order to evaluate the proposal, a case study within an egovernment scenario was proposed, implemented as an orchestration and executed on top of the prototype, using a configuration like the one presented in Section III.E. This allowed verifying the technical feasibility of the proposal as well as evaluating different aspects of the solution. Regarding the security requirements, it was verified the successful integration of the solution with the authentication mechanisms of the InP. It was also verified that the solution allows the identification of the client as well as the identification of the BPEL Engine as an intermediary. In addition, all service invocations pass through the access control system, which allows auditing and controlling the access to services. Indeed, the solution behaves as expected in case of attempts of unauthorized accesses. Tests were also performed to evaluate the propagation of additional security tokens as well as the execution of concurrent orchestrations. Performance tests were also executed. Fig. 7 shows the processing time of several of the components of the solution. In particular, the STS is the component which requires more processing time, due to the cryptographic tasks associated with the generation and verification of signatures. In addition, the processing time associated to the BPEL engine is also considerable. Regarding the components of the BPEL Gateway, the only one which requires a relevant time is the TokenGenerator, again due to cryptographic tasks. Finally, the cache component seems to be a convenient option given the time required in the token generation and processing tasks.
• AuxiliaryTokenGenerator: This component was implemented in order to support one of the solution alternatives which requires the generation of an auxiliary token in order to request a new one to the STS. The implementation of this component was based on the OpenSAML product. • TokenPropagationFilter: This component processes SOAP messages by examining their security headers and removing the ones that should not be propagated in the invocation of a given service. To this end, the component determines the service that is being invoked (by examining the WS-Addressing headers of the SOAP message) and gets the list of items (specified with XPath) that must be propagated for that service (by
the
Fig. 7. Percentage of Time required by each activity
Note that the execution of the case study was not performed at the production or testing environment of the InP. On the contrary, it was performed within a prototype of the InP which was developed emulating various of its components using JBoss ESB. The case study was executed in a single PC with a core i5 processor and 8GB of RAM. JBoss AS was used to deploy the prototype of the platform and Apache Tomcat to deploy Apache ODE and the services. V.
RELATED WORK
This section presents related work on the orchestration of secure Web Services. It also reviews some e-government platforms and analyzes the support provided by some vendors for orchestrating secure Web Services. Although none of these initiatives provides a comprehensive solution for the requirements identified in Section II.F, there are some aspects of them that were leveraged in the proposed approach. With respect to the orchestration of secure Web Services, various proposals were found in the literature. In [20] the authors propose a method for modeling security constraints and a brokered architecture to build composite Web services considering the specified security constraints. It mainly focuses on the automatic generation of an orchestration based on a matchmaker component that considers security requirements of clients and providers. Even though this work deals with the composition of secure Web Services, it does not address the identified requirements. In particular, it does not provide solutions for orchestrating Web Services which use the WSSecurity and WS-Trust standards to provide security characteristics. In [21] an approach for identity and access management (IAM) in the context of a process-driven SOA is presented. In particular, the authors propose a domain-specific language (DSL) for RBAC that allows for the definition of IAM policies. These policies are used to annotate parts of WSBPEL process definitions which, at deployment time, are used to enhance these definitions with special activities to ensure the compliance with the IAM policies. Similar to the services of the InP, the services in this work require SAML tokens, in particular, containing the subject, the role and the context in which the invocation is performed (e.g. an emergency context). In case of a context change, the solution also requires requesting a new SAML token. While the type of scenario addressed in this work has some similarities with the InP, the solutions proposed do not deal with all the identified requirements. Still, some of the ideas of this work were leveraged in the proposed solution (e.g. the automatic enhancement of WS-BPEL process definitions, at deploy time, in order to deal with security characteristics). In addition, the BIS-Grid project [22] emerged with the purpose of integrating an orchestration engine to a Grid Computing platform, where services are stateful and require advanced security characteristics. The authors argue that a traditional BPEL Engine usually only allows the orchestration of stateless services and that they only support basic security characteristics. In order to address these issues they propose an additional service, which encapsulates a BPEL engine and intercepts all the message interchanges with clients and services. The advantage of this proposal is that neither nonstandard BPEL extensions are used nor the BPEL engine is
modified, which allows applying this solution with any WSBPEL compliant engine. Similar to the previous work, at deployment time, WS-BPEL definitions are enhanced with security related tasks. Even though this work does not address all of the identified requirements and specifically deals with stateful services, it deals with similar concerns to the ones arising within the InP, for example, the integration with security standards not natively supported by BPEL engines. Consequently, some of the solutions proposed in this work could be leveraged in the proposal, in particular, the usage of an additional service to perform security activities. Finally, in [23] the authors propose RBAC-WS-BPEL, an extended version of the WS-BPEL language that supports the specification of authorization information for WS-BPEL processes, and BPCL, a new XML-based language for describing authorization constraints. However, this work does not address either the integration with the advanced Web Services security standards required in the InP. In addition, there are various vendors which provide products (e.g. BPEL engines, ESBs) with features which can be used to support the orchestration of secure Web Services. Such is the case of IBM [27] and Oracle [28], which offer additional components to the BPEL engine in order to support some Web Services security standards. In addition, some IBM documentation [18] proposes the usage of the mediation characteristics of ESBs to perform security mediations, for example, to perform a token exchange with an STS. However, these solutions are implemented within specific products which, on the one hand, are not available at the InP and, on the other hand, do not provide solutions which can be applied with products of others vendors. These components do not provide either a comprehensive solution for the identified requirements; instead, they provide generic building blocks which can be used to build such comprehensive solution. Regarding the orchestration of services within egovernment platforms, various initiatives were analyzed [24][25][26]. In particular, the Platino Platform of the Canarias Government [25] provides considerable online documentation and presents some interesting characteristics, like the usage of the WS-Security standard and the Apache ODE BPEL Engine. However, solutions for orchestrating secure Web Services in this context were not specifically found. Finally, not much work was found regarding the usage of delegated SAML assertions. The main work [29] related to this topic that was found presents a case study within a healthcare scenario. In this scenario a node, acting as a gateway for accessing remote resources, uses a delegated assertion to act on behalf of a client. In particular, the "holder-of-key" method is used in this assertion as the subject confirmation mechanism. VI.
CONCLUSIONS AND FUTURE WORK
This paper presented solution alternatives for implementing orchestrations of secure Web Services within the Uruguayan Egovernment Interoperability Platform (InP). In particular, the solutions focused on solving issues regarding the integration with the Security System of the platform. The proposal, which leverages guidelines and ideas of other proposals and products, comprises a reference architecture
which provides a basis over which a standard BPEL engine can be complemented with mediation and integration capabilities. In addition, different components and solution alternatives were analyzed in order to deal with diverse issues arising when orchestrating secure Web Services within the InP. These components and alternatives can be combined to build solutions with different characteristics which allow dealing with diverse requirements. In addition, even though the solutions were proposed in the context of the Uruguayan E-government Platform, they may be applied in similar contexts or scenarios. Indeed, the proposal can be seen as a more general solution to orchestrate Web Services which require security tokens using WS-Security and WS-Trust. The proposal provides solutions for two main issues: invocation of secure Web Services by orchestration engines and propagation of security information from the client of an orchestration to the services which compose it. A complete prototype of the proposal was also developed using Apache ODE, as the WS-BPEL engine, and JBoss ESB. In addition, a case study within an e-government scenario was proposed, implemented as an orchestration and executed on top of the prototype. This allowed evaluating some aspects of the solution, for example, in terms of performance. The main contributions of this work are: i) the proposal of integral standard-based solutions for incorporating security characteristics in Web Services orchestrations, in particular, concerning authentication, authorization and auditing features, ii) prototypes which validate the technical feasibility of these solutions, iii) a test environment, based on the implemented prototypes, which provides an infrastructure for evaluating future characteristics of the InP or similar platforms, and iv) the foundation for developing orchestrations of secure Web Services in real world scenarios, in particular, within the InP. One line of future work will concentrate on performing a more exhaustive evaluation of the solution focusing on security and performance issues. In addition, other lines of work that may be addressed in the future are: i) a choreography-based approach, as described in [30], instead of a centralized approach for Web Services compositions, and ii) the impact of using advanced quality of service features, like transactional or reliable messaging support, in the proposed solution. REFERENCES [1]
[2] [3] [4]
[5] [6]
L. González, R. Ruggia, J. Abin, G. Llambías, R. Sosa, B. Rienzi, D. Bello, F. Alvarez. “A Service-oriented Integration Platform to Support a Joined-up E-government Approach: The Uruguayan Experience”. International Conference on Electronic Government, the Information Systems Perspective, and Electronic Democracy, Austria, 2012. “SOAP Specifications”, W3C, Apr. 2007. http://www.w3.org/TR/soap/. E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, “Web Services Description Language (WSDL) 1.1.” W3C, 15-Mar-2001. T. Erl, A. Karmarkar, P. Walmsley, H. Haas, L. U. Yalcinalp, K. Liu, D. Orchard, A. Tost, and J. Pasley, Web Service Contract Design and Versioning for SOA, 1st ed. Prentice Hall, 2008. “Web Services Addressing (WS-Addressing)”, W3C, Oct. 2004. http://www.w3.org/Submission/ws-addressing/. D. Chappell, Enterprise Service Bus: Theory in Practice. O’Reilly Media, 2004.
[7]
[8] [9] [10] [11] [12]
[13] [14]
[15] [16]
[17]
[18]
[19] [20]
[21]
[22] [23]
[24]
[25] [26] [27]
[28] [29]
[30]
M.-T. Schmidt, B. Hutchison, P. Lambros, and R. Phippen, “The enterprise service bus: making service-oriented architecture real,” IBM Syst. J., vol. 44, no. 4, pp. 781–797, 2005. M. Papazoglou, Web Services: Principles and Technology, 1st ed. Prentice Hall, 2007. T. Erl, SOA Design Patterns, 1st ed. Prentice Hall PTR, 2009. R. Kanneganti and P. A. Chodavarapu, SOA Security. Manning Publications, 2008. A. Singhal, T. Winograd, and K. Scarfone, “Guide to secure web services,” NIST Special Publication, vol. 800, no. 95, p. 4, 2007. “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0”, OASIS, March, 2005. http://docs.oasisopen.org/security/saml/v2.0/saml-core-2.0-os.pdf “PicketLink STS - SAML Profile| JBoss Community.” [Accessed: Apr 2014]. https://community.jboss.org/wiki/PicketLinkSTS-SAMLProfile. “SAML Condition for Delegation Restriction,” OASIS, 2009. http://docs.oasis-open.org/security/saml/Post2.0/sstc-samldelegation.html. [Accessed: Apr -2014]. “WS-BPEL Version 2.0” OASIS, April, 2007. http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html [Accessed: April-2014]. Silberman and Mandal, “Understanding web services specifications, Part 7: WS-Business Process Execution Language,” 10-May-2007. http://www.ibm.com/developerworks/webservices/tutorials/wsunderstand-web-services7/. [Accessed: Apr-2014]. M. Steffen and E. Penna "Orquestación de servicios en la plataforma de interoperabilidad de gobierno electrónico", Trabajo de fin de carrera, Laboratorio de Integracion de Sistemas, Instituto de Computación, Universidad de la Republica, Uruguay, 2013 A. Buecker, P. Ashley, M. Borrett, M. Lu, S. Muppidi, N. Readshaw, and I. B. M. Redbooks, Understanding SOA Security Design and Implementation. IBM Redbooks, 2008. “Apache ODE – Headers Handling.” [Accessed: Apr-2014]. https://ode.apache.org/extensions/headers-handling.html. B. Carminati, E. Ferrari, and P. C. K. Hung, “Security Conscious Web Service Composition,” in International Conference on Web Services, 2006. ICWS ’06, 2006, pp. 489–496. W. Hummer, P. Gaubatz, M. Strembeck, U. Zdun, and S. Dustdar, “An Integrated Approach for Identity and Access Management in a SOA Context,” 16th ACM Symposium on Access Control Models and Technologies, New York, NY, USA, 2011, pp. 21–30. “BIS-Grid: Grid-basierte Integration und Orchestrierung : Startseite.” http://bisgrid.d-grid.de/bi.offis.de/bisgrid/ [Accessed: Apr -2014]. E. Bertino, J. Crampton, and F. Paci, “Access Control and Authorization Constraints for WS-BPEL,” in International Conference on Web Services, 2006. ICWS ’06, 2006, pp. 275–284. “Modernización y Gobierno Electrónico” http://www.modernizacion.gob.cl/interoperabilidad/plataforma-deintegracionpisee/. [Accessed: Apr -2014]. “Platino: Plataforma de interoperabilidad del Gobierno de Canarias.” http://www.gobiernodecanarias.org/platino/. [Accessed: Apr -2014]. “Padrões de Interoperabilidade de Governo Eletrônico.” http://eping.governoeletronico.gov.br/. [Accessed: Apr -2014]. M. B. Juric, S. Chandrasekaran, A. Frece, G. Srdic, and M. Hertis, WSBPEL 2.0 for SOA Composite Applications with IBM WebSphere 7. Birmingham: Packt Publishing, 2010. “Oracle BPEL Process Manager.” [Accessed: April-2014] http://www.oracle.com/technetwork/middleware/bpel/overview/. M. Masi and R. Maurer, “On the Usage of SAML Delegate Assertions in an Healthcare Scenario with Federated Communities,” in Electronic Healthcare, vol. 69, M. Szomszor and P. Kostkova, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 212–220. V. Issarny, N. Georgantas, S. Hachem, A. Zarras, P. Vassiliadist, M. Autili, M. Gerosa, and A. Hamida, “Service-oriented middleware for the Future Internet: state of the art and research directions,” Journal of Internet Services and Applications, vol. 2, no. 1, pp. 23–45, 2011.
