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:
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.
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.