Semantics-based design for Secure Web Services

Transcription

1 1 Semantics-based design for Secure Web Services Massimo Bartoetti Pierpaoo Degano Gian Luigi Ferrari Roberto Zunino Dipartimento di Informatica University of Pisa L.go Bruno Pontecorvo, Pisa, Itay Phone Fax

2 2 Abstract We outine a methodoogy for designing and composing services in a secure manner. In particuar, we are concerned with safety properties of service behaviour. Services can enforce security poicies ocay and can invoke other services that respect given security contracts. This ca-by-contract mechanism offers a significant set of opportunities, each driving secure ways to compose services. We discuss how to correcty pan services compositions in severa reevant casses of services and security properties. To this aim, we propose a graphica modeing framework, based on a foundationa cacuus caed λ req [13]. Our formaism features dynamic and static semantics, so aowing for forma reasoning about systems. Static anaysis and mode checking techniques provide the designer with usefu information to assess and fix possibe vunerabiities. Index Terms Web services, ca-by-contract, anguage-based security, static anaysis, system verification. I. INTRODUCTION Service-oriented computing (SOC) is an emerging paradigm to design distributed appications [42], [41], [25]. SOC appications are obtained by suitaby composing and coordinating (i.e. orchestrating) avaiabe services. Services are stand-aone computationa units distributed over a network, and made avaiabe through standard interaction mechanisms. Composition of services may require pecuiar mechanisms to hande compex interaction patterns (e.g. to impement transactions), whie enforcing non-functiona requirements on the system behaviour, ike e.g. security, avaiabiity, performance, transactionaity, quaity of service, etc. [46]. An important aspect is that services are open, in that they are buit with itte or no knowedge about their operating environment, their cients, and further services therein invoked. Web Services [2], [45], [48] buit upon XML technoogies are possiby the most iustrative and we deveoped exampe of the SOC paradigm. A variety of XML-based technoogies have been devised for describing, discovering and invoking web services [17], [19], [16], [49]. There are aso severa standards for defining and enforcing non-functiona requirements of services, e.g. WS-Security [4], WS- Trust [3] and WS-Poicy [47] among others. The success of the SOC paradigm is highy reated to the deveopment of network infrastructures supporting interoperabe and secure messaging among services, as we as high-eve

3 3 coordination standards. A further eement is the definition of nove methodoogies for modeing, anaysing and certifying SOC systems, see e.g. [26]. A chaenging issue for SOC research is how to compose existing services into more compex ones, aso by propery seecting and configuring services so to guarantee that their composition enjoys some desirabe properties. Non-functiona aspects, e.g security, make service composition even harder. From a methodoogica perspective, Software Engineering shoud faciitate the shift from traditiona approaches to the emerging service-oriented soutions. Aong these ines, one of the goas of this paper is to strenghten the adoption of forma techniques for modeing, designing and verifying SOC appications. In particuar, we propose a SOC modeing framework supporting history-based security and ca-by-contract. The starting point of our work is λ req [13], [8], a foundationa cacuus for describing, seecting and securey composing services. The execution of a program may invove accessing securitycritica resources; these actions are ogged into histories. The security mechanism may inspect these histories, and forbid those executions that woud vioate the prescribed poicies. The ca-bycontract seection mechanism impements a matchmaking agorithm based on service behaviour. This agorithm expoits static anaysis techniques to detect the pans for resoving the ca-bycontract invoved in a service orchestration. In our modeing framework, services are rendered as typed diagrams. Service interfaces extend the WSDL interfaces: besides the standard WSDL attributes, we add semantic information about service behaviour. In our mode, the pubished interface of a service is an annotated functiona type, of the form τ H 1 τ 2. Intuitivey, when suppied with an argument of type τ 1, the service evauates to an object of type τ 2. The annotation H is a sort of context-free grammar that describes a the possibe run-time histories of the services. Thus, H can be expoited to constrain the seection of a service that respects the desired security properties. Service interfaces are mechanicay inferred by a type and effect system. To seect a service that matches a given contract, a cient issues a request of the form. ϕ A request type τ = τ 1 τ2 matches those services with interface τ H 1 τ 2 whose abstract behaviour H respects the poicy ϕ. These services are guaranteed to respect ϕ in a the possibe executions. The seection agorithm searches a service repository for an interface matching the request type. Since service interactions may be compex, it might be the case that a oca choice for

4 4 a service is not secure in a broader, goba context. For instance, choosing a ow-security e- mai provider might prevent you from using a home-banking service that exchanges confidentia data through e-mai. In this case, you shoud have panned the seection of the e-mai and bank services so to ensure their compatibiity. To cope with this kind of issues, we define a static machinery that determines the viabe pans for seecting services that respect a the contracts, both ocay and gobay. The main contributions of the present paper are the foowing: 1) a forma modeing anguage for designing secure services. Our graphica formaism resembes UML activity diagrams, and it is used to describe the workfow of services. Besides the usua workfow operators, we can express activities subject to security constraints. The awareness of security from the eary stages of deveopment wi foster security through a the foowing phases of software production. Our diagrams have a forma operationa semantics, that specifies the dynamic behaviour of services. Moreover, diagrams can be staticay anaysed, to infer the contracts satisfied by a service. Our approach aows for a fine-grained characterization of the design choices that affect security (Section II). We support our proposa with some case study scenarios. 2) the integration of a verification technique to study composition properties of service networks. A static anaysis is used to infer an abstraction of the behaviour of a network. This abstraction is then mode-checked to construct a correct orchestrator that coordinates the running services in a secure manner. Secure orchestration wi aso aow for improving the overa performance by avoiding unnecessary dynamic security checks whie executing services. Studying the output of the mode-checker may highight possibe design faws, and suggest how to revise the cas-by-contract and the security poicies. A the above machinery is competey mechanizabe, and we are impementing a too to support our methodoogy. The fact that the too is based on strong theoretica grounds (i.e. λ req type and effect inference and verifier) positivey impacts the reiabiity to our approach. 3) a study of various panning and recovering strategies. We discuss severa situations in which one needs to take a decision before proceeding with the execution. For instance, when a panned service disappears unexpectedy, one can choose to repan, i.e. to adapt the current pan to the new network configuration. Depending on the boundary conditions and on past experience, one can choose among different tactics. We comment on the feasibiity,

5 5 advantages and costs of each of them. The paper is organized as foows. In Section II we introduce a taxonomy of security aspects in service-oriented appications. Section III, IV and V present our forma mode. In particuar, Section III introduces our design notation and the operationa semantics; Section IV presents service contracts, and outines how they can be automaticay inferred; Section V iustrates how to seect services under the ca-by-contract phiosophy, and discusses some panning and recovering strategies. Two scenarios for secure service composition are presented in Section VI. We concude the paper with some remarks (Section VII) about the expected impact of our methodoogy on Software Engineering, and we discuss some reated works. II. A TAXONOMY OF SECURITY ASPECTS IN WEB SERVICES Service composition heaviy depends on which information about a service is made pubic, on how to choose those services that match the user s requirements, and on their actua run-time behaviour. Security makes service composition even harder. Services may be offered by different providers, which ony partiay trust each other. On the one hand, providers have to guarantee that the deivered service respects a given security poicy, in any interaction with the operationa environment, and regardess of who actuay caed the service. On the other hand, cients may want to protect their sensitive data from the services invoked. In the history-based approach to security, the actua access rights of a running piece of code depend on (a suitabe abstraction of) the execution history of a the pieces of code run so far. This approach has been receiving major attention, both at the eve of foundations [5], [30], [44] and of anguage design and impementation [1], [27]. The observations of security-reevant activities, e.g. opening socket connections, reading and writing fies, accessing critica memory regions, are caed events. Histories are sequences of events. The cass of poicies we are concerned with is that of safety properties of histories, i.e. properties that are expressibe through finite state automata. The typica run-time mechanisms for enforcing history-based poicies are reference monitors, which observe program executions and abort them whenever about to vioate the given poicy. Reference monitors enforce exacty the cass of safety properties [43]. Since histories are the main ingredient of our security mode, our taxonomy speaks about how histories are handed and manipuated by services. We focus on the foowing aspects.

6 6 Stateess / statefu services A stateess service does not preserve its history across distinct invocations (yet it checks the history within each invocation). Instead, a statefu service keeps track of the histories of a the past invocations. Steteess services can enforce poicies that inspect the history of the current invocation ony, e.g. resource usage contro. Statefu services aow for more expressive security poicies: for instance, a statefu service can bound the number of invocations on a per-cient basis, whie a stateess service cannot. More in genera, statefu services can expoit their histories to record security-reevant information about the state of cient sessions. Consider for instance a service that requires password authentication, and that gives ony three chances per hour to authenticate. This can be modeed as a statefu service. In this case the history keeps track of the number of faied authentication attempts. The security poicy prevents the service from being used by a caer for which the history has recorded three faied authentication attempts in the ast hour. Athough stateess services admit security poicies that are ess expressive than those of statefu services, static anaysis can usuay infer enough information to ensure secure composition. For instance, consider a cient that wants to buy some pharmaceuticas through an onine vendor, whie being assured that his shopping ist is not eaked to other services (e.g. insurance companies). Staticay anaysing pharmacy services permits to match the cient with a service conforming to its requirements. This is because the information recorded in stateess histories is enough to show possibe eaks. Loca / goba histories Loca histories ony record the events generated by a service ocay on its site. Instead, a goba history may span over mutipe services. Loca histories are the most prudent choice when services do not trust other services, in particuar the histories they generate. In this case, a service ony trusts its own history but it cannot constrain the past history of its caers, e.g. to prevent that its cient has visited a maicious site. Goba histories instead require some trust reation among services: if a service A trusts B, then the history of A may comprise that of B, and so A may check poicies on the behaviour of B. For instance, consider an aiance of services trusting each other, that wish to impement a distributed back-ist. More in detai, when any of the services in the aiance back-ists (through a suitabe event in the history) an externa service, then a the aiance must abstain from invoking that externa service. This can be impemented

