Gabriela Gheorghe

Stephan Neuhaus

Bruno Crispo

xESB: An Enterprise Service Bus for Access and Usage Control Policy Enforcement

Enforcing complex policies that span organizational domains is an open challenge. Current work on SOA policy enforcement splits security in logical components that can be distributed across domains, but does not offer any concrete solution to integrate this security functionality so that it works across security services for organization-wide policies. In this paper, we propose xESB, an enhanced version of an Enterprise Message Bus (ESB), where we monitor and enforce preventive and reactive policies, both for access control and usage control policies, and both inside one domain and between domains. In addition, we introduce indicators that help SOA administrators assess the effectiveness of their policies. Our performance measurements show that policy enforcement at the ESB level comes with only moderate penalties. This work is supported by the European Commission under the project EU-FP7-IST-IP-MASTER.

messages themselves instead of the effect they have on the business process. Second, current approaches focus mostly on simple access control policies instead of complex organization-wide policies that also include usage control.

Another problem, one that plagues administrators of SOAs, is whether security policies perform as they should. The state of the art is to pepper the deployed services with debugging output, but this is clearly unsatisfactory, if not completely infeasible, for example when using third-party services.

This paper addresses all three issues by implementing flexible, instrumentable, and highly configurable policy enforcement mechanisms at the ESB level. We also cover access as well as usage control policies that can span the entire organization: our enforcement mechanisms implement reactions to violations in addition to traditional access control. Additionally, we augment policies with indicators that our ESB continuously monitors in order to measure how well the policies perform. By providing a unified and service-independent way to aggregate data, indicators help administrators understand, at run-time, why policies fail.

Besides addressing the issues of regulating message flow and allowing organisation-wide policies, our work also decouples the enforcement logic from the business logic. This way, process and application designers can focus on the business aspects of their applications and how they must be used, but not how this is technically enforced. Thus our contributions can be summarized as follows:

-A new approach for security policy enforcement for SOA (Sect. 4).

-A working prototype implementation of xESB, (Sect. 5), that has low overhead (Sect. 8). -Support for reactive policies, and for usage control policies (Sect. 6).

-Support for indicators to help monitoring policies (Sect. 7).

Introduction

As Service-oriented architectures (SOAs) expand, they need to interconnect and adapt to increasing business and infrastructural demands. These intercommunication and interconnection requirements are met by a piece of middleware called the Enterprise Service Bus (ESB). The ESB offers a standard way to connect services by acting as a message hub, making interservice communication smooth and painless. But this ease of use comes with a downside: when businesses expose their services in order to participate in an SOA, they face increased risks of misuse or abuse. What is therefore needed is a way to formulate and enforce policies that make such misuse or abuse impossible.

However, ESBs do not address non-functional aspects such as security, so what protects messages in transit and makes security decisions based on them? Since ESB components are using the bus as a low-level service which abstracts communication details from the higher-level services, we believe that it is the ESB that should be in charge of enforcing message-level policies.

There are two main aspects in which current work in SOA policy enforcement falls short of this expectation. First, the majority of existing work locates policy enforcement inside an orchestration engine such as BPEL, but such a view is not suited to scenarios where policies concern the service request or response The remainder of this paper is organized as follows. After showing our supporting case study (Sect. 2) and some background on the ESB platform (Sect. 3), we motivate why policy enforcement on the ESB is needed (Sect. 4). After that, we introduce our xESB prototype (Sect. 5) and briefly present the language we used to write our policies (Sect. 6). We next give an overview of some possible enforcement indicators (Sect. 7), and present a performance evaluation (Sect. 8). We finish with a review of related work (Sect. 9) and a discussion of future work and conclusions (Sect. 10).

Motivating Example

As motivating example to illustrate the design and features of xESB, we consider a hypothetical company 'Foo.uk', providing VoIP-based services using a communication platform implemented as a SOA using an ESB. While Foo.uk is hypothetical, the problems it faces definitely are not. For example, Zimmermann et al. published a large case study in which a "large telecommunication wholesaler" switches to BPEL and SOA, so it is clear that the wholesaler will also have to face security issues at the SOA level [START_REF] Zimmermann | Service-oriented architecture and business process choreography in an order management scenario: rationale, concepts, lessons learned[END_REF]. However, giving examples from actual companies would give much extraneous detail not relevant to this paper, and we have therefore stripped the examples down so that the relevant problems and their solutions can be exposed more clearly.

