Secure Service Orchestration

Transcript

1 Secure Service Orchestration Massimo Bartoletti Pierpaolo Degano Gian-Luigi Ferrari Roberto Zunino Dipartimento di Informatica Università di Pisa

2 Summary Overview issues in secure service composition security model: safety framings and policies call-by-contract for service request plans for secure orchestration A calculus for service composition syntax and operational semantics type & effect system Plans & Orchestration constructions of plans and linearization model-checking viable plans

3 Programming in a world of services l 1 τ 1 l 3 τ 3 S1 S3 l 2 τ 2 client l 4 τ 4 S2 S4

4 Programming in a world of services service location l 1 τ 1 service code l 3 τ 3 S1 S3 l 2 τ 2 client l 4 τ 4 S2 service interface S4 service orchestration

5 Traditional protection: firewalls l 1 browser mail server l 3 hacker l 2 file server l 4 web server

6 Traditional protection: firewalls l 1 firewall l 3 browser mail server hacker l 2 file server access denied l 4 web server

7 Trojan horses l 1 firewall l 3 browser applet l 2 file server read/write mail server download applet l 4 hacker upload applet web server

8 Trojan horses l 1 firewall l 3 browser applet mail server hacker l 2 file server Given a choice between dancing pigs and security, users will pick dancing pigs everytime [Edward Felten] l 4 web server

9 Trojan horses l 1 firewall l 3 browser applet mail server hacker l 2 file server sandbox Given a choice between dancing pigs and security, users will pick dancing pigs everytime [Edward Felten] l 4 web server

10 Security and service composition two kinds of security concerns: secrecy of transmitted data, authentication, etc (protocol analysis techniques first part of course) control on computational resources (access control, resource usage analysis, information flow control, etc) need for linguistic mechanisms that: work in a distributed setting assume no (or weak) trust relations among services can also cope with mobile code

11 Checklist for secure service composition We want to devise a framework that: is expressive enough to model with real-world (although simplified) scenarios allows for a formal characterization of what security property is actually obtained, under a reasonable trusted computing base is simple enough to allow for a clean formal treatment, and for mechanical analysis tools deal with security from system design to implementation abstracts from technological biz (no WS-* buzzwords)

12 Security and service composition: safety framings Client wants to protect from untrusted results client applet service Linguistic mechanism: safety framing ϕ[applet] applet service The policy ϕ is enforced stepwise within its scope

13 Security and service composition: safety framings Similarly, services want to protect from clients client remote exec result service (now the safety framing belongs to the service) client remote exec result ϕ [exec] Scoped policies check the local execution histories

14 Security and service composition: service selection Call-by-name: request a given service among many S1 req S2 S2 S3 Why S2 and not S1 or S3, if all functionally equivalent?

15 Security and service composition: service selection Problems with call by name : what if named service S2 becomes unavailable? and if S2 is outperformed by S1 or S3? hard reasoning about non-functional properties of services (e.g. security) security level independent of the execution context (unless hard-wired in the service code) From syntax-based to semantics-based invocation Service names l,l,.. tell me nothing about the behaviour!

16 Security and service composition: service selection Call-by-contract: request a service respecting the desired behaviour req τ S1 only S1 is guaranteed to match the behaviour τ τ1 τ2 τ3 S1 S2 S3 τ imposes both functional and non-functional constraints

17 Use cases for call-by-contract Example: download an applet that obeys the policy ϕ req τ 0 ( τ 1 ϕ[ ] τ 2 ) Example: a remote executer that obeys the policy ϕ req ( τ 0 τ 1 ) ϕ ϕ [ ] τ 2

18 Observable behaviour access events are the actions relevant for security (e.g. read/write local files, invoke/be invoked by a given service, etc) mechanically inferred, or inserted by programmer. their meaning is fixed globally. access events cannot be hidden. the (abstract) behaviour observable by the orchestrator over-approximates the histories, i.e. sequences of access events, obtainable at run-time (type & effect system).