7 7 by making the services in the aiance share a goba history. Before invoking an externa service, the caer inspects the goba history to find whether it has been back-isted beforehand. Note that the trust reationship among the services in the aiance is crucia: even a singe untrusted service coud compromise the security of the aiance, by maiciousy modifying the goba history. To securey impement the goba history, i.e. to protect its integrity, communication between services is done through suitabe cryptographic protocos. These protocos must be designed to be coherent with the existing trust reationship, e.g. signed histories are considered reiabe ony if the signer is trusted [51]. First order / higher order requests A request type τ ϕ τ is first order when both τ and τ are base types (Int, Boo, etc.). Instead, if τ or τ are functiona types, the request is higher order. In particuar, if the parameter (of type τ) is a function, then the cient passes some code to be possiby executed by the requested service. Symmetricay, if τ is a function type, then the service returns back some code to the caer. Mobiity of code impacts the way histories are generated, and demands for particuar mechanisms to enforce security on the site where the code is run. A typica protection mechanism is sandboxing, that consists in wrapping code within an execution monitor that enforces a given security poicy. When there is no mobie code, more efficient mechanisms can be devised, e.g. oca checks on security-critica operations. For instance, Java Appets are mobie code appications running on the cient browser, and they can be invoked through higher order requests. A browser cas a service that returns an appet; the browser runs then the appet, whie enforcing its own security poicy, e.g. the standard Java sandboxing. Actuay, history-based security is more genera than Java, since it checks the a the past execution history, whie Java ony checks the frames in the ca stack [34]. Higher order requests aso aow a cient to pass some mobie code as a parameter to a service. The execution of that code can be constrained both by the cient and by the service, by suitabe poicies imposed on its execution. Dependent / independent threads In a network of services, severa threads may run concurrenty and compete for services. A thread is a computation started from a particuar initiator service in the network. Roughy, initiator services are those deegated by the active actors to attain a given goa. Independent

8 8 threads keep execution histories separated, whie dependent threads may share part of their histories Therefore, dependent threads may infuence each other when using the same service, whie independent threads cannot. Impementing independent threads requires that each service records the history of each thread that invoked that service, i.e. services actuay maintain a mapping from thread initiators to their histories. For instance, consider a service that can be invoked ony once. If threads are independent, this one-shot service has no way to enforce singe use. It can ony check that no thread uses it more than once, because each thread keeps its own history. Dependent threads are necessary to correcty impement the one-shot service. III. SERVICES The basic entity in our graphica formaism is that of service. We sha first describe the syntax of services, and then study how they behave when pugged into a network. A service is represented as a box containing its code. The four corners of the box are decorated with information about the service interface and behaviour. The abe : τ indicates the ocation where the service is made avaiabe, and its certified pubished interface τ (discussed ater on in Section IV). The other abes instead are used to represent the state of a service at run-time. : τ π : τ service ocation + interface τ π orchestration pan B event history (m, Φ) monitor fag m + sequence Φ of active poicies (m, Φ) B service code Fig. 1. Execution state of a service. The abe is an abstraction of the service execution history. In particuar, we are concerned with the sequence of security-reevant events happened sometimes in the past, in the spirit of history-based security [1]. The abe (m, Φ) is a pair, where the first eement is a fag m representing the on/off status of the execution monitor, and the second eement is the sequence ϕ 1 ϕ k of active security poicies. The monitor must check that services adhere to each poicy ϕ i, for i 1..k, when the fag is on. Security poicies are modeed as reguar properties

9 9 of event histories, i.e. properties that are recognizabe by a finite state automaton. Athough the soundness of our design and anaysis techniques does not depend on the ogic chosen for expressing reguar properties of histories, we find it convenient to express poicies through our tempate security automata (see beow). The abe π is the pan used for resoving service choices. A pan formaises how a caby-contract is transformed into a ca-by-name. Pans may come in severa different shapes [11]. Here we focus on a very simpe form of pans, i.e. mappings from request abes r to service ocations. We represent pans with the syntax defined in Fig. 2. π,π ::= 0 empty r[] service choice r[?] unresoved choice π π composition Fig. 2. Syntax of pans. The empty pan 0 has no choices; the pan r[] associates the service pubished at site with the request abeed r. A pan is compete when it has no unresoved choices. Composition on pans is associative, commutative and idempotent, and its identity is the empty pan 0. Since pans are functions, they have a singe choice for each request, i.e. r[] r[ ] impies =. The abe B inside the box is a bock that describes the workfow behaviour of the service, in particuar of the security-reevant activities. Formay, B it is a contro fow graph [40] with nodes modeing activities, and arrows modeing intra-procedura fow. The syntax of activities and fow graphs are defined in Fig. 3, whie Fig. 4 summarizes the reevant syntactic categories. Activities comprise basic activities, events, requests, security bocks, and panning bocks. A basic activity a is an interna computation that does not affect security-critica objects. For instance, evauating a booean or arithmetic expression are basic activities. An event α(o) abstracts from a security-critica action α performed on an object o. For instance, write(foo) for writing the fie foo, sgn() for a certificate signed by, etc. We simpy write α when the target object is immateria. A service request takes the form. The abe r uniquey identifies the request in a

10 10 A ::= activities a basic activity α(o) event request ϕ[b] security bock {B} panning bock B = (N, Λ, ) service fow graph where N finite set of nodes Λ : N A abeing function N N set of arrows Fig. 3. Syntax of services. network of services, and the request type τ is defined by: τ ::= b τ ϕ τ where b is a base type (Int,Boo,void,...). The annotation ϕ on the arrow is the query pattern (or contract ) to be matched by the invoked service. For instance, the request type τ ϕ τ matches services with functiona type τ τ, and whose behaviour respects the poicy ϕ. A security bock ϕ[b] annotates B with the poicy ϕ, with the intention that ϕ must be obeyed whie running B. This can be accompished by enabing the execution monitor, that checks the history against ϕ at each step of the execution of B. We sha see ater on a static anaysis of services that wi aow to turn off the execution monitor, whie guaranteeing that the poicy ϕ is obeyed. A panning bock {B} constructs a pan for the execution of B (see Section V for more detais on how this is accompished). Both kinds of bocks can be nested, and they determine the scope of poicies (hence caed oca poicies [7]) and of panning. Service fow graphs B = (N, Λ, ) are directed graphs, where N is the (finite) set of nodes, Λ is a function that maps nodes to activities, and is the set of arrows. Note that oops are

11 11 o,o,... Obj Objects (a finite set) α,α,... Act Actions (a finite set) α(o),... Ev = Act Obj Events,,... Ev Histories (finite sequences of events) ϕ,ϕ,... Po Poicies (reguar properties of histories) r,r,... Req Request abes,,... Loc Service Locations π,π,... Req Loc Pans (functions from Req to Loc) Fig. 4. Syntactic categories. permitted in fow graphs, to mode iterative computations. We assume that each graph has a singe entry node, and a singe exit node. This graphica formaism is based on λ req, a ca-by-vaue λ-cacuus enriched with oca security poicies and ca-by-contract service requests. Since our main focus is on secure composition, in the graphica mode we do not render a the features of λ req. In particuar, we negect variabes, higher-order functions, and parameter passing. However, we fee free to use these features in our exampes, because their treatment can be directy inherited from λ req. Semantics of services We formay define the behaviour of services through a graph rewriting semantics [6]. In this section, we assume that the services which initiate a computation are furnished with an arbitrary pan. In the next section, we sha discuss a static machinery that wi enabe us to construct these pans so to guarantee that computations wi never go wrong, i.e. they satisfy a the contracts and the security poicies on demand. We sha aso show some strategies to adopt when services disappear unexpectedy (Section V). The graph rewriting semantics for the case of dependent threads is spit in two parts: basic activities, events, security bocks, requests and returns are shown in Fig. 5. Instead, Fig. 10 detais the rues that invove panning and recovering strategies, i.e. panning bocks, requests to unavaiabe services, unresoved requests, services going down and up, and pubication of new services. We sha briefy discuss the case of independent threads beow in this section.