Since Foo.uk operates in the UK, it must comply with regulations such as those described in the Statutory Instrument 2003 No. 2426 [START_REF]The privacy and electronic communications (ec directive) regulations 2003[END_REF] implementing the Privacy and Electronic Communications EC Directive [3]. In order to do so, the Foo.uk platform must be able to enforce policies such as "Log starting time and duration of incoming calls" or "Hide initiator number in outgoing calls".

For the first policy, a simple mechanism should signal the start of a call and its duration. Capturing and logging these events should leave the application unaltered. What is therefore required is a control that is able to filter messages and to duplicate them to a logging service. For the second policy, a mechanism is needed to filter outgoing calls from incoming ones. This can be achieved simply by looking at the type and parameters of the event (either a service invocation or a service response) and then modifying those that identify the initiator. In addition, for business purposes Foo.uk must be able to enforce also policies like:

Silver customers can use premium services only for 3 hours a month. If the control service assigns special message identification that can easily differentiate between subscriber types and call types, Foo.uk needs logic to infer the duration of a call for a specified amount of time. Anytime a silver customer would request a video call, the request should not be serviced unless the 3 hours a month have not been exceeded. Thus, the service response depends on whether a predicate is satisfied or not.

Process collect calls only after destination has agreed to pay. Similar to the previous case, verifying a condition in this case means ensuring that something has happened in the past: the VoIP destination must have accepted to pay for the call. This predicate needs to be checked only before replying to a collect call request: the response is delayed until the destination either explicitly accepts or rejects the payment or times out (which should be construed as rejection).

Delay high-quality calls until resources are available. Assuming a VoIP user requests high quality parameters for a call, a load-balancer component of the SOA would have the authority to delay the service request until it allocates the resources needed for such a situation.

Enacting the rules above can be done by a dedicated component acting as gateway for rule compliance: as an infrastructure component, it would interpose between the VoIP provider and the service clients. Having an application-level module in charge of this would be inefficient because the above policies do not directly relate to application logic; they concern legal issues that the VoIP communication protocol should obey, irrespective of its conceptual design or its architecture. These issues, or constraints, can be more frequently subject to change (or update), than the overall SOA application. We argue that it is best to separate the constraint checking functionality from the business application in such a way that the former can easily adapt to new organizational requirements.

If a new business or regulatory policy would replace an existing one (e.g., not hide, but encrypt initiator number in outgoing calls), then the changes on the enforcement logic should be as light as changing a service endpoint (from one that hides data to one that encrypts data). This behavior would be in complete resonance with the concepts of service-orientation and reuse, because it brings a clear decoupling between service logic and service security. Such a separation has not been previously addressed at the message level, and our solution benefits from this approach in that the prototype is not hardcoded to a specific decision making or enforcement component; any trusted security components of these types can be plugged in.

3 The ESB in the Service-Oriented Architecture

The ESB is a middleware placed between the various services of an SOA application. It offers a layer of communication and integration logic in order to mitigate technology disparities between communication parties, ranging from intelligent routing to XML data transformation.

Java Business Integration (JBI) [START_REF] Sun | Java Community Process Program: Sun JSR-000208 Java Business Integration[END_REF] standardizes deployment and management of services deployed on an ESB. It describes how applications need to be built in order to be integrated easily. The generic JBI architecture is shown in Figure 1 (left). Since the primary function of the ESB is message mediation, the Normalized Message Router (NMR) is the core of the JBI-ESB and provides the infrastructure for all message exchanges once they are transformed into a normalized form. Components deployed onto the bus can be either service engines, which encapsulate business logic and transformation services; or binding components, which connect external services to the JBI environment. by delegating them to a trusted third party). This section describes how we modeled the policy enforcement process that we later implemented in xESB.

The policy language and its interpretation are the subject of Section 6.

Interception

Enforcement starts by intercepting messages to which at least one policy applies. The policies dictate what message types and parameters to look at: message destination, source, size, or metadata like annotation information. Irrespective of the message format (usually XML-based), the elements described above are usually easy to inspect on every message simply because all messages on the bus have the same format. A prefiltering mechanism can help the interceptor catch messages with a higher probability of being relevant than any other message; for instance, if a policy refers to requests that are simultaneously outgoing and have a valid security signature, then the interceptor could just check if the current call is outgoing. This is a condition which is inexpensive to check compared to the validity of the signature, and if it does not hold then the signature need not be validated. Figure 1 (right) shows the format of a message on the NMR; because of the normalized format, split into structured metadata and payload, the message destination and the direction of the message can be easily extracted and compared against given data. This simple mechanism is an easy way to separate incoming calls from outgoing ones, based on message metadata.