19 What kind of policies? History-based security Policies ϕ are regular properties event histories (i.e. the language accepted by ϕ is recognizeable by finite state automata) Policies ϕ,ϕ ϕ have a local scope, possibily nested ϕ[ ϕ ϕ [ ] When the scope of ϕ is left, the history needs not to obey ϕ any longer. Parametric policies ϕ(x) can be defined through template usage automata.

20 Example: the Chinese Wall policy ϕ Chinese Wall: cannot write (α w ) after read (α r ) A ϕ α r α w q0 q1 q2 q2 offending state α w α r * α w α r α w ϕ

21 Other expressible policies Anti-phishing: known phishers sites are blacklisted (sensitive accesses are denied after you have visited a phisher site) Chinese-Wall (tolerant version): you cannot connect to the network after you have read a file you have not created Java sandbox: an applet can only connect to the site it was downloaded from Denial-of-service: an applet cannot create more than k files.

22 A taxonomy of security aspects stateless / stateful services. In the stateless case, each service invocation starts with an empty history, while stateful keeps histories through invocations. local / global histories. In the local case, a policy can only inspect histories of a single site. This requires no trust among services. first order / higher order requests. With higher-order requests, we can model mobile code. dependent / independent threads. In the dependent case, threads share execution histories. Instead, independent threads keep histories separated.

23 Principle of Least Privilege Programs should be granted the minimum set of rights needed to accomplish their task A service must always obey all the active policies (no policy override) Policies can always inspect the whole past history (no event can be discarded) Privileged calls implemented by policies that explicitly discard the past

24 Roadmap to call-by-contract We have defined: the form of requests: req τ the observable behaviour: event histories the security policies ϕ, and their enforcement mechanism A ϕ local policies: ϕ[ ] What s next: service publication: l{s}: τ service orchestration: mapping req τ to req l

25 Service publication (1) l 1 τ 1 l 1 {S1}: τ 1 l 2 {S2}: τ 2 1. infer τ 3 from S3 2. mark S3 so to prevent spoofing l 2 l 3 S1 τ 2 S2? S3

26 Service publication (2) l 1 τ 1 l 1 {S1}: τ 1 l 2 {S2}: τ 2 l 3 {S3}: τ 3 l 2 S1 τ 2 S2 Service Repository l 3 τ 3 S3

27 Service orchestration l 0 H l 1 S1 l i {S i }: τ i req r τ π 1. combine τ with the τ i to infer the abstract behaviour H 2. extract from H a viable plan π forl 0 l 2 l 3 S2 S3

28 Service orchestration l 0 H req r τ Plan π = r[l 2 ] l 1 l 2 S1 S2 l 3 S3 Names are only known by the orchestrator!

29 What is a plan? A plan drives the execution of an application, by associating each service request with one (or more) appropriate services With a viable plan: executions never violate policies there are no unresolved requests you can then dispose from any execution monitoring! Many kinds of plans: Simple: one service for each request Multi-choice: more services for each request Dependent: one service, and a continuation plan

30 Who do we trust? The orchestrator, that: certifies the behavioural descriptions of services (types annotated with effects H) composes the descriptions, and ensures that selected services match the requested types extracts the viable plans (through modelchecking) Also, we trust services not to change their code on-the-fly (trusted computer - corporate)

31 Summing up a calculus for secure service composition: distributed services safety framings scoped policies on localized execution histories call-by-contract service invocation static orchestrator: certifies the behavioural interfaces of services provides a client with the viable plans driving secure executions

32 What s next calculus: syntax and operational semantics static semantics: type & effect system types carry annotations H about service behaviour effects H are history expressions, which overapproximate the actual execution histories extracting viable plans: linearization: unscrambling the structure of H model checking: valid plans are viable

33 Services Services e ::= x α if b then e else e λ z x.e e e ϕ[e] req r τ (only in configs) wait l variable access event conditional abstraction application safety framing service request wait reply

34 Networks location service code and published interface N ::= l{e:τ}: η, e N N published service composition running code execution history

35 (Simple) Plans A plan is a function from requests r to services l π ::= 0 r[l] π π empty service choice composition Plans respect the partial knowledge l < l of services about the network (< is a partial ordering)

36 Example: delegating code execution l 1 l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 l 4 α c ;(λx.α r ; ;α w ) req r2 (f) f()

37 Example: delegating code execution l 1 use in certified sites α c only l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c ;(λx.α r ; ;α w ) req r2 (f) do not write α w after a read α r l 4 f()

38 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 l 4 α c ; (λx.α r ; ;α w ) req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

39 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = wait l 2 α c ; ϕ [f()] l 2 ε l 4 α c ; (λx.α r ; ;α w ) req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

40 Executing a network of services l 0 l 1 l 3 λx.ϕ[α r ; ] f = wait l 2 α c ; ϕ [f()] l 2 α c l 4 λx.α r ; ;α w req r2 (f) f() π = r 1 [l 2 ] r 2 [l 3 ]

41 Executing a network of services l 1 l 0 l 3 ε λx.ϕ[α r ; ] f = λx.α r ; ;α w α c ; ϕ [f()] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

42 Executing a network of services l 0 l 1 l 3 α c λx.ϕ[α r ; ] ϕ [αr; ; αw] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

43 Executing a network of services l 0 l 1 l 3 α c α r λx.ϕ[α r ; ] ϕ [αw] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ]