12 12 A the remaining axes in the taxonomy are covered by our semantics When irreevant, we omit the abe τ in services. Note that the actua vaues for some abes in rues REQ and RET are defined ater on in Fig. 6, since they depend on the choice made on the security aspects discussed in Section II. This gives rise to different behaviours of requests and returns according to the possibe choices in the taxonomy. The configurations of our semantics are sets (i.e. networks) of services. We mark the next activity to be performed by a running service with an overine, e.g. α(o) means that the event α(o) is about to be fired. An activity just executed is marked with an underine, e.g. α(o). We extend this notation to bocks B, i.e. B means that the entry node of B is the next activity, whie B means that the exit node of B was the ast executed one. Aso, configurations comprise dashed arrows that connect a running request with the invoked service. We now briefy discuss the graph rewritings in Fig. 5. Note that we ony depict rewriting within a context. For instance, the rewriting a a in the SKIP rue can be appied in any context, i.e. within any bock B containing a. A basic activity is just passed over (rue SKIP). The evauation of an event α(o) requires checking compiance of the new history α(o) with each poicy ϕ in Φ (denoted α(o) = Φ), if the execution monitor is on. If a the poicies are respected (rue EV), then α(o) is appended to the current history, and the execution proceeds to the next bock. Otherwise, if some poicy is vioated (rue FAIL), then the execution goes into a stuck state fai. This state modes a security exception (for simpicity, we do not mode here exception handing; extending our formaism in this direction woud require to define, among the other things, how to compensate from aborted computations, e.g. ike in Sagas [32], [20]) The rue SEQ says that, after a bock B has been evauated, the next activity is chosen among the bocks with incoming arrows from B. Note that branching is a specia case of SEQ, where the bock B is a conditiona or a switch. Entering a security bock ϕ[b] resuts in appending the poicy ϕ to the sequence of active poicies. Leaving ϕ[b] removes ϕ from the sequence. In both cases, as soon as a history is found not to respect ϕ, and the execution monitor is on, the evauation gets stuck. A request under a pan r[ ] π ooks for the service at site. If the service is avaiabe (rue REQ), then the cient estabishes a session with that service (dashed arrow),

13 13 π π π π a SKIP a B SEQ B B i B i (m, Φ) (m,φ) (m, Φ) (m, Φ) π π π π α(o) EV α(o) α(o) FAIL fai (m,φ) if m is on, α(o) = Φ α(o) (m,φ) (m, Φ) m is on, α(o) = Φ (m, Φ) π π π π ϕ[b] SECIN ϕ[b] ϕ[b] SECOUT ϕ[b] (m, Φ) (m, Φϕ) (m, Φϕ) (m, Φ) r[ ] π r[ ] π r[ ] π B REQ B, Φ in Fig. 6 (m,φ) (m, Φ) (m, Φ ) π π π B RET B in Fig. 6 (m,φ) (m, Φ ) (m, Φ) Fig. 5. Semantics of services in the case of dependent threads (Part I). and waits unti it returns. Note that the meaning of the abes and Φ is eft undefined in Fig. 5, since it depends on the choice made on the security aspects discussed in Section II. The actua vaues for the undefined abes are shown in Fig. 6. In particuar, the initia history of the invoked service is: (i) empty, if the service is stateess with oca history; (ii)

14 14 REQ Stateess service Statefu service Loca histories Goba histories Loca histories Goba histories = ε = = = Φ = ε Φ = Φ Φ = ε Φ = Φ RET = = = = Fig. 6. Histories and poicies in four cases of the taxonomy. the invoker history, if the service has a goba history; (iii) the service past history, if the service is statefu, with oca history. Returning from a request (rue RET) requires suitaby updating the history of the caer service, according to chosen axes in the taxonomy. The actua vaues for the history are defined in Fig. 6. The cases N/A, PLG IN, PLG OUT and UNRES are defined in Fig. 10, and they have many possibe choices. When no service is avaiabe for a request (e.g. because the pan is incompete, or because the panned service is down), or when you have to construct a pan for a bock, the execution may proceed according to one of the strategies discussed in Section V. A pan is viabe when it drives no stuck computations (uness some service mentioned in the pan becomes unavaiabe). Under a viabe pan, a service can aways proceed its execution without attempting to vioate some security poicy (therefore the execution monitor is unneeded), and it wi aways manage to resove each request. The static machinery described in Section IV discovers viabe pans. An exampe Consider a network composed by two services at ocations and, both statefu and sharing a goba history. The service at starts with an action α (the omitted target object is immateria in this exampe), and then issues a request r, resoved to by the provided pan. The service at performs α within a security bock ϕ[ ], where the poicy ϕ prevents α from being fired twice. A computation of the network is depicted in Fig. 7, where we assume the execution monitor is on. Note that the pan r[ ] is not viabe, because it drives a computation that fais because of an attempted security vioation, right before the second α is fired at.

15 15 r[ ] r[ ] α ϕ[α] EV α ϕ[α] SEQ ε (on, ) ε α (on, ) ε r[ ] r[ ] r[ ] α ϕ[α] REQ α ϕ[α] SECIN α (on, ) ε α (on, ) α (on, ) r[ ] r[ ] r[ ] r[ ] α ϕ[α] FAIL α fai αα = ϕ α (on, ) α (on, ϕ) α (on, ) α (on, ϕ) Fig. 7. A computation of two statefu services with goba history. Independent threads To mode independent threads, each service must keep a separate history for each thread. Equivaenty, we keep a history for each thread initiator. To this aim, instead of a singe history, services now carry a function L mapping the abe I of each initiator to its corresponding history. Moreover, we keep track of the initiator name: each service invoked on behaf of the initiator I is tagged as such. The semantics of services can now be easiy adapted, making L( I ) pay the roe of in the semantics for dependent threads. We depict in Fig. 8 the rue REQ for independent threads. The reation among,, Φ and Φ is sti the one defined by Fig. 6. Note that is used to update L( I ), ony: a other histories in L are eft unchanged. The rue RET is deat with simiary, as for the rues FAIL, PLG IN and PLG OUT. Modeing security poicies Security poicies ϕ are reguar properties of histories, and they are defined through tempate security automata A ϕ(x). A tempate security automaton gives rise to a finite state automaton

16 16 r[ ] π r[ ] π r[ ] π B REQ B = L( I) I, Φ in Fig. 6 I I L (m, Φ) L L = L{ I } L (m, Φ) L (m, Φ ) Fig. 8. Maintaining separate histories in the case of independent threads. when the parameter x is instantiated to an actua object o. These automata wi be expoited to recognize those histories obeying ϕ. Formay, a tempate security automaton A ϕ(x) is a 5-tupe (S,Q,q 0,F,E), where x is a parameter, and: S Act (Obj {x, x}) is the input aphabet, Q is a finite set of states, q 0 Q \ F is the start state, F Q is the set of fina offending states, E Q S Q is a finite set of tempate edges, written q ϑ q. The edges in a tempate security automaton can be of three kinds: either q α(o) q where o is an object, or q α(x) q, or q α( x) q (where x means different from x ). Given a object o Obj, a tempate security automaton A ϕ(x) is instantiated into a finite state automaton A ϕ(o) by binding the variabe x to o. The intuition is that q α(x) q wi resut in an actua transition q α(o) q, whie q α( x) q wi give rise to a finite set of transitions q α(o ) q, for a o Obj \ {o}. More formay, et A ϕ(x) = (S,Q,q 0,F,E) be a tempate security automaton, and et o Obj. The finite state automaton A ϕ(o) is defined by the 5-tupe (Ev,Q,q 0,F,δ), where the transition reation δ is defined as foows: δ = δ {q α(o ) q o Obj, q : q α(o ) q δ }

17 17 where the auxiiary reation δ is defined as: δ = {q α(o) q q α(x) q E } o Obj\{o} {q α(o ) q q α( x) q E } {q α(o ) q q α(o ) q E } Note that the definition for δ adds sef-oops for a the events not expicity mentioned in the tempate automaton A ϕ(x). We say that a history respects ϕ, written = ϕ, when is not in the anguage of A ϕ(o), for a o Obj. When is in the anguage of A ϕ(o) for some object o, we say that vioates ϕ, written = ϕ. Note that instantiated tempate security automata are non-deterministic. Given a history and a poicy ϕ, we want that a the traces of the instances of A ϕ(x) compy with ϕ. This is a form of diaboic (or interna) non-determinism. To account for that, we make the offending states as fina thus going into a fina state represents a vioation of the poicy, whie the other states mean compiance to the poicy. IV. CALL-BY-CONTRACT A service B is pugged into a network by pubishing it at a site, together with its interface τ. We assume that each site pubishes a singe service, and that interfaces are certified, e.g. they are inferred by the type and effect system simiar to that in [13]. Aso, we assume that services cannot invoke each other circuary, since this is quite unusua in the SOC scenario. Contracts The types τ are annotated with history expressions H that over-approximate the possibe runtime histories. Fig. 9 dispays the syntax of types and history expressions. When a service with interface τ H τ is run, it wi generate one of the histories denoted by H. Note that we overoad the symbo τ to range over both service types and request types τ ϕ τ. History expressions, defined in Fig. 9, are a sort of context-free grammars. They incude the empty history ε, events α, and H H that represents sequentiaization of code, H + H for branching, security bocks ϕ[h], recursion µh.h (µ binds the occurrences of the variabe h in H), ocaization : H, and panned seection {π 1 H 1 π k H k }.