Decision

Once a policy-relevant message is intercepted, it needs to be evaluated against the applicable policy (see Fig. 2). The decision component does policy matching: it examines all policies in the policy base (or policy repository) by evaluating them against the current message. The evaluation is done by comparing message context and actual parameters (e.g., destination service, source service, message type, etc) with the conditions required by interested policies. We considered the simple case of comparing the message against all policies in the policy base, until the first match is found.

The output of the decision phase is called the verdict. This enforcement decision is binary: either the message is legitimate, or it is a policy violation. While the first case implies that there will be no consequences onto the message flow, the second case calls for one or more enforcement actions. These actions are detailed below.

Actions

The third step of enforcement is to take action based on the verdict that was reached in step 2. We have implemented five basic enforcement actions that implement the four mechanisms formalized by Pretschner et al. [START_REF] Pretschner | Mechanisms for usage control[END_REF] to approach usage control enforcement:

The acceptor accepts whole messages. If the verdict does not indicate any policy violation, then the acceptor is invoked, with the effect that the message is allowed without any modification. The blocker rejects whole messages. Contrary to the previous case, the blocker mechanism is invoked to react to a policy violation by rejecting the entire message and sending back an error message. The modifier pertains to the class of mechanisms that modify a message. The point is to go beyond the classic "all or nothing" enforcement approach and modify the message so that it conforms to the given policy. The delayer refers to the class of mechanisms that postpone a message until a condition is satisfied. This mechanism maps to the idea of obligation enforcement, where an actor would be allowed to perform an action only after a condition has been verified. For instance the policy "Delete all traces of a call after the call has been terminated and paid" can be implemented by delaying the deletion of call traces until the arrival of a message that signals a call that is terminated and paid for. The executor enables complex actions. In some cases, the reaction to a violation may require the execution of a complex recovery process that requires more than the basic mechanisms implemented by xESB. Implementing these mechanisms in xESB would make it inflexible, so xESB uses the executor to invoke an external service or process, which can also be an orchestration engine.

Actions can be differentiated as preventive or corrective. Preventive actions ensure that a policy violation will not happen: prior to allowing a sensitive action, they check its compliance with the policies. Corrective actions, on the other hand, try to compensate a violation that already happened. The blocker is a preventive mechanism: if a message on the ESB is not allowed to reach its destination, then it is simply dropped. The other actions-modifying, delaying, calling an external entity-are by their nature compensatory: if an intercepted message or a group of messages already constitute a policy violation, an appropriate action must be taken to correct the respective message or message flow (e.g., reroute to a secure service, deny further messages on that route until next day, etc.). The executor mechanism can be both preventive and reactive. We see the actions described above as enforcement primitives on ESB messaging. Because implementing a blocking, modifying, delaying and executing mechanism should be different from application to application, we argue that our design caters to a customizable ESB enforcement framework. Our model provides a set of basic components -the interceptor, the decision maker, the action performer -and the wiring between them; the semantic behind the enforcement actions and the policies are independent of the solution design. In a JBI service bus, the component that mediates all communication is the normalized message router (NMR). It is therefore natural to embed an interposition mechanism within the NMR, in order to capture incoming messages on their way to their destination, be it before being processed (service requests) or after being processed (service replies).

Once the message has been intercepted, the next step is to analyze the messages just captured. The JBI standard helps us again: the messages being routed are normalized before they get to the router; this means that they are transformed to a fixed format that separates clearly the XML payload of a message, the message context (metadata) and message attachments (the format is given in Figure 1). This feature makes it feasible to analyze parts of a normalized message. In order to derive a verdict, we designed the analysis component to compare the metadata of a current message with the metadata specified by the policies in the policy base. By metadata, we mean information such as message source and destination; by context we mean any flow-related condition, such as a constraint that pertains to message flow precedence (e.g., an incoming call was not logged before it was accepted), or usage control-specific constraints that mainly involve counting (e.g., a silver customer has used 2 hours of premium services this month) or obligations (e.g., silver customers can use video calls for no more than 3 hours a month). With some information on the state of a service or a message, the problem of comparing the current intercepted message against the business constraints in the policy base is described in Sect. [START_REF] Ueno | Early capacity testing of an enterprise service bus[END_REF].