44 Executing a network of services l 1 l 0 l 3 α c α r α w ϕ λx.ϕ[α r ; ] ϕ [αw] l 2 l 4 α c ; (λx.α r ; ;α w ) wait l 3 f() π = r 1 [l 2 ] r 2 [l 3 ] not viable!

45 Semantics of services (1) [App1] η,e 1 η,e 1 η, e 1 e 2 η, e 1 e 2 [App2] η,e 2 η,e 2 η, v e 2 η, v e 2 [AbsApp] η, (λ z x.e) v η, e{v/x, λ z x.e/z} [If] η, if b then e true else e false η, e B (b)

46 Semantics of services (2) [Event] η, α ηα, () [Framing Out] [Framing In] η,e η,e η = ϕ η, ϕ[e] η, ϕ[e ] η = ϕ η, ϕ[v] η, v

47 Semantics of networks (1) [Inject] η, e η, e l: η, e π l: η, e N 1 π N 1 [Par] N 1 N 2 π N 1 N 2

48 Semantics of networks (2) [Request] π = r[l ] π l: η, req r v l {e }: ε, π l: η, wait l l {e }: ε, e v [Reply] l: η, wait l l {e }: η, v π l: η, v l {e }: ε,

49 Other kinds of plans Simple plans π ::= 0 π π r[l] l: req r l : {e} r[l ] l: wait l l : e Multi-choice plans π ::= 0 π π r[l 1 l k ] l: req r l : {e} r[l,l ] l: wait l l : e Dependent plans π ::= 0 π π r[l. π] l: r[l.π] req r l : {e} l: r[l.π] wait l l : π e many others: multi+dependent, regular, dynamic,

50 Static semantics Type & effect system types carry annotations H about service abstract behaviour effects H, namely history expressions, over-approximate the actual execution histories the type & effect inferred for a service depends on its partial knowledge < of the network

51 Types (pretty standard) τ ::= int bool 1 τ τ H

52 Effects (history expressions) H ::= ε h α H H H + H µh.h ϕ[h] l: H {π 1 H 1 π k H k } empty variable access event sequence choice recursion safety framing localization planned selection

53 Semantics of history expressions [[ α ]] π = (?: α) [[ l: H ]] π = [[ H ]] π {l /?} [[{π 1 H 1 π k H k } ]] π = U i=1..k [[ {π i H i } ]] π [[ {π H} ]] π = [[ H ]] π if π π plan π resolves the requests as π 0 π r[l] r[l] π π 0 π 1 π if π 0 π & π 1 π

54 Semantics of history expressions [[ H H ]] π = [[ H ]] π [[ H ]] π [[ H + H ]] π = [[ H ]] π + [[ H ]] π [[ µh.h]] π = U n>0 f n( ) where f(x) = [[ H ]] π { X / h}