18 18 τ,τ ::= types b base type τ H τ annotated functiona type H,H ::= history expressions ε empty h variabe α(o) event H H sequence H + H choice ϕ[h] security bock µh.h recursion : H ocaization {π 1 H 1 π k H k } panned seection Fig. 9. Service interfaces: annotated types and history expressions The semantics of a history expression is a set of histories, possiby carrying security annotations in the form ϕ[]. We denote by H the semantics of H. We now briefy describe how this semantics is constructed: see [8] for the forma treatment. The semantics of the history expression α is the set of histories {α}. The semantics of H H is the set of histories such that H and H. The semantics of H + H comprises the histories such that H H. The semantics of ϕ[h] is the set of histories ϕ[] such that H. The semantics of µh.h is the east fixed point of the operator f(h) = H {H/h}, where we denote with H ρ the semantics of a history expression H in an environment ρ, mapping variabes h to sets of histories. For instance, the semantics of µh. (γ + α h β) consists of a the histories α n γβ n, for n 0 (i.e. γ, αγβ, ααγββ,...). The construct : H ocaizes the behaviour H to the site. E.g., : α ( : α ) β denotes two histories: αβ occurring at ocation, and α occurring at. A panned seection abstracts the behaviour of service requests. Given a pan π, a panned

19 19 seection {π 1 H 1 π k H k } chooses those H i such that π incudes π i. Intuitivey, the history expression H = {r[ 1 ] H 1,r[ 2 ] H 2 } is associated with a request r that can be resoved into either 1 or 2. The histories denoted by H depend on the given pan π: if π chooses 1 (resp. 2 ) for r, then H denotes one of the histories represented by H 1 (resp. H 2 ). If π does not choose either 1 or 2, then H denotes no histories. Certifying contracts and panning Our panning and verification technique for services is inherited from that of the λ req cacuus. The interested reader can find the forma foundations of our work in [10], [8]. Here, we ony summarize the reevant resuts for our present modeing framework. A static anaysis over our diagrams infers judgements of the form H B : τ. Roughy, this means that the service with code B has type τ, and its execution histories are represented by the history expression H. This static anaysys enjoys two fundamenta resuts. Correctness. Effects correcty over-approximate service run-time histories More formay, consider a service with code B such that H B : τ. If running the service (pugged into a network) generates a history, then B ([8], Th. 1). The second property of our static anaysis is type safety. We say that an effect H is vaid under a pan π when the histories denoted by H never vioate the security poicies in H. Type safety ensures that, if (staticay) the effect of a service B is vaid under a pan π, then (dynamicay) the pan π is viabe for B. Type safety. Vaid effects drive computations that never attempt security vioations. More formay, consider a service with code B such that H B : τ. If H is vaid under π, then the execution is secure (i.e. = Φ whenever a running service carries abes and (m, Φ)), and it never reaches a fai configuration. Moreover, if π is compete (i.e. it has no unresoved choices r[?]) and the chosen services do not disappear, then the execution monitor can be safey kept off ([8], Th. 2). A further resut is that the vaidity of history expressions can be mechanicay verified.

20 20 Mode-checking. Vaidity for history expressions is mode-checkabe. The actua mode-checking agorithm for the vaidity of H returns the set of pans under which H is vaid. Determining such viabe pans is not a trivia task: indeed, resoving requests independenty might not ead to a viabe pan, as discussed in the introduction. Our modechecking technique requires severa preiminary steps. Technicay, we first inearize the history expression H to coect a the pans and the associated effects, whie preserving the semantics of H ([8], Ths. 4 and 5). The resuting history expression has the form of a singe, top-eve panned seection {π 1 H 1 π k H k }. We can then check each H i independenty. First, H i is reguarized to remove the redundant framings ϕ[ ϕ[ ] ] ([8], Th. 6). This makes possibe to construct a finite state automaton that recognizes the vaidity of histories ([8], Lemma 8). This finite state automaton is then used in the actua mode-checking of H i ([8], Th. 8). If H i mode-checks, then the associated pan π i is viabe. Summing up: Panning = Correctness + Type Safety + Mode Checking V. PLANNING AND RECOVERING STRATEGIES We now consider the probem of choosing the appropriate service for a bock of requests. Whie one might defer service seection as much as possibe, thus ony performing it when executing a request, it is usuay advantageous to decide how to resove requests in advance, i.e. to buid a pan. This is because eary panning can provide better guarantees than ate service seection. For instance, consider a bock with two consecutive requests r 1 and r 2. It might be that, if we choose to resove r 1 with a particuar service 1, ater on we wi not be abe to find safe choices for r 2. In this case we get stuck, and we must somehow escape from this deadend, possiby with some expensive compensation (e.g. canceing a reservation). Eary panning, instead, can spot this kind of probems and try to find a better way, typicay by considering aso r 2 when taking a choice for r 1. As seen in the previous section, a compete viabe pan π for a bock B guarantees that B can be securey executed without execution monitoring, and that we wi never get stuck uness a service mentioned in π becomes unavaiabe. When we cannot find a compete viabe pan, we

21 21 coud fa back to using an incompete pan with unresoved requests r[?]. In this case, we get a weaker guarantee than the one above, namey that we wi not get stuck unti an unresoved request must actuay be executed. To provide gracefu degradation in our mode, we aso consider the unfortunate case of executing a request r when either r is sti unresoved in the pan (Rue UNRES), or r is resoved with an unavaiabe service (Rue N/A, for Not Avaiabe). Notationay, unavaiabe services are represented as sashed boxes. Therefore, we wi ook for a way to continue the execution, possiby repairing the pan. Figure 10 formaizes the behaviour of services reated to panning and recovering. Rue DOWN modes an ide service becoming unavaiabe. For simpicity, we assume that services cannot become unavaiabe whie serving a request. Unavaiabe services are modeed as sashed boxes. Rue UP modes an unavaiabe service going back to the avaiabe state. Rue PUB is for service pubishing. The behavioura interface τ of a new service (with code B) must be staticay certified, written H B : τ. Note that H = ε for non-initiator services. The effect of an invoked service with type τ = τ 0 H τ 1 is the atent effect H. Rue N/A modes a request to an unavaiabe service. Recovering from this situation demands for updating the current pan, and possiby activating the execution monitor. Beow in this section we sha examine some possibe strategies for doing that. Rue UNRES handes the case of unresoved requests. These are deat with simiary to the rue N/A. Rue PLN IN describes which actions have to be taken when entering a panning bock {B}. Before start the execution of B, we need to devise a pan for resoving the service requests in B. Again, severa strategies are appicabe, as discussed beow. Rue PLN OUT simpy exits from a panning bock. This operation affects neither the pan nor the execution monitor. We now discuss some strategies for constructing or repairing a pan. As a matter of fact, no strategy is aways better than the others, since each of them has advantages and disadvantages, as we wi point out. The choice of a given strategy depends on many factors, some of which ie outside of our forma mode (e.g. avaiabiity of services, cost of dynamic checking, etc.). We devise four main casses of strategies:

22 22 B DOWN B B UP B : τ r[?] π π H B : τ fresh PUB ε B (m, Φ) UNRES π, m, Φ in Fig. 11 (m, Φ ) r[ ] π π N/A π, m, Φ (m,φ) in Fig. 11 (m, Φ ) π π π π {B} PLNIN {B} {B} PLNOUT {B} π, m, Φ (m,φ) in Fig. 12 (m, Φ ) (m,φ) (m, Φ) Fig. 10. Semantics of services in the case of dependent threads (Part II). Greyfriars Bobby. 1 Foow oyay a former pan. If a service becomes unavaiabe, just wait unti it comes back again. This strategy is aways safe, athough it might obviousy bock the execution for an arbitrariy ong time possiby forever. Patch. Try to reuse as much as possibe the current pan. Repace the unavaiabe services with avaiabe ones, possiby newy discovered. The new services must be verified for compatibiity with the rest of the pan. 1 In 1858, a man named John Gray was buried in od Greyfriars Churchyard in Edinburgh. The famous Skye Terrier, Greyfriars Bobby was so faithfu to his master that for fourteen years, unti his own death, Bobby ay on the grave ony eaving for food.

23 23 Sandbox. Try to proceed with the execution monitor turned on. The new pan ony respects a weak form of compatibiity on types ignoring the effect H, but it does not guarantee that contracts and security poicies are aways respected. Turning on the execution monitor ensures that there wi not be security vioations, but execution might get stuck ater on, because of attempted insecure actions. Repan. Try to reconstruct the whoe pan, possiby expoiting newy discovered services. If a viabe pan is found, then you may proceed running with the execution monitor turned off. A compete pan guarantees that contracts and security poicies wi be aways respected, provided than none of the services mentioned in the pan disappear. In Fig. 11, we describe the effects of these strategies in the context of the N/A and UNRES rues. There, we aso make precise the recovered pan π and the (m, Φ ) appearing in the rue. For the Greyfiars Bobby strategy, we patienty wait for the service to reappear; on timeout, we wi try another strategy. The Patch strategy mends the current pan with a oca fix. Note that the Patch strategy is not aways safe: in the genera case, it is impossibe to change just the way to resove the faiing request r and have a new safe pan. We sha return on this issue ater on. However, as the figure shows, in some cases this is indeed possibe, provided that the pan with the new choice for r is checked for vaidity. The Repan strategy is safe when a suitabe pan is found, but it coud invove staticay re-anaysing a arge portion of the system. When a ese fais, it is possibe to run a service under a Sandbox, hoping that we wi not get stuck. From now onwards, we use the foowing abbreviations for the various aternatives described in Section II: stateess (1) / statefu (ω), oca (L) / goba (G), first order (F) / higher-order (H), dependent (D) / independent (I). For instance, the case IFL1 in the figure is the one about independent threads, first order requests, oca histories, and stateess services. In Fig. 12 we ist the strategies for the rue PLN IN, describing how to buid a pan for a bock B. Note that, when we construct a new pan π we aready have a pan π π B, where π B ony pans the requests inside B. We can then reuse the avaiabe information in π and π B to buid π. The former pan π π B can be non-empty when using nested panning bocks, so reusing parts from it is indeed possibe. Since we can reuse the od pan, the strategies are exacty the same of those for the N/A case. The Greyfriars Bobby strategy waits for a the services mentioned in the od pan to be avaiabe at panning time. This is because it might be wise not to start the bock, if we know