Once a verdict is reached, the action performing phase consists of one of the actions given in Sec. 4.3. xESB implements message blocking by sending the current message not to its desired endpoint but to a loopback interface (the request initiator can receive nothing or a fault message); the xESB modifier simply replaces parts of the message header as specified by the policy; the delayer routes the message to a delayer component that puts the message in a queue and removes it again when the condition associated with it is satisfied (be it time or a boolean condition); lastly, the executor is implemented by routing the current message to the endpoint of the desired service. An underlying assumption of the design is that the xESB mechanism is always invoked because the NMR processes every message. The xESB is trusted to always invoke the PEP, and the enforcement actions are on services that are deployed on the ESB (hence a service not deployed on the bus is not known to xESB). Therefore, xESB acts as a reference monitor.

Performance considerations made us embed the modifying and rerouting functionality into the component that does message interception on the bus. The specific delaying and blocking behavior were implemented as separate components (namely, plain Java objects) to which the NMR would direct messages. Thus, while the intercepting mechanism is ESB platform-specific, we aimed to make the analysis and action hooks reusable across applications. The logic to decide on the enforcement verdict can be reused irrespective of the deployed policies, but the actions matching this verdict are application-dependent. This design has flexibility as its greatest advantage; for instance, it does not rule out the call-back to an analysis component that is application-logic aware, and that might be interested to analyze message payload in order to make an enforcement decision. In addition to this aspect, we have also incorporated support for indicators within our xESB. Section 7 will discuss indicators in greater detail.

Enforcement Language

As we have shown in Sect. 4.3, we wish to enforce not only by control, but also by reaction. Reaction covers temporal and transient obligations to which any entity in the distributed environment can be bound. Existing languages and language frameworks address only some of these aspects (see Sect. 9). Consequently, we have created our own policy language.

A policy is written as text, which is compiled into binary form. During execution, the compiled policy file resides in memory and is interpreted by a stack machine. Policy turnover is at the moment not implemented, but we do not see large technical difficulties in doing so: turnover is problematic only for enforcement on message exchanges or sessions, where different policies may have to be applied to different messages. Since we enforce policies one message at a time, such problems do not exist in xESB.

Policy Files

Policies are expressed as a sequences of rules, expressed in Event-Condition-Action form. A message is sequentially checked against the rules until either a rule applies or there are no more rules. Figure 4 shows how the policy "Silver customers can use video calls for no more than 3 hours a month" would be expressed in this language. From this example, we can see that the policy language contains the following components: Default Action. This allows allow-based or deny-based policies. Counters, Timers, and Hashes. These declare items of state, which are pieces of data that keep their values across policy checks. There are three types of state: counters, timers, and hashes. The latter keep arrays of state, thus allowing state per user or state per messge source etc.

Rules and Obligations. Rules and obligations are very similar. However, rules compute verdicts such as block, allow and so on. When a rule that carries a verdict matches a message, the action part of that rule is executed and processing is stopped. On the other hand, obligations exist solely for the purpose of updating state, so processing continues.

Event, Condition and Action Specifications. The event part of a rule or obligation checks if the message is a request or a response. Conditions are part of a rule or obligation and checks whether the rule or obligation applies to the current message. The action specification of a rule or obligation can update state (both rules and obligations) or return a verdict (rules only).

What is the overall effect of this policy file? The first obligation takes care of rearming the timer if it has fired. The second obligation updates the length of video calls, and the rule blocks video calls in excess of three hours. Identifiers such as 'type', 'source', 'destination', etc. refer to names of the metadata fields in the normalized message.

While this example illustrates the main features of the language, some other features of interest include:

Modifying message metadata. The language construct "modify h metadataname = string-expression" modifies parts of a message's metadata, i.e., anything outside the message payload. Modification lets the message pass after modification. Delaying a message. One possible verdict is "delay n", which means to delay the message by a specified amount of time. This implies allowing the message to pass eventually. Delay until a condition is met. Another innovative verdict is "delay until condition", which will delay a message until a certain condition is met. The condition can be any boolean expression on the state (but not on any message headers). This is not the same as bocking a message, since a message is completely discarded when it is blocked, whereas here it is merely delayed.

Cross-Service Policies

