Secure and Unfailing Services 169
q1
start q2 q3
q4 q5
q6
αsgn(x),x∈bl
αsgn(x),x∈bl
αp(y),y≤p
αp(y),y>p
* αta(z),z≥t
αta(z),z<t
*
*
Fig. 1.The automaton for the policyϕ(bl,p,t)
that the involved services never go wrong at run-time, in that they are capable of successfully accomplishing their tasks (progress property) without raising any security exceptions. Therefore, no run-time monitor is needed, to control the execution of the network of services.
The paper is organised as follows. The next section intuitively presents our formalism, the problems and our goal through an example. Sect. 3 formalizes the main aspects of our proposal, defines the syntax and the semantics of history expressions; it recalls the methodology of [5,4] and shows it applicable to our case for verifying the security aspects of services. The definition of compliance, its reduction to a safety property and the technicalities needed to model-check it are in Sect. 4. In Sect. 5, we discuss our results and future work.
C1=open1,ϕ
({s1},45,100)Req(CoBo.P ay+N oAv)close1,ϕ({s1},45,100)
C2=open2,ϕ
({s1,s3},40,70)Req(CoBo.P ay+N oAv)close2,ϕ({s1,s3},40,70)
Br=Req.open3,∅IdC.(Bok+U nA)close3,∅(CoBo.P ay⊕N oAv) S1=αsgn(1).αp(45).αta(80).IdC(Bok⊕U nA)
S2=αsgn(2).αp(70).αta(100).IdC(Bok⊕U nA⊕Del) S3=αsgn(3).αp(90).αta(100).IdC(Bok⊕U nA) S4=αsgn(4).αp(50).αta(90).IdC(Bok⊕U nA)
Fig. 2. Two clients, a broker and four hotels
differ only in the way they instantiate their policies. The client opens a session and sends his request to the broker, who must respect the policy ϕ. Sending the request is modelled by the actionReq, while receiving the request is done throughReq, the complementary action (for the sake of simplicity we omit the data needed for booking the hotel). The client is then willing to receive the confirmation of the booking and to settle the bill (CoBo.P ay). The client is also ready to receive a negative message of no rooms are available (N oAv). When either message is received, the session with the broker is closed. As said, the broker receives the requestReq and then opens a session with one of the hotels.
The broker sends the Id of the client and all the data withIdC, and then waits either the booking or the negative message with (Bok+U nA). Then the session with the hotel is closed, and the response message is forwarded to the client.
The hotel services perform the events of signing and publishing the price and rating; and then interact with the broker. Note that all services, except forS2, have theinternal choiceBok⊕U nAand decide on their own which message to send. Note that the internal choice is different from the external choice in, e.g.
Bok+U nA, that is instead driven by the message received. SinceBris ready to receive each sent message, we say that the mentioned services arecompliantwith Br. Instead, serviceS2isnot compliant withBrsince it can send a messageDel (meaning that there will be available rooms later in the week) that the broker is not able to handle, and the interaction gets stuck. As far as security is concerned, it turns out that the servicesS1andS4violate the policy ofC1, sinceS1is black listed andS4respects neither thresholds; while the servicesS1, S3do not satisfy the policy ofC2 since they are black listed.
Figure 3 displays a fragment of a computation. It is a sequence of config- urations χ and of transitions χ →γ χ, where γ records either an event or a communication made of two complementary actions (disregard for a while the indexesπ, R of the arrows). A configuration is made of tuples η, : S, put in parallel (through ), where η is a sequence of events, is the location of the service/clientS. In our example, the starting configuration has the two clients, one on locationc1, the other onc2. Both performed no actions, so their exe- cution history is empty (ε). The first step opens a session betweenC1 and Br
Secure and Unfailing Services 171
ε, c1:C1ε, c2:C2open→1,ϕ1π,R ϕ1,[c1:Req.(CoBo. . . .)close1,ϕ1, br:Br]ε, c2:C2→τπ,R ϕ1,[c1: (CoBo. . . .)close1,ϕ1, br:open3,∅IdC . . .]ε, c2:C2open→3,∅π,R
P
ϕ1,[c1. . . ,[br:IdC . . . , s3:αsgn(3). . .]]ε, c2:C2open→2,ϕ2π,R
P
Q
ϕ2,[c2:Req . . .close2,ϕ2, br:Br]αsgn(3)→ π,R αp(90)
→ π,R αta(100)
→ π,R
η
ϕ1αsgn(3)αp(90)αta(100),[c1:. . . ,[br:IdC . . . , s3:Idc . . .]]Q→τπ,R→τπ,R η,[c1:. . . ,[br:close3,∅. . . , s3:ε]]Qclose→3,∅π,R η,[c1: (CoBo.P ay+N oAv)close1,ϕ1, br: (CoBo.P ay⊕N oAv)]Q→τπ,R
η,[c1:close1,ϕ1, br:ε]Qclose→1,ϕ1π,R
ηϕ1, c1:εϕ2,[c2:Req. . . . , br:Br]→τπ,R . . .
Fig. 3.A fragment of a computation
and registers in the history that the whole session, in particularBr, is subject to the policy ϕ, duly instantiated (call it ϕ1 =ϕ({s1},45,100)). The second step shows that the request of the client has been accepted by the broker, via a com- munication. Now a nested session is opened involving the broker andS3, in the third step, and no policy is put over the called serviceS3.
Concurrently,C2 can ask for a reservation, as expressed by the fourth step1, that registers that the policyϕ2=ϕ({s1,s3},40,70)is active. Note that we assume that the broker can replicate its code at will.
The two parallel sessions can evolve concurrently. For simplicity, we proceed with serviceS3, that signs, shows the price and its rating (all displayed in the same line). The broker is ready to send the client’s data toS3, and to receive back an answer, say “no room is available” (S3 is now ε, because it has no further activities to do). The session is then closed in the 10th step, and the broker resumes its conversation with the clientC1, and forwards the non-availability, in step 11. The next steps close the session numbered 1 and the security framing ofϕ1. The last transition continues the session involving the second client.
The index Rof the arrows shows that the transitions depend on the services contained in the repositoryR.
The index π is a vector of functions, called a plan, that indicates how the requests are bound to services. The planπ1 for the first client maps the request
1 Our present framework deals with concurrency in an interleaving style, so the ac- tivity of the clients, the broker, the hotels are interleaved; for a more realistic, truly concurrent approach, see [15]).
1, originated byopen1of the client, to br, and the request 3 fromopen3 of the broker, tos3. We callπ1 valid, because it drives a computation where both the security constraints and compliance of clients/services are guaranteed.
Suppose now that the plan π2 for the second client maps request 2 to br
and request 3 (from the second instance of the broker) tos2. SinceS2does not comply withBr, at run-time a communication involving the actionDelcannot be performed because the broker has no actionDel. Our assumption that the service can decide what to send on its own is violated. For this reason, we say that this plan is not valid. Finally, consider a plan that maps request 3 to s3, that this time is compliant with the broker. HoweverS3 is black-listed by C2, and so a policy violation occurs; also this plan is not valid.
Our task in the next sections will be defining a static analysis that allows us to construct valid plans, only. With such plans, neither violations of security, nor missing communications can occur, so there is no need for any execution monitor at run-time.