55 Example H = {r[l] {r [l 1 ] α 1, r [l 2 ] α 2 }, r[l ] β} π = r[l] r [l 2 ] [[ H ]] π = [[ {r[l] {r [l 1 ] α 1, r [l 2 ] α 2 }} ]] π U [[ {r[l ] β} ]] π = [[ {r [l 1 ] α 1, r [l 2 ] α 2 } ]] π = [[ {r [l 1 ] α 1 } ]] π U [[ {r [l 2 ] α 2 } ]] π = [[ α 2 ]] π = (?: α 2 )

56 Example H = l: {r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 } β π = r[l 1 ] [[ H ]] π = [[{r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 } β ]] π {l/?} = [[{r[l 1 ] l 1 :α 1, r[l 2 ] l 2 :α 2 }]] π (l: β) = [[ l 1 :α 1 ]] π (l: β) = (?: α 1 ) {l 1 /?} (l: β) = (l: β, l 1 : α 1 )

57 Typing rules (1) [T-Ev] Γ, α - l α : 1 [T-Var] Γ, ε - l x : Γ(x) [T-Loc] Γ, H - l e: τ Γ, l: H - e: τ [T-Wk] Γ, H - l e: τ Γ, H+H - l e: τ

58 Typing rules (2) [T-If] [T-Fr] Γ, H - l e: τ Γ, ϕ[h] - l ϕ[e] : τ Γ, H - l e: τ Γ, H - l e : τ Γ, H - l if b then e else e : τ

59 Typing rules (3) [T-Abs] Γ; x:τ;z: τ τ, H - l e : τ [T-App] H Γ, ε - l λ z x.e : H Γ, H - l e: τ τ Γ, H H H τ τ H τ - l e e : τ Γ, H - l e : τ

60 Typing Example (1) α - l α:1 z:1 H? - l (λy.zx)β:1 1,α+? - l if b then α else (λy.zx)β:1

61 Typing Example (2) H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 z:1 H H β - l (λy.zx)β:1 1,α+H β - l if b then α else (λy.zx)β:1

62 Typing Example (3) x:1;z:1 H 1, H - l zx:1 H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 z:1 H H β - l (λy.zx)β:1 1,α+H β - l if b then α else (λy.zx)β:1

63 Typing Example (4) z:1 H H 1, ε - l z:1 1 x:1;z:1 H x:1, ε - l x:1 1, ε ε H - l zx:1 H ε - l (λy.zx):1 1 β - l β:1 α - l α:1 z:1 H β H - l (λy.zx)β:1 1,α+ β H - l if b then α else (λy.zx)β:1

64 Typing Example z:1 H 1,α+ β H - l if b then α else (λy.zx)β:1 ε - l λ z x.if b then α else (λy.zx)β: τ H τ [T-Abs] To use rule the latent and actual effects must be unified, i.e. H = α+ β H A history expression that satisfies the above is: H = µh. α + β h

65 Typing requests (an example) We want to type at l : req r int φ[ ] int α l 1 int int α α l 2 int int α l 3 int bool ε - l req r int { r[l 1 ] l 1 :φ[α], r[l 2 ] l 2 :φ[α α]] } int

66 Typing rules (3) [T-Req] τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

67 Typing rules (3) [T-Req] certified interface τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

68 Typing rules (3) [T-Req] compatible types τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ

69 Typing rules (3) [T-Req] τ = U { ρ + r[l] τ A & B & C } A, ε - l e: τ C l <l {e: τ } Γ, ε - l req r ρ : τ B ρ τ visibility

70 Certified published interfaces l 1 ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f()

71

72 Abstracting client behaviour l 1 ε ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f() { r 1 [l 1 ] l 1 : ε, r 1 [l 2 ] l 2 : α c ] }

73 Abstracting client behaviour l 1 ε ϕ[α r ] 1 (1 1) l 3 h (1 1) α c ϕ [h] 1 λx.ϕ[α r ; ] f = req r1 () α c ; ϕ [f()] l 2 α c α r α w 1 (1 1) l 4 h (1 1) h 1 α c ; λx.α r ; ;α w req r2 (f) f() { r 2 [l 3 ] l 3 : α c ϕ [{ r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }], r 2 [l 4 ] l 4 : { r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }}