To show that we can use xESB to enforce cross-service and hence potentially inter-organisational policies, let us consider the regulatory requirement to hide initiator numbers in outgoing calls. Since this policy holds for video, audio and ordinary phone calls, it affects potentially many services and therefore also potentially different organisations within Foo.uk. Figure 5 shows how to express this policy. Note how simple this policy is to implement on the ESB level. On the BPEL level, it would be much more complicated, because a generic anonymisation service would have to be written and deployed, and message transformation would have to be performed at the BPEL level.

default-action { allow; } rule { if invocation when { h "Type" equals "start-call" } do { modify h "Initiator" = "000000"; } } Fig. 5. Policy expressing "Initiator numbers need to be anonymized for outgoing calls". services based on security parameters or on the history of requests from a caller. For example, if a caller is denied access three times in a row, we block access permanently. Limiting the number of requests from a particular client to a particular service can prevent DoS attacks; see Fig. 8.

It can be noticed from the examples above that we can derive a number of useful indicators by combining mechanisms for counting, using flags for flow precedence, inspecting message types, sizes and message parts. Our language and our intercepting mechanism can be used to count specific events and reason on message precedence, as well as inspecting message properties.

Performance Evaluation

To implement xESB, we chose Apache Servicemix 3.3, a JBI-compliant open source ESB. We used the Servicemix API to intercept messages according to Fig. 3. This section describes the evaluation of our prototype implementation.

We followed a capacity testing model [START_REF] Ueno | Early capacity testing of an enterprise service bus[END_REF] to measure the lower bound of the instrumentation overhead. We used the sample SOAP that come with ServiceMix 3.3, and soapUI as a tool for load generation 3 . We used SOAP messages of 8 Kb 3 http://www.soapui.org/ q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q 0 5 10 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q 25 50 75 size and a varying number of parallel clients. Our testbed PC was a 32-bit system with a 2.6GHz processor and 3GB of RAM. The JVM was allowed 1280MB of memory, with a ServiceMix queue size of 256 requests.

To answer the question "how does the number of rules in a policy file affect the round-trip time (RTT) of messages?", we constructed policy files of 0, 5, 10, 25, 50, 100, and 200 rules such that in all files, only the last rule would ever match. Therefore we are actually measuring the effect of checking the rules, not simply loading a larger ruleset, which would have almost no effect. For each policy file, we then used SoapUI to send 8 Kb messages to xESB using 100 parallel threads for 3 minutes. We repeated this process 3-5 times. Since SoapUI does not return the RTT for individual messages, we looked at the average RTT. The results are plotted in Fig. 9, left. The most important conclusion is that xESB is almost unaffected by the size of the policy file: the main delay seems to be in message processing, not policy enforcement. In fact, profiling shows that policy enforcement takes only about 0.2% of CPU time.

The next question we asked is "How does the number of parallel clients affect the RTT?". Using a similar method as above (8 Kb messages using 100 rules for 3 minutes, repeat 3-5 times, then look at the average RTTs), we arrived at Fig. 9, right. As expected, both the average RTT and the variability rise linearly.

A curious feature that can be seen in the figure is the tremendous variability in RTT. Since this variability also shows in the uninstrumented ServiceMix, we conclude that policy enforcement is not responsible for this. We conjecture that this is due to the staged-event architecture of ServiceMix, where processing is done in bursts because computation happens in stages 4 .

There is a large number of security standards that cover XML message validation, authorization, encryption or even federated authentication: OASIS's WS-Security, SAML, XACML 5 , and other WS-* specifications. These standards only deal with particular narrow issues of SOA scenarios (point-to-point authentication, authorization, message integrity, etc.) and not with SOA policy compliance.

The work on enforcing security at the message-level is limited to considering access control policies. The solution of Svirskas et al. [START_REF] Svirskas | Towards secure and trusted collaboration environment for european public sector[END_REF] is limited to controlling service access and logging on the ESB. A similar approach [START_REF] Leune | Exploring a multi-faceted framework for soc: how to develop secure web-service interactions? Research Issues on Data Engineering[END_REF] suggests several infrastructure security services to act on different types of events by means of a gateway, but the separation between business and security concerns is not clear. Maierhofer et al. [START_REF] Maierhofer | Extendable and adaptive message-level security enforcement framework[END_REF] describe a dynamic enforcement framework for security at the message-level, but do not discuss interoperability nor implementation. Another solution [START_REF] Goovaerts | Infrastructural support for enforcing and managing distributed application-level policies[END_REF] suggests a custom security service bus for enforcement of complex policies. Other conceptual approaches based on law-governed interactions [START_REF] Lam | A collaborative framework for enforcing server commitments, and for regulating server interactive behavior in soa-based systems[END_REF] aim to model enforcement of laws onto communication between servers and clients, but they consider generic distributed dedicated entities to perform the law realization. Our assumption differs in that it uses the ESB as a centralized mechanism that either performs on-the-fly enforcement or delegates it to a trusted entity. We explicitly focus on access and usage control policies, and unlike other approaches, we offer a concrete model and a proof-of-concept implementation.