24 24 STRATEGY STATE UPDATE CASE CONDITION Greyfriars Bobby Patch Sandbox Repan π Φ π r[ i ] Φ π r[ i ] (on, Φϕ) π (off, Φϕ) a The current pan π has a choice for r IFL1 ϕ[h i ] is vaid IFLω ϕ[h i ] is vaid, and i π IFG1 ϕ[h i ] is vaid DFL1 ϕ[h i ] is vaid a The service i has type τ τ a The new pan π has a choice for r Fig. 11. Faiure handing strategies for a request ϕ τ. that we wi ikey get stuck ater. Instead, if some services keep on being unavaiabe, we shoud rather consider the other strategies. As for the N/A rue, the Patch strategy is not aways safe, but we can sti give some conditions that guarantee the safety of the pan update, which is oca to the bock B. The Repan strategy, instead, can change the whoe pan, even for the requests outside B. If possibe, we shoud aways find a compete pan. When this is not the case, we might proceed with some unresoved requests r[?], deferring them to the N/A rue. As a ast resort, when no viabe pan can be found, or when we deem Repan to be too expensive, we can adopt the Sandbox strategy that turns on the execution monitor. We now show a situation where the Patch strategy is not safe. We consider the case IFLω case (independent threads, first order requests, oca histories, statefu services). The initiator service, in the midde of Fig. 13, performs two requests r 1 and r 2 in sequence. The two requests have the same contract, and thus they can be resoved with the statefu services 1 and 2. The service at 2 performs an event α, within a security bock ϕ. If ϕ aows a singe occurrence of α, we shoud be carefu and invoke the (statefu) service 2 at most once. The current pan π = r 1 [ 1 ] r 2 [ 2 ] is safe, since it invokes 2 exacty once.

25 25 STRATEGY STATE UPDATE CASE CONDITION Greyfriars Bobby π π B Φ a The pan π B has a choice for a r i IFL1 ϕ[h i ] is vaid, for a i Patch π r i [ i ] Φ IFLω IFG1 ϕ i [H i ] are vaid, i are distinct, and a i π i ϕ i [H i ] are vaid, for a i DFL1 ϕ i [H i ] are vaid, for a i Sandbox π r i [ i ] (on, Φϕ) a The services i have type τ i τ i H vaid under π, where Repan π (off, Φϕ) a is the current history, and H approximates the future behaviour (may need to refine the anaysis) Fig. 12. ϕ Panning strategies for a bock B invoving requests req ri τ i i τ i 1 : τ : τ r 1[ 1] r 2[ 2] 2 : τ req r1 τ req r2 τ ϕ[α] 1 (m 1, Φ 1) (m, Φ) 2 (m 2, Φ 2) Fig. 13. An unsafe use of the Patch strategy. Now, consider what happens if the service 1 becomes unavaiabe. The N/A rue is triggered: if we appy Patch and repace the current pan with r 1 [ 2 ] r 2 [ 2 ], then this patched pan is not viabe. Indeed, the new pan invokes 2 twice, so vioating ϕ. The safety condition in Fig. 11 is fase, because 2 π: therefore, this dangerous patch is correcty avoided.

26 r[ 1] r [ 2] >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] PLNIN 8 >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] REQ ε (off, ) ε ε ε (off, ) ε ε 0 r[ 1] r [ 2] 1 r[ 1] r [ 2] 2 0 r[ 1] r [ 2] 1 r[ 1] r [ 2] 2 8 >< >: req r τ 9 >= >; 2 ϕ6 4 act α β ϕ[α] SECIN SKIP SEQ EV SECOUT 8 >< >: req r τ 9 >= >; 2 ϕ6 4 act α β ϕ[α] RET DOWN ε (off, ) ε (off, ) ε ε (off, ) α (off, ) ε 0 r[ 1] r [ 2] r[ 1] r [ 1] >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] N/A 8 >< >: req r τ 9 >= >; 2 ϕ 6 4 act α β ϕ[α] ε (off, ) α ε ε (on, ) α ε Fig. 14. Semantics Exampe An exampe We show in Fig. 14 a short exampe iustrating our service semantics, in the case of statefu oca histories (ILFω). The network is composed of three services: an initiator (abeed 0 ) and two other services ( 1 and 2 ). The initiator performs two requests using the same contract τ; in this exampe we simpy assume that both services 1 and 2 are compatibe with τ. The service 1, when invoked, runs some activity act and then may perform either the event α or the event β. Instead, 2 may perform α, ony. Both services run their code under a oca poicy ϕ, stating that the event α can be performed at most once, in the whoe ife of each service. In the initia state, a the histories are empty (ε), the initiator has not yet computed a pan (0), and the execution monitor is not active (off ).

27 27 We now comment on the transitions. For brevity, in Fig. 14 we sometimes compacted more steps in a singe one, as we sha point out shorty. First, rue PLNIN is used to form a pan, resoving both requests r and r. There are four possibe pans, since each of the requests can be resoved with either 1 or 2. Invoking 2 twice wi surey vioate the poicy ϕ. Service 1 coud aso invaidate the poicy ϕ if the α branch is taken in both invocations: our static machinery, to err on the safe side, assumes this worst-case situation and consider invoking 1 twice as unsafe. So, the ony viabe pans are r[ 1 ] r [ 2 ] and r[ 2 ] r [ 1 ]. In the figure we choose the first pan. In the second transition we simpy use rue REQ and invoke 1. Then many transition rues are appied: we enter the security bock with rue SECIN; we run act with rue SKIP; we choose the α branch with rue SEQ; we run α with rue EV; we finay exit the security bock with rue SECOUT. The event α is therefore recorded in the history of 1. Finay, we can return to 0 using rue RET. Here, we show what happens if service 2 becomes unavaiabe through rue DOWN. To run request r we can not use rue REQ, but instead we can appy rue N/A and try to recovery from the faiure of 2. We then appy the Sandbox strategy. We turn on the execution monitor, and fix the pan so that r resoves to some avaiabe service compatibe with τ: in the exampe, 1. Doing this, we sha run again service 1. If the service wi attempt to perform another α, this wi be prevented by the execution monitor. If instead 1 wi choose the β branch, it wi compete successfuy. VI. SCENARIOS FOR SECURE SERVICE COMPOSITIONS To iustrate some of the features and design faciities made avaiabe by our framework, we consider two sma case studies. First, we consider a car repair scenario, where a car may break and then request assistance from a tow-truck and a garage. The second scenario is about an embedded computationa device that wants to deegate execution of mobie code. A. Car repair In this scenario, we assume a car equipped with a diagnostic system that continuousy reports on the status of the vehice. When the car experiences some major faiure (e.g. engine overheating, exhausted battery, fat tyres) the in-car emergency service is invoked to seect the appropriate tow-truck and garage services. The seection may take into account some driver custom poicies,

28 28 and other constraints, e.g. the tow-truck shoud be cose enough to reach both the ocation where the car is stuck and the chosen garage. The main focus here is not on the structure of the overa system architecture, rather on how to design the workfow of the service orchestration, taking into account the specific driver poicies and the service contracts on demand. The system is composed of three kinds of services: the CAR-EMERGENCY service, that tries to arrange for a car tow-trucking and repair, the TOW-TRUCK service, that picks the damaged car to a garage, and the GARAGE service, that repairs the car. We assume that a the invoved services trust each other s history, and so we assume a shared goba history, with independent threads. We aso design a the services to be statefu, so that, e.g. the driver can customize the choice of garages, according to past experiences. We start by modeing the CAR-EMERGENCY, i.e. the in-vehice service that handes the car faut. This service is invoked by the embedded diagnosis system, each time a faut is reported. The actua kind of faut, and the geographic ocation where the car is stuck, are passed as parameters named ft and oc. The diagram of the CAR-EMERGENCY service is dispayed on the eft-hand side of Fig. 15. Faut Location Boo ϕ BL 8> < >: req rt void ϕ L(oc) void req rg void ϕ F (ft) void 9 >= >; sgn( x) q 0 sgn(x) q 1 A ϕbl (x) repair ok? α BL [yes] [no] α BL q 3 sgn(x) q 2 Fig. 15. The CAR-EMERGENCY service and the back-isting poicy ϕ BL. The outer poicy ϕ BL (back-ist) has the roe of enforcing a sort of quaity of service constraint. The CAR-EMERGENCY service records in its history the ist of a the garages used