74 Summing up Calculus: operational semantics and type & effect system effects are history expressions, and overapproximate the actual execution histories planned selections therein hinder information about which plans to choose for secure compositions

75 What s next: the road to viable plans linearization: extracting plans and their pure effects by unscrambling the structure of history expressions validity: defining when an effect denotes histories that never go wrong model checking: valid plans are viable transform history expression into BPAs transform policies into FSAs orchestrator: uses viable plans to drive safe service composition

76 Which are the viable plans? { r 1 [l 1 ] l 1 : ε, r 1 [l 2 ] l 2 : α c ] } { r 2 [l 3 ] l 3 : α c ϕ [{ r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }], r 2 [l 4 ] l 4 : { r 1 [l 1 ] ϕ[α r ], r 1 [l 2 ] α r α w }} Difficult to tell: the planned selections are nested! { r 1 [l 1 ] r 2 [l 3 ] l 3 : α c ϕ [ϕ[α r ]], { r 1 [l 2 ] r 2 [l 4 ] l 2 : α c, l 4 : α r α w, { r 1 [l 1 ] r 2 [l 4 ] l 4 : ϕ[α r ], { r 1 [l 2 ] r 2 [l 3 ] l 2 : α c, l 3 : α c ϕ [α r α w ]} viable viable not viable not viable

77 Linearization transform H into an equivalent H Hsuch that H is in linear form, i.e.: H = {π 1 H 1 π k H k } and the H i have no planned selections. defined through oriented equations that groups r[l] in topmost position

78 Linearization H {0 H} {π i H i } i {π j H j } {π j i π j H i H j } i,j {π i H i } i + {π j H j } j {π i π j H i + H j } i,j ϕ[ {π i H i } i ] {π i ϕ[h i ] } i µh.{π i H i } i {π i µh. H i } i {π i {π i,j H i,j } j } i {π i π i,j H i,j } i,j

79 Example H ϕ[ λ z x. req r ρ; z x ] l 1 l 2 α β H = ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} h ]

80 Example H = ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} h ] ϕ[ µh. { r[l 1 ] α, r[l 2 ] β} {0 h} ] ϕ[ µh. { r[l 1 ] 0 α h, r[l 2 ] 0 β h} ] = ϕ[ µh. { r[l 1 ] α h, r[l 2 ] β h}] ϕ[ { r[l 1 ] µh. α h, r[l 2 ] µh. β h } ] { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h] }

81 Simple vs multi-choice plans With simple plans: H { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h] } With multi-choice plans: H { r[l 1 ] ϕ[ µh. α h], r[l 2 ] ϕ[ µh. β h], r[l 1,l 2 ] ϕ[ µh. (α+ β) h]} Plan r[l 1,l 2 ] useful when l 1 or l 2 unavailable

82 Example: bottleneck service l 0 H ϕ= never αα nor ββ l 2 ϕ[req r ; req r ] l 1 reqr1 l 3 α β H = ϕ[ { r[l 1 ] { r 1 [l 2 ] α, r 1 [l 3 ] β} } { r [l 1 ] { r 1 [l 2 ] α, r 1 [l 3 ] β}}]

83 Simple vs dependent plans With simple plans: H { r[l 1 ] r 1 [l 2 ] r [l 1 ] ϕ[α α], r[l 1 ] r 1 [l 3 ] r [l 1 ] ϕ[β β] } With dependent plans: H { r[l 1. r 1 [l 2 ]] r [l 1. r 1 [l 2 ]] ϕ[α α], r[l 1. r 1 [l 2 ]] r [l 1. r 1 [l 3 ]] ϕ[α β], r[l 1. r 1 [l 3 ]] r [l 1. r 1 [l 2 ]] ϕ[β α], r[l 1. r 1 [l 3 ]] r [l 1. r 1 [l 3 ]] ϕ[β β] } not viable not viable not viable viable viable not viable

