ASSERT ENABLED SERVICE MARKETPLACE

Figure 8.1: ASSERT Enabled Service Marketplace (AESM) and its stake-holders.

and based on other results from the EU project ASSERT4SOA. A high-level overview of the AESM is shown in Figure 8.1 that presents the different stakeholders interacting with AESM.

The AESM prototype that we propose, demonstrates the application of the Digital Security Certificate concepts proposed in the thesis along with the service discovery concepts proposed in ASSERT4SOA project to a business-oriented service marketplace and highlights key benefits that these approaches can bring in such a scenario. Through the AESM, busi-ness consumers can browse a catalogue of certified applications and ser-vices, can express their security requirements and compare services based on their certified properties; also, using ASSERT4SOA matchmaking ser-vices, the AESM automatically ranks the available candidate services based on how well their certified properties match the user’s security require-ments. From the standpoint of a business consumer, the AESM covers three key functional areas, outlined below.

(i) Defining explicit security requirements. In order to take into ac-count the security requirements of business consumers, the market-place should allow for expressing these requirements explicitly. In 135

real-life scenarios, there may be different actors that could access this function besides the user that directly subscribes to services from the marketplace (the buyer). In larger organizations there can be a cen-tral office in charge for defining the security policies that consumers must comply with when subscribing to a service.

(ii) Searching based on security requirements. Service subscribers should be able to use the security requirements to search the marketplace for the services that meets their requirements. The process of matching requirements with the certified properties of the services offered on the marketplace should be as simple and quick as possible, and the security characteristics of each certified service should be readily ac-cessible to the user.

(iii) Automated matching and approximate solutions. Among the re-sults of a search, the buyers should be supported in finding the best fitting solution. If no candidate matches the security requirements exactly, the marketplace should suggest the closest match to the se-curity requirements, ultimately allowing the buyer to take a rational decision based on all the information available both about the func-tionality and the security properties of each candidate.

Each of these three points has been implemented in the prototype. Their usage is illustrated in the next section.

8.1.1 Typical usage scenario: a walk-through

The marketplace permits users to search for services on the store with multiple filters, including security properties, keywords and other store spe-cific filters. The workflow below presents a typical usage scenario of the system, specifying how it caters for the requirements of the service con-sumers, who are responsible for subscribing to business services respecting the security requirements imposed by corporate policies, customers needs, applicable laws, and regulations.

Searching for secure business services

As in all marketplace store-fronts, the user can search the repository of available applications and services, browsing by categories (business areas, industries) and/or specifying one or more keywords in the search field. Dif-ferently from existing marketplaces, the security properties of the services in the result list represented explicitly as security certificates (ASSERTS).

8.1. ASSERT ENABLED SERVICE MARKETPLACE

Figure 8.2: Sorted (and color-coded) results obtained from applying a pol-icy

Consumers can easily inspect them by clicking on the seal icon (Figure 8.2). For each certified service, not only the information about the high-level certified security property is available (e.g., “confidentiality of stored data”), but also the mechanism used to achieve that property (e.g., en-cryption) and its parameters (e.g., cryptography algorithm used: AES with key-length 256 bits). All this information is in fact contained in theASSERT of the certified service and hence, consumers can trust this information since this is attested by the Certification Authorities. Finally, information about the entity that evaluated the service at hand is available (the certifi-cate issuer) together with the dates of issuing and validity (not shown in the figure, but visible in the details screen for each service).

Refining the search using stored policies

The possibility to review and compare the security properties of the dif-ferent candidate services is already a significant step forward from existing marketplace instantiations. However, leveraging the fact that ASSERTSare machine-readable, the marketplace can also offer automatic filtering of the candidate services based on the user’s security requirements. Of course, a prerequisite for such a feature to work is that the consumer specifies their security requirements. For this purpose, our prototype offers a user-friendly interface (a wizard), partly shown in Figure 8.3.

137

Figure 8.3: Specifying Security Policies (Requirements)

The figure depicts the step of the wizard where the user can express the security properties that candidate services must satisfy, and can indicate what mechanism should be used to achieve those properties. At the end of the wizard, a new policy is created and the corresponding button is added to the left-hand side menu (Figure 8.2). Different policies can be applied at the same time: each may contain constraints of different nature, or coming from different sources. For example, centrally-defined corporate policies could be loaded automatically when the user logs onto the marketplace; in addition to those policies, the user can use the wizard to define and apply additional customized policies covering requirements related to a particular domain, business area, or location. Under the hood, the active policies are translated by the system into a Query for the ASSERT4SOA matchmaker service.

After applying one or more policies, the candidate service list is filtered to show only those that match (at least a part of) the constraints expressed in the active policies. The results are ranked and colour-coded to indicate how close a candidate service is to the specified security criteria represented in the applied policies.

Finding the best match among candidate services

From the results list, it is also possible to compare two or more services side by side, to have a clear visual comparison of their security properties and to understand how they compare with the constraints of the active policies (Figure 8.4). In addition to the colour coding (as in the preceding