29 29 in past repair requests. When the seected garage G competes repairing a car, it appends to the history its own signature sgn( G ). When the user is not satisfied with the quaity (or the bi!) of the garage, the garage is back-isted (event α BL ). The poicy ϕ BL ensures that a backisted garage (marked by a signature sgn( G ) foowed by a back-isting tag α BL ) cannot be seected for future emergencies. The back-isting poicy ϕ BL is formay defined by the tempate security automaton in Fig. 15, right-hand side. Note that some abes in ϕ BL are parametric: sgn(x) and sgn( x) stands respectivey for the signature of garage x and a signature of any garage different from x, where x can be repaced by an arbitrary garage identifier. If, starting from the state q 0, a garage signature sgn(x) is immediatey foowed by a back-isting tag α BL, then you reach the state q 2. From q 2, an attempt to generate again sgn(x) wi resut in a transition to the offending sink state q 3. For instance, the history sgn( 1 )sgn( 2 )α BL sgn( 2 ) drives the automaton A ϕbl ( 1 ) to the state q 3, thus vioating the poicy ϕ BL. The crucia part of the design is the panning bock. It contains two requests: r T for the towtruck, and r G for the garage. The contract ϕ L (oc) requires that the tow-truck is abe to serve the ocation oc where the car is broken down. The contract ϕ F (ft) seects the garages that can repair the kind of fauts ft. The panning bock has the roe of determining the orchestration pan for both the requests. In this case, it makes itte sense to continue executing with an incompete pan or with sandboxing: you shoud perhaps ook for a car renta service, if either the tow-truck or the garage are unavaiabe. Therefore, a meaningfu panning strategy is trying to find a coupe of services matching both r T and r G, and wait unti both the services are avaiabe. The diagram of the TOW-TRUCK service is dispayed in Fig. 16, on the eft. The service wi first fire the event init T, to signa starting of execution, and then it wi expose the ist of geographic ocations ZIP 1,...,ZIP k it can reach. Each zip code ZIP i is modeed as an event. The computation then branches, according to whether there are any avaiabe trucks. This is rendered as a basic activity with two outgoing edges. The contract ϕ L (oc) imposed by the CAR-EMERGENCY service ensures that the ocation oc is covered by the truck service. Formay, ϕ L (oc) checks if the zip code oc is contained in the interface of the tow-truck service (we omit the automaton for ϕ L (oc) here). Then, the TOW-TRUCK may perform some interna activities (irreevant in our mode), possiby invoking other interna services. The exposed interface is of the form void init T ZIP 1 ZIP k void. The GARAGE service (Fig. 16, center) exposes the kinds of fauts REP 1,...,REP n the garage

30 30 T : void init T ZIP 1 ZIP k void G : void REP 1 REP n sgn( G ) void init T ϕ GZ REP 1 A ϕgz ZIP 1 q 0 ZIP k init T ZIP G avaiabe trucks? REP n [yes] [no] sgn( G) q 1 Fig. 16. The TOW-TRUCK (eft) and GARAGE (right) services, and the Garage-Zip poicy ϕ GZ can repair, e.g. tyres, engine, etc. The request contract ϕ F (ft) ensures that the garage can repair the kind of faut ft experienced by the car. The GARAGE service may perform some interna bookkeeping activities to hande the request (not shown in the figure), possiby using interna services from its oca repository. After the car repair has been competed, the garage G signs a receipt, through the event sgn( G ). This signature can be used by the CAR-EMERGENCY service to impement its back-isting poicy. The GARAGE service expoits the poicy ϕ GZ (for Garage-Zip, see Fig. 16, right) to ensure that the tow-truck can reach the garage address. Assume the garage is ocated in the area identified by ZIP G. Then, the poicy ϕ GZ checks that the tow-truck has exposed the event ZIP G among the ocations it can reach. The event init T ensures that ony the ast invocation of the TOW- TRUCK service is considered. For instance, the history init T ZIP G1 init T ZIP G1 ZIP G ZIP G2 obeys ϕ GZ (reca that the instantiation of tempate security automata adds the sef-oops for ZIP G1 and ZIP G2, and that the fina states are actuay the offending ones). When both the contract ϕ L (oc) and the poicy ϕ GZ are satisfied, we have the guarantee that the tow-truck can pick the car and deposit it at the garage. In Fig. 17, we show a system composed by one car CAR, two TOW-TRUCK services T1

31 31 T1 T2 init T init T ZIP P I ZIP F L ZIP SI ZIP P I ZIP LU CAR (Pisa,Tyres) ϕ BL 8 >< req rt void ϕ L(ZIP P I ) void 9 >= avaiabe trucks? [yes] [no] avaiabe trucks? [yes] [no] >: req rg void ϕ F (REP tyres ) void >; repair ok? F L LU [no] ϕ GZ(FL) ϕ GZ(LU) [yes] α BL REP tyres REP engine REP battery REP tyres sgn(lu)α BL (on, ϕ BL) sgn( F L) sgn( LU) Fig. 17. The CAR-EMERGENCY cient ( CAR), two tow-truck services ( T1, T2), and two garages ( FL, LU ). and T2, and two GARAGE services FL and LU. The car has experienced a fat tyres accident in Pisa (ZIP PI ), and it has back-isted the garage in Lucca, as recorded in the history sgn(lu)α BL. The tow-truck service T1 can reach Forence and Pisa, whie T2 covers three zones: Pisa, Siena and Lucca. The garage FL is ocated in Forence, and it can repair tyres and batteries; the garage LU is in Lucca, and it repairs engines and tyres. We now discuss a the possibe orchestrations: the pan r T [ T1 ] r G [ LU ] is not viabe, because it vioates the poicy ϕ GZ (LU). Indeed, the tow-truck can serve Forence and Pisa, but the garage is ocated in Lucca. simiary, the pan r T [ T2 ] r G [ FL ] vioates ϕ GZ (FL). the pan r T [ T2 ] r G [ LU ] is not viabe, because it vioates the back-isting poicy ϕ BL. Indeed, it woud give rise to a history sgn(lu)α BL sgn(lu), not accepted by the

32 32 automaton in Fig. 15. finay, the pan r T [ T1 ] r G [ FL ] is viabe. The tow-truck can reach both the car, ocated in Pisa, and the garage in Forence, which is not back-isted. B. Remote code execution Consider the scenario depicted in Fig. 18. Assume that the cient at site 0 is a device with imited computationa capabiities, wanting to execute some code downoaded from the network. To do that, the cient issues two (higher order) requests in sequence, the first one to obtain a piece of mobie code (e.g. an appet), and the second one to dispatch its execution to another service. The sites 1 and 2 are the avaiabe code providers, whie 3 and 4 are the code executers. Modeing this scenario requires enriching our graphica notation with some extra features, e.g. parameter passing and higher-order services. In Fig. 18 we sha briefy introduce the needed notation. A more forma treatment can be obtained by using the cacuus λ req [12]. 1 0 (fun x)sgn( 1 ) ϕ OS [ read] f = (req r1 Int (Int Int))() 2 (fun x)sgn( 2 ) read write (req r2 (Int Int) Boo)(f) 3 4 sgn( 3 ) α ω ϕ CW[f()] sgn( 4 ) α 1 f() Fig. 18. One cient ( 0), two code providers ( 1, 2), and two code executors ( 3, 4). To dea with higher order, we introduce some extra notation. Passing a parameter f to a service invoked through a request r is denoted (f). A service returning a function that takes as input a parameter x and then evauates the bock B is denoted (fun x) B. The request abeed r 1 asks for some code, and it can be served by two code providers at 1 and 2, both stateess and with oca histories. The request type Int (Int Int) means that, upon receiving a vaue of type Int, the invoked service repies with a function from Int to Int, with no security constraints.

33 33 The service at 1 returns a one-shot function that can be used ony once. Within the function body, the ony security-reevant operations are writing the service signature (sgn( 1 )) and reading (read) on the fie system where the deivered code is run. The poicy ϕ OS ensures that the code is one-shot. To do that, ϕ OS permits using the function in statefu sites ony, and then prevents the event sgn( 1 ) from being executed twice (see the tempate security automaton A ϕos (x) in Fig. 19, right). We assume that a service decares that it supports statefu execution by emitting the event α ω, whie the event α 1 is for stateess services. The code provided by 2 first reads (read) some oca data, and eventuay writes them back (write) to 2. Since 0 is assumed to have a imited computationa power, the code f obtained by the request r 1 is passed as a parameter to the service invoked by the request r 2. This request can be served by either 3 or 4, both with oca histories. The service at 3 is statefu (α ω ), and it runs the provided code f under a Chinese Wa security poicy ϕ CW, requiring that no data can be written after reading them (see A ϕcw in Fig. 19, eft). The service at 4 is stateess (α 1 ), and it simpy runs the code f, with no security constraints. A ϕcw A ϕos(x) read q 0 q 1 q sgn(x) 0 q 1 α ω write sgn( 1) sgn( 1) q 2 sgn( q 1) 3 q 2 Fig. 19. The Chinese Wa poicy ϕ CW (eft) and the one-shot poicy ϕ OS (x) (right). The types inferred for the services are shown in Fig. 20. For instance, the type of 3 is a poymorphic function that, when appied to a function with a atent effect h (where h is an effect variabe, to be bound to a history expression), wi produce a vaue of type Boo, and a history in the semantics of sgn( 3 ) α ω ϕ CW [h]. The abstract behaviour of the whoe network of services is therefore rendered by the foowing

