logo  
           
 
Prototype

The following figure illustrates the developed prototype as an UML deployment diagram:

As one can see, the prototype consists of three domains. Both, domain 1 and domain 2 have a SeAAS engine deployed, which are Java applications and the heart of our approach. Additionally domain 1 and 2 use an enterprise service bus to route between the domains and also within a domain. Further there are also several services deployed at each domain. Security services like Security Token Service (STS), XACMLight and Non-Repudiation-Protocol services (NRP) are deployed at domain 1 and 2. At domain 3 a trusted third party service (TTP) is deployed for a fair NRP. Furthermore all domains require a set of services, the so called Basic Security Services (BSS) which are responsible for primitive security operations like encryption or digital signatures. One of those services, the WS-Security-Policy service implements the WS-Security-Policy standard. Additionally each domain also provides some business services in order to realize our use case. In particular domain 3 has a credit card service (CCS), domain 2 an advanced business service (ABS) and domain 1 the basic business services (BBS). For more details about the business services please use the following activity diagrams and descriptions. The test client of the prototype is connected to domain 2.


The activity diagrams with the security requirements of the prototype:

Activity diagram of GetItems

The operation GetItems is located in the inventory service of the basic business services at domain 1. It returns all currently available items. At the beginning of the activity the client generates a request for the GetItems operation. This request is then forwarded to domain 2, but before the request is actually sent to domain 1 the SeAAS engine of domain 2 first takes care that the security requirements are met according to the specifications in the activity diagram. At domain 1 the SeAAS engine is responsible for the security requirements before the request is dispatched at the actual business service. After domain 1 has processed the request, the SeAAS engine of domain 1 again takes care that all security requirements are enforced and sends the response then back to domain 2. In domain 2 the SeAAS engine, again first enforces the security requirements and at the end forwards the response back to the client.
Additionally to the GetItems operation the client in the prototype also invokes a GetStock operation which requires exactly the same security requirements. Therefore we do not include an extra activity diagram for this operation.


Activity diagram of OrderItem

Here one can see how an order is placed. First the order request is created, secured and sent by the client to the ABS of domain 2. This message has to fulfill the specified security requirements. The ABS then calls the credit card service at domain 3. And again the SeAAS engine is enforces the specified security requirements. In domain 3 the CCS itself implements the security requirements. If the credit card number is successfully validated domain 2 invokes the basic order service of domain 1. Similar to the previously described GetItems activity the SeAAS engines of the two domains are responsible to enforce the security requirements. Finally the response is forwarded to the actual client, which then has to check if the specified security requirements are fulfilled.


Activity diagram of CancelOrder

In the end the test client tries to cancel the previously placed order by invoking the CancelOrder operation of the basic order service.


 

 
 
In association with:
qe_logo