84 Validity histories are enriched with [ ϕ and ] ϕ to point out the scope of policies. a history is valid when all the policies are respected, within their scopes ϕ = you cannot write (α w ) after you have read (α r ) ex: α w α r [ ϕ α w ] ϕ not valid (write after read) ex: α w [ ϕ α r ] ϕ α w valid (write outside scope of ϕ) a history expression H is π-valid when all the histories in [[ H ]] π are valid.

85 Validity, formally Safe sets: S(ε) = 0 S(η α) = S(η) S(η 0 [ ϕ η 1 ] ϕ ) = S(η 0 η 1 ) U ϕ[ flat(η 0 ) flat pref(η 1 ) ] Example: S([ ϕ α [ Ψ β ] Ψ γ ] ) = S(α [ ϕ Ψ β ] Ψ γ ) U ϕ[{ε, α, αβ,αβγ }] = Ψ[{α, αβ}], ϕ[{ε, α, αβ,αβγ }] η is valid if, for each ϕ[{η 1,,η k }] in S(η): η i = ϕ for 1 i k

86 Verifying validity Model checking: valid plans are viable (drive executions that never go wrong) transform linearized history expression into BPAs (Basic Process Algebras) transform policies into scoped policies (in the form of Finite State Automata)

87 Basic Process Algebras BPAs A BPA P is a pair (p, ) where: p is a BPA process: p,p ::= 0 β p p p + p X is a set of BPA definitions: { X 1 = p 1 X k = p k } Standard LTS semantics. If P = (p, ) [[P]] = {β 1 β k p β 1 p 1 β k p k } Example: P = (X, {X = β X}) X β X β 0 X X β X β

88 From history expressions to BPAs Example H = β (µh. α + h h + ϕ[h]) BPA(H) = β X, { X = α + X X + [ ϕ X ] ϕ } Theorem: [[ H ]] = [[ BPA(H) ]]

89 From policies to scoped policies Example α w α r * A ϕ α r α w q0 q1 q2 Chinese Wall policy: no write after read

90 From policies to scoped policies α w α r α r, α w A ϕ[ ] α r α w q0 q1 q2 ] ϕ ] ϕ [ ϕ [ ϕ [ ϕ α r q0 q1 α w q2 α w α r α r, α w α w [ ϕ α r α w not valid

91 From policies to scoped policies Theorem: η valid iff η recognized by A ϕ[ ] for all ϕ occurring in η η w/o redundant framings ϕ[ϕ[ ]] =ϕ[ ]

92 Model- checking BPAs with FSAs Theorem: H valid iff [[ BPA(H) ]] = A ϕ[ ] ϕ in H

93 Main result Network N = l 1 { e 1 : τ 1 } l k { e k : τ k } 0, H i - e i : τ i for 1 i k If H i is π-valid then π is viable for e i

94 Summing up hypothesis: client with history expression H linearization: transform H into an equivalent H in linear form, i.e.: H = {π 1 H 1 π k H k } and the H i have no planned selections. verification: model-check the H i for validity theorem: if H i is valid, then π i is viable

95 Conclusions A linguistic framework for secure service composition safety framings, policies, req-by-contract type & effect system verification of effects, to extract viable plans The orchestrator securely composes and runs service-based applications

96 Other issues considered instrumentation: how to compile local policies into local checks, in case that some policy may fail resource creation: how to create fresh resources liveness: how to deal with properties of the form something good will happen multi-choice and dependent plans

97 Future work other kinds of plans (e.g. dynamic) other kinds of effects (e.g. sessions) safety framings and security protocols safety framings for information flow incremental analysis, when new services can be discovered at run-time trust relations between services spatial types and logics

98 References M. Bartoletti, P. Degano, G.L. Ferrari, R. Zunino. Secure Service Orchestration. FOSAD 07. M. Bartoletti, P. Degano, G.L. Ferrari. Planning and verifying Service Composition. To appear in JCS. M. Bartoletti, P. Degano, G.L. Ferrari, R. Zunino. Semantics-based design for Secure Web Services. To appear in IEEE TSE. M. Bartoletti, P. Degano, G.L. Ferrari. Plans for service composition. WITS 06.