34 34 1 : Int (Int sgn(1) ϕ OS[read] Int) 0 f = (req r1 Int (Int Int))() (fun x)sgn( 1 ) ϕ OS [ read] 2 : Int (Int sgn(2) read write Int) (fun x)sgn( 2 ) read write (req r2 (Int Int) Boo)(f) 3 : (Int h Int) sgn(3) αω ϕ CW[h] Boo sgn( 3 ) α ω ϕ CW [f()] 4 : (Int h Int) sgn(4) α1 h Boo sgn( 4 ) α 1 f() Fig. 20. One cient, four services, and their certified pubished interfaces. history expression H: {r 2 [ 3 ] 3 : sgn( 3 ) α ω ϕ CW [{r 1 [ 1 ] sgn( 1 ) ϕ OS [read],r 1 [ 2 ] read write}] r 2 [ 4 ] 4 : sgn( 4 ) α 1 {r 1 [ 1 ] sgn( 1 ) ϕ OS [read],r 1 [ 2 ] read write}} The intuitive meaning of H is that, under the pan r 2 [ 3 ], i.e. if r 2 is served by 3, the events sgn( 3 ) and α ω are generated at site 3, foowed by a security bock ϕ CW. This bock wraps sgn( 1 ) ϕ OS [read] if 1 is chosen for r 1, or read write if 2 is chosen instead. Otherwise, if r 2 is served by 4, then the behaviour (on site 4 ) depends on the former choice for r 1. If 1 was seected, then sgn( 1 ) ϕ OS [read], otherwise read write. Note aso that no event is generated by the cient at site 0. The presence of higher order requests makes non-trivia anaysing H to find if there is any viabe pan. The probem is that the effect of seecting a given service for a request is not confined to the execution of that service. The history generated whie running a service may ater on vioate a poicy that wi become active after the service has returned. Since each service seection affects the whoe execution of a program, we cannot simpy devise a viabe pan by ooking at oca requests constraints, ony.

35 35 In our exampe, we find that H is equivaent to the foowing H : H = {r 1 [ 1 ] r 2 [ 3 ] 3 : sgn( 3 ) α ω ϕ CW [sgn( 1 ) ϕ OS [read]], r 1 [ 2 ] r 2 [ 4 ] 4 : sgn( 4 ) α 1 sgn( 2 ) read write, r 1 [ 1 ] r 2 [ 4 ] 4 : sgn( 4 ) α 1 sgn( 1 ) ϕ OS [read], r 1 [ 2 ] r 2 [ 3 ] 3 : sgn( 3 ) α ω ϕ CW [sgn( 2 ) read write]} Every eement of H ceary separates the pan from the associated abstract behaviour. This piece of behaviour has no further pans within, and so it has a the information needed to mode-check its vaidity. E.g., under the pan r 1 [ 1 ] r 2 [ 3 ], the abstract behaviour at site 3 is: sgn( 3 ) α ω ϕ CW [sgn( 1 ) ϕ OS [read]] There are then four possibe pans for the execution: r 1 [ 1 ] r 2 [ 3 ], r 1 [ 1 ] r 2 [ 4 ], r 1 [ 2 ] r 2 [ 3 ], and r 1 [ 2 ] r 2 [ 4 ]. The pan r 1 [ 2 ] r 2 [ 3 ] is not viabe, because it woud drive a computation aborted by the execution monitor at site 3. The monitor aborts the execution just before generating the event write, because the history sgn( 3 )α ω sgn( 2 )read write (oca at 3 ) woud vioate the Chinese-Wa poicy ϕ CW. The pan r 1 [ 1 ] r 2 [ 4 ] is not viabe, too. Indeed, the history sgn( 4 )α 1 sgn( 1 ) at 4 vioates the poicy ϕ OS(4 ) (reca that ϕ OS prevents the code provided by 1 from being executed by stateess services). There are two further pans to consider, i.e. r 1 [ 1 ] r 2 [ 3 ] and r 1 [ 2 ] r 2 [ 4 ]. These pans are judged viabe by our static anaysis, and indeed they drive executions that never fai. Summing up, we have inferred the overa effect H, we have transformed it into a simpe panned seection {π 1 H 1 π k H k }, and we have mode-checked the vaidity of the H i. The pans π i associated with the vaid H i safey drive the execution, without resorting to any run-time monitor. VII. CONCLUSIONS AND RELATED WORK We have introduced a UML-ike graphica anguage for designing and verifying security poicies of service-oriented appications. The distinguished feature of our modeing framework is that it provides high-eve constructs (e.g. ca-by-contract) abstracting from the underying middeware for service programming and depoying. We tacked the probem of modeing and verifying properties of service orchestration in the presence of security constraints. Our main

36 36 resut is a semantic-based methodoogy for synthesizing the skeeton structure of the orchestration engine. The orchestration pan detais which services the orchestrator engine has to choose in order to compete the origina task, whie obeying the security poicies on demand. Here, we deat with security poicies, but our methodoogy can be appied to hande a variety of non-functiona safety constraints. We envisage the impact of our approach on the service protoco stack as foows. First, our proposa requires extending services description anguages: besides the standard WSDL attributes, service description incudes information about service behaviour. Moreover, the ca-by-contract invocation mechanism adds a further panning ayer to the standard service protoco stack. This ayer provides the orchestrator with the pans guaranteeing that the reevant services aways respect the required properties. The trustfuness of the panning ayer and of the orchestrator foows from our forma approach, in particuar from the soundness of the type and effect system, and the correctness of panning and of verification [8]. Another feature offered by our framework is that of mapping high-eve service descriptions into more concrete λ req programs. This can be done with the hep of simpe mode transformation toos. Such mode-driven transformation woud require very itte user intervention. Typicay, the user just needs to (i) make the argument passing and return vaues expicit, e.g. decorating the diagram with variabes, and (ii) annotate conditiona branches with the proper guards. Transforming the diagram into a λ req program can instead be performed in a competey automated way, e.g. by impementing diagram oops through recursive functions, avaiabe in λ req. This mode transformation woud aow one to reuse a the λ req toos, incuding its static machinery, and therefore to rapidy buid a working prototype of a service-based appication. As usua, a prototype can hep in the design phase, because one can perform tests on the system, e.g. by providing as input seected data, one can observe whether the outputs are indeed the intended ones. In λ req, this standard testing practice can be more effective by expoiting the ca-by-contract mechanism. For instance, one can perform a request with a given poicy ϕ and observe the resuting pans. This makes the system consider a the services that satisfy ϕ, and the observed effect is simiar to running a cass of tests. To make a concrete exampe, a designer of an onine bookshop can specify a poicy such as order a book without paying and then inspect the generated pans: the presence of viabe pans coud point out an unwanted behaviour, e.g. due to an unpredicted interaction between different specia offers. Standard testing

37 37 techniques are not sophisticated enough to spot such kind of bugs. Thus, a designer may find the λ req prototype usefu to check the system correctness, since unintended pans provide him with a cear description of the unwanted interactions between services. Reated work Severa approaches have been deveoped to support verification of service-oriented systems. For exampe, dynamic bisimuation-based techniques have been adopted to anayse the consistency between orchestration and choreography of services [21], [22], whie state-space anaysis has been expoited to check correctness of service orchestration [31]. Our approach aows for synthesizing and checking the correctness of the orchestration staticay. Process cacui techniques have been used to formaize Web Services standards (see e.g. [28], [18], [35], [37], [23]). A different approach is Cook and Misra s Orc [38], an abstract programming mode for structured orchestration of services. Web service authentication has been recenty modeed and anaysed in [14], [15] through a process cacuus enriched with cryptographic primitives. The main difference of these approaches with ours stands on the eve of abstraction. Technicay, the work of Skaka and Smith [44] is the cosest to our framework. We share with them the use of a type and effect system and that of mode checking vaidity of effects (they hande history-based access contro). A reated ine of research addresses the issue of modeing and anaysing resource usage. Igarashi and Kobayashi [36] introduce a type systems to check whether a program accesses resources according to a user-defined usage poicy. Our mode is ess genera than the framework of [36], but we provide a static verification technique [9], whie [36] does not. From a software engineering perspective, the advent of service-oriented appications has ed to the deveopment of higher eve modeing anguages which ony focus on the service interfaces and orchestration (business) ogic and abstract from the underying programming middeware. A we known exampe is provided by the Service Component Architecture (SCA) [24]. This framework aims at simpifying impementations, by aowing designers to focus on the business ogic ony whie compying with existing standards. Our approach compements the SCA view providing a fu-fedged mathematica framework for designing and verifying properties of service assembies. It woud be interesting deveop a (mode-transformation) mapping from our forma framework to SCA.