Concerning the policy language, elaborate access control languages (e.g., Ponder [START_REF] Damianou | The ponder policy specification language[END_REF], EPAL [START_REF] Backes | A toolkit for managing enterprise privacy policies[END_REF], SPL [START_REF] Ribeiro | Spl: An access control language for security policies with complex constraints[END_REF]) are unable to express obligations that pertain to usage control. More generic usage control centric languages are POLPA [START_REF] Baiardi | Improving grid services security with fine grained policies[END_REF] and OSL [START_REF] Hilty | A policy language for distributed usage control[END_REF]; while the former does not explicitly address obligations, the latter is not supported by an implementation. Unaware of any implementation of a generic usage control language that supports compensations, we have developed a proof-of-concept policy language fit for the ESB. Compared to theoretic works on access control compensations [START_REF] Povey | Optimistic security: A new access control paradigm[END_REF], violation management [START_REF] Brunel | Security policy compliance with violation management[END_REF] and obligation assessment [START_REF] Irwin | Assigning responsibility for failed obligations[END_REF][START_REF] Irwin | On the modeling and analysis of obligations[END_REF], we go beyond access control and provide an implementation of compensations on the fly. This means that whenever a violation of some service usage rule is detected, the correction happens as the event travels through the system, before it reaches some interested party.

In usage control enforcement [START_REF] Park | The UCONABC usage control model[END_REF], Katt et al. [START_REF] Katt | A general obligation model and continuity: enhanced policy enforcement engine for usage control[END_REF] add the notion of postobligations to the obligation model; they consider and implement a mechanism for ongoing enforcement. The work of Pretschner et al. [START_REF] Pretschner | Mechanisms for usage control[END_REF][START_REF] Pretschner | Policy evolution in distributed usage control[END_REF] describes a formalized usage control language and the mechanisms to enforce such a language, but do not cover an enforcement model for SOA. xESB reuses these enforcement mechanisms as well as idea of post-obligations but applies them for the first time to the ESB level.

The paper presented xESB, an instrumented JBI ESB for the enforcement of security policies that are organization-wide. xESB is able to enforce both access and usage controls policies. The rich enforcement semantics of xESB allows not only to reject ESB messages that violate a policy but also to compensate that violation. xESB also introduces and supports indicators aiming to help the security administrator analyze and derive useful information about policy violations (e.g., discover configuration mistakes) and their impact to the overall security of the organization. While initial performance tests are very promising, we are planning to xESB with a commercial SOA application and run more extensive tests to validate the initial results.

We are currently working to extend xESB on four aspects:

Optimization. In a large policy file a lot of time is spent evaluating conditions in order to find those rules or obligations that apply to a given message. To improve this, we will implement some form of the Rete algorithm [START_REF] Forgy | A network match routine for production systems[END_REF], or select rules according to which message parts appear in where-clauses. Conditions on message payload. We will extend xESB so that complex conditions on the message payload can also be evaluated. We will most likely base this capability on XPath. Performance measurements. Apart from measuring the performance impact of the executor and modifying mechanism, we plan to evaluate different policy engines against our enforcement design, thus checking its extensibility. Performance indicators. We will implement performance indicator support in order to derive general information on the runtime enforcement process (e.g., statistics on the rules that are frequently enforced or violated).

Fig. 1 .

 1 Fig. 1. The architecture of the JBI system (left) and example of a normalized message in an InOnly exchange (right)

Fig. 2 .

 2 Fig. 2. The enforcement process behind xESB

Fig. 3 .

 3 Fig. 3. The xESB enforcement architecture. The solid arrows indicate the invoke chain, while the dotted arrows show the response chain. Both request and response are intercepted. The policy is only on requests from Client 1 to Provider 2, hence the interceptor gives the request to the PDP, and then passes the response from the PDP to the PEP.