38 38 Aso reated to our approach is the work on SRML [29], a high-eve core anguage, independent from the underying programming middeware. SRML has a mathematica semantics providing a basis for verification and offers both syntactic and behavioura service interfaces. The ogic for the specification of behavioura properties of services is sti under deveopment. The interconnections between services are specified in a decarative stye, but they are not driven by the properties of a contract as it is our proposa. Finay, there are severa UML extensions, caed UML profies, deaing with services. Here, we mention the UML profie for BPEL [33], the UML profie for ong-running transactions [50], and the UML profie for λ req [39]. Our graphica design notation basicay provides the notion of activity diagram for this UML profie. Acknowedgments We thank the anonymous referees for their insightfu comments. This research has been partiay supported by EU-FETPI Goba Computing Project IST SENSORIA (Software Engineering for Service-Oriented Overay Computers). REFERENCES [1] M. Abadi and C. Fournet. Access contro based on execution history. In Proc. 10th Annua Network and Distributed System Security Symposium, [2] G. Aonso, F. Casati, H. Kuno, and V. Machiraju. Web Services: Concepts, Architectures and Appications. Springer, [3] S. Anderson et a. Web Services Trust Language (WS-Trust), [4] B. Atkinson et a. Web Services Security (WS-Security), [5] A. Banerjee and D.A. Naumann. History-based access contro and secure information fow. In Workshop on Construction and Anaysis of Safe, Secure and Interoperabe Smart Cards (CASSIS), [6] H. P. Barendregt et a. Term graph rewriting. In Parae Languages on PARLE: Parae Architectures and Languages Europe, [7] M. Bartoetti, P. Degano, and G.L. Ferrari. History based access contro with oca poicies. In Proc. Foundations of Software Science and Computation Structures (Fossacs), voume 3441 of Springer LNCS, [8] M. Bartoetti, P. Degano, and G.L. Ferrari. Panning and verifying service composition. Technica Report TR-07-02, Dip. Informatica, Univ. of Pisa, to appear in Journa of Computer Security. [9] M. Bartoetti, P. Degano, G.L. Ferrari, and R. Zunino. Types and effects for resource usage anaysis. In In Proc. Foundations of Software Science and Computation Structures (Fossacs), [10] Massimo Bartoetti, Pierpaoo Degano, and Gian Luigi Ferrari. Enforcing secure service composition. In Proc. 18th Computer Security Foundations Workshop (CSFW), 2005.

39 39 [11] Massimo Bartoetti, Pierpaoo Degano, and Gian Luigi Ferrari. Pans for service composition. In Workshop on Issues in the Theory of Security (WITS), [12] Massimo Bartoetti, Pierpaoo Degano, and Gian Luigi Ferrari. Security issues in service composition. In Invited tak at (FMOODS), voume 4037 of Lecture Notes in Computer Science. Springer, [13] Massimo Bartoetti, Pierpaoo Degano, and Gian Luigi Ferrari. Types and effects for secure service orchestration. In Proc. 19th Computer Security Foundations Workshop (CSFW), [14] K. Bhargavan, R. Corin, C. Fournet, and A.D. Gordon. Secure sessions for web services. In Proc. ACM Workshop on Secure Web Services, [15] K. Bhargavan, C. Fournet, and A.D. Gordon. A semantics for web services authentication. In Proc. ACM SIGPLAN-SIGACT Symposium on Principes of Programming Languages (POPL), [16] B. Boch et a. Web services business process execution anguage, version 2.0. Technica report, TC OASIS, [17] D. Booth et a. Web Service Description Language (WSDL), Version 2.0, [18] M. Boreae et a. SCC: a service centered cacuus. In WS-FM, voume 4184 of Springer LNCS, [19] D. Box et a. Simpe Object Access Protoco (SOAP) 1.1. W3C Note, [20] Roberto Bruni, Hernán Megratti, and Ugo Montanari. Theoretica foundations for compensations in fow composition anguages. In Proc. 32nd ACM SIGPLAN-SIGACT Symposium on Principes of programming anguages (POPL), [21] Nadia Busi, Roberto Gorrieri, Caudio Guidi, Roberto Lucchi, and Gianuigi Zavattaro. Choreography and orchestration: A synergic approach for system design. In Internationa Conference on Service Oriented Computing (ICSOC), voume 3826 of LNCS. Springer, [22] Nadia Busi, Roberto Gorrieri, Caudio Guidi, Roberto Lucchi, and Gianuigi Zavattaro. Choreography and orchestration conformace for system design. In COORDINATION, voume 4038, [23] M. Carbone, K. Honda, and N. Yoshida. Structured goba programming for communicating behaviour. In European Symposium in Programming Languages (ESOP), voume to appear, [24] SCA Consortium. Buiding systems using a service oriented architecture. In White Paper. Avaiabe from www- 128.ibm.com/deveoperworks/ibrary/specification/ws-sca/, [25] F. Curbera, R. Khaaf, N. Mukhi, S. Tai, and S. Weerawarane. The next step in web services. Communications of the ACM, 46(10), [26] W. Van der Aast, A. ter Hofstede, B. Kiepuszewski, and A. Barros. Workfow patterns. Distributed and Parae Databases, 14(1), [27] G. Edjai, A. Acharya, and V. Chaudhary. History-based access contro for mobie code. In Secure Internet Programming, voume 1603 of Springer LNCS, [28] G.L. Ferrari, R. Guanciae, and D. Stroo. JSCL: A middeware for service coordination. In Proc. FORTE, voume 4229 of Springer LNCS, [29] Jose Louis Fiadeiro, Antonia Lopez, and Laura Bocchi. A forma approach to service component architecture. In WS-FM 2006, voume 4184 of LNCS. Springer, [30] P. W. Fong. Access contro by tracking shaow execution history. In IEEE Symposium on Security and Privacy, [31] Howard Foster, Sebastian Uchite, Jeff Magee, and Jeff Kramer. Mode-based verification of web services. In ASE. IEEE Computer Society, 2003.

40 40 [32] Hector Garcia-Moina and Kenneth Saem. Sagas. In Proc. ACM SIGMOD. ACM Press, [33] T. Gardner and a. Um 1.4 profie for automated business process with a mapping to the BPEL 1.0. In White Paper. IBM Apha Works, [34] Li Gong. Inside Java 2 patform security: architecture, API design, and impementation. Addison-Wesey, [35] C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. SOCK: A cacuus for service oriented computing. In Proc. Service-Oriented Computing (ICSOC), voume 4294 of Springer LNCS, [36] A. Igarashi and N. Kobayashi. Resource usage anaysis. In Proc. 29th ACM SIGPLAN-SIGACT Symposium on Principes of Programming Languages (POPL), [37] A. Lapadua, R. Pugiese, and F. Tiezzi. A cacuus for orchestration of web services. In European Symposium in Programming Languages (ESOP), voume to appear, [38] J. Misra. A programming mode for the orchestration of web services. In 2nd Internationa Conference on Software Engineering and Forma Methods (SEFM 2004), [39] C. Montangero and L. Semini. Barbed mode driven software deveopment: A case study. Technica report, SENSORIA, IST , monta/pcu/ttss07rep.pdf. [40] Femming Nieson, Hanne Riis Nieson, and Chris Hankin. Principes of Program Anaysis. Springer-Verag, [41] M. Papazogou. Service-oriented computing: Concepts, characteristics and directions. In Proc. Web Information Systems Engineering (WISE), [42] M. Papazogou and D. Georgakopouos. Specia issue on service oriented computing. Communications of the ACM, 46(10), [43] F.B. Schneider. Enforceabe security poicies. ACM Transactions on Information and System Security (TISSEC), 3(1), [44] C. Skaka and S. Smith. History effects and verification. In Proc. Asian Programming Languages Symposium (APLAS), voume 3302 of Springer LNCS, [45] M. Sta. Web services: Beyond component-based computing. Communications of the ACM, 55(10), [46] Ioan Toma and Dougas Foxvog. Non-functiona properties in Web Services. WSMO Deiverabe, [47] Vedamuthu et a. Web Services Poicy Framework (WS-Poicy), [48] W. Voges. Web services are not distributed objects. IEEE Internet Computing, 7(6), [49] W3C. UDDI Technica White Paper, [50] Martin Wirsing et a. Semantic-based deveopment of service-oriented systems. In Forma Techniques for Networked and Distributed Systems - FORTE 2006, voume 4229 of Lecture Notes in Computer Science. Springer, [51] R. Yahaom, B. Kein, and Th. Beth. Trust reationships in secure systems A distributed authentication perspective. In Proc. IEEE Symposium on Security and Privacy, 1993.

41 41 Massimo Bartoetti received the PhD degree in Computer Science from the University of Pisa in His research activity mainy spans over anguage-based security and static anaysis for functiona and object-oriented anguages. His current research interests incude type and effect systems and anaysis and design of core cacui for service-oriented computing. Pierpaoo Degano has been fu professor of Computer Science since 1990, and he has been at the Department of Computer Science, University of Pisa since He served as guest editor of Theoretica Computer Science, the ACM Computing Surveys, and Science of Computer Programming. He cofounded the IFIP TC1 WG 1.7 on Theoretica Foundations of Security Anaysis and Design; he is member of the Board of Directors of the Microsoft Research - University of Trento Center for Computationa and Systems Bioogy. His main areas of interest are security of concurrent and mobie systems, systems bioogy, semantics and concurrency, methods and toos for program verification and evauation, and programming toos. Gian Luigi Ferrari received the PhD degree in computer science in 1989 from the University of Pisa, where he is an Associate Professor at the Department of Computer Science. His research interests incude forma specification and verification of concurrent and mobie systems, programming anguages for goba computing, too support for mobie systems and theoretica aspects of distributed computing. Roberto Zunino received the PhD degree in computer science from the University of Pisa in His main research topics incude computer security, cryptographic protocos, systems verification and static anaysis. He has worked on automatic verification techniques and on the agebraic properties of cryptographic primitives. Other research interests are anguage-based security and type systems.