Fig. 4 .

 4 Fig. 4. Policy for "Silver customers can use video calls for at most 3 hours a month".

2

 2 Fig. 5. Policy expressing "Initiator numbers need to be anonymized for outgoing calls".2

Fig. 8 .

 8 Fig. 8. Indicators for misuse or attack: counting recursions (left), preventing DoS or password guessing (right).

Fig. 9 .

 9 Fig. 9. RTT for varying policy file sizes (left) and varying number of parallel connections (right), for 8 Kb messages. The x axes are not uniformly spaced.

The Enforcement ProcessThe runtime enforcement process starts the moment a message is intercepted. Once obtained, the event is evaluated against the deployed security policies; the result is a decision that the enforcer translates into a series of actions; the enforcement process is in charge of performing those actions (either directly or

Staged Event-Driven Architecture http://www.eecs.harvard.edu/ ~mdw/proj/ seda/

These OASIS standards can be found at http://docs.oasis-open.org

Figure 6 shows the two remaining policies from Sect. 2, namely "log start time and duration of calls", and "accept collect calls only after destination explicitly accepts to pay".

Enforcement Indicators

As previously mentioned, we want indicators to give a quantitative measure of the quality of the enforcement process. We will provide some examples of possible ESB-level indicators that have an impact over the assessment of policy enforcement. We split them in two basic types:

Indicators for misconfiguration. By counting repeated violations from a particular service, an indicator can show that the service always violates the policy no matter the user on whose behalf it works. This would mean that the cause is not the user nor the way the service is used, but rather the way in which the service is configured. Another example is an indicator that can quantify how many services do not follow deployment or runtime constraints such as: using disallowed protocol versions, being in disallowed service states or deploying services that should not have been deployed. That may be a more general indicator for misconfiguration of the overall application. We show two simple examples in Fig. 7.

Indicators for reaction to misuse/attacks. Recursion in service chains can impact service availability because it can lead to deadlocks. Counting and limiting the number of times this happens may be an indicator of service availability. An example of an indicator preventing attacks is disabling access to 2 The modify action implies a verdict, hence this is indeed a rule, not an obligation.


Alain Sarlette
email: alain.sarlette@inria.fr

Mazyar Mirrahimi
email: mazyar.mirrahimi@inria.fr

Loss-tolerant parity measurement for distant quantum bits

Thanks to cat-state probes, we propose a scheme to measure the parity of two distant qubits, while ensuring that losses on the quantum channel between them does not destroy coherences within the parity subspaces.

The correlation of distant systems through entanglement is a hallmark of quantum physics and plays a fundamental role in envisioned quantum technology. E.g. towards future quantum computers, quantum teleportation could transport information between few-qubits processing units and well-protected memory units [1]. A major challenge towards enabling these applications is that generating entangled states between distant systems must rely, itself, on a quantum channel. Microwave experiments have demonstrated how to deterministically entangle separate quantum subsystems via parity measurements [2], yet with a fidelity directly limited by the quality of the quantum channel. Heralding and distillation allows to generate high-fidelity entanglement, with channel losses affecting preparation success only [3][4][5]. The present proposal aims at deterministically stabilizing entanglement, with minimal resources, thanks to a channelloss-tolerant joint parity measurement.

An ideal Eigenstate-Preserving Quantum Non-Demolition (EP-QND) measurement of the joint parity of two qubits would have outputs +, -, with associated projectors

Q + = |00 00| + |11 11| , Q -= |01 01| + |10 10| .
This can be effectively achieved in a standard way with a single probe qubit that starts in state |0 , consecutively undergoes a CNOT conditioned on each individual target qubit, and finally is measured in the canonical basis |0 , |1 . The issue is that when the probe undergoes channel losses between its interactions with the two target qubits, entanglement is in general irremediably lost. However, as already noticed in a distillation context [4], things can get much better if the channel loss can be restricted to a operator, e.g. bit-flip. In this case indeed, the QND character is preserved and only the contrast of the parity measurement is reduced.

The key of our proposal is therefore and implementation where the physical noise channel on the probe, i.e. the photon loss operator, reduces to a stochastic bit-flip effect. This is obtained by encoding the logical |0 , |1 states of the probe into so-called "cat states" of an electromagnetic field pulse: The evolution implied by one measurement iteration on the target qubits' joint state, can be described by two superoperators K + and K -, depending on the detection outcome (+) or (-). In absence of channel loss, η = 0, we have K ± (ρ) = Q ± ρQ ± . Finite channel loss η > 0 has a primary and a secondary effect. The primary effect is to reduce the contrast, i.e. have slightly different energies, such that the rate of photon loss contains slight information allowing to discriminate in which of the two states we were after interaction with the first target system. Accordingly, this loss becomes negligible for a choice of α 1. As a tradeoff, larger α imply slower convergence via r parity , which can be detrimental when the target qubits' finite lifetime is taken into account. Thanks to the near EP-QND character of our parity measurement, the long-term fidelity decay can be countered in order to stabilize a particular Bell state with a simple feedback protocol. To stabilize |00 + |11 , (i) apply a π-pulse around the X-axis on the first qubit whenever the measurements estimate a probability higher than 1/2 to be in the odd parity subspace, (ii) after that, apply a π/2-pulse on both qubits around the Y -axis irrespectively of the detection result. The measurement back-action favors convergence towards the dominant parity, the π pulse correcting the parity whenever this is not even. This pushes the state towards the span of |00 ± |11 without favoring the target +. The two π/2-pulses then leave |00 + |11 untouched and send the undesired |00 -|11 onto |01 + |10 , such that the next parity measurement stochastically moves the corresponding population as well towards the target. Figure c shows a simulation of the expected steady-state fidelity achievable by selecting the optimal value of α, as a function of channel loss rate η and expected bit-flips per measurement iteration T d /T 1 . A 99% entanglement fidelity appears within reach of state-of-the-art experiments.

C ± β = (|β ± |-β ) / N ± β , N ± β = 2 ± 2 e -2|β | 2 ,
K + (ρ) = (1 -ξ )Q + ρQ + + ξ Q -ρQ -with 0 < ξ < 0.
Indeed, all the required operations for this proposal have been individually implemented within the framework of quantum superconducting circuits. The strong dispersive coupling of a transmon qubit to a high-Q cavity mode, provides universal controllability of the state of the quantum harmonic oscillator modeling the cavity mode [6,7], with a coupling strength, and hence the number of gate operations that limits a single measurement duration, more than three orders of magnitude larger than both the qubit and the cavity decay rates. Recent experiments realizing a variable coupling between cavity modes and a transmission line [8], provide the catch-gate-release capability on the propagating microwave field. The final measurement can be performed in any convenient basis after tweaking U B .

The authors thank the Agence Nationale de la Recherche for financial support under grant ANR-14-CE26-0018. For more details, see our paper [9].

  where |β denotes a coherent state (quasi-classical state) of phasor amplitude β ∈ C. The normalization constants N ± β rapidly approach √ 2 as β increases. In our scheme, shown on Figure a, the probe field is initially prepared in |C + α p and interacts with two qubit-cavity target systems in a cascaded manner. These are performed by unitary operations U A and U B which perform the CNOT switch from C ± β to C ∓ β , at the respective amplitude β of the field reaching the respective qubit (β = α for U A and β = √ ηα for U B ). Indeed between the two target setups the probe is exposed to losses, modeled as mixing with the vacuum state |0 env of an ancillary mode through a beam-splitter unitary operator U η BS with transmittance √ η and reflectance √ 1η. Finally a measurement projects the probe's state onto C + √ ηα (+) or C - √ ηα (-) e.g. through parity discrimination.

5 . 2 . 2 1-e -4η|α| 2 .

 5222 This leaves invariant a state of definite parity, e.g. K -(|ψ ψ|) = K + (|ψ ψ|) = |ψ ψ| for any |ψ = c 1 |00 + c 2 |11 . However, such |ψ will give both (+) and (-) detections, just with predominance for (+), while a perfect parity observation would never give (-) detections. The resulting convergence from an initial state (|e + |g )(|e + |g )/2 towards a Bell state of definite parity B e + = (|00 + |11 )/ √ 2 or B o + = (|01 + |10 )/ √ 2 is visible as the fast initial evolution on Figure b, for various probe field intensities |α| 2 and transmission efficiency η = .75. The convergence rate can be computed as approximately r parity = The secondary effect of channel loss is a slight violation of the QND character, i.e. a loss of coherence inside the same parity subspace span(|00 , |11 ). This loss of decoherence occurs at a rate approximately r dephasing = 1 2 log 1-e -4|α| On Figure b, this leads to the slow decay of fidelity. The latter is only due to the fact that C + β and C - β

  Photon-number parity detector