## 5 Trust Adaptation
### Experimental Results
#### 5.2.2 Migration Workflow  
_(1) Web service development_: We demonstrate an example workflow for securing a Java Web service with RBAC. In the development phase, developers have no knowledge of an AAI implementation that an IDaaS offers. However, they may define a set of roles for their application as well as which roles are allowed to access which resources. Figure 8 shows the deployment descriptor of the delivery service, whereby developers allow the role \"admin\" to access a web resource. _(2) Topology description:_ In this step, a security architect describes the security topology. Figure 9a shows a Graphical User Interface (GUI) that helps the architect  
Figure 8: Developers may use a deployment descriptor for RBAC. Figure 7: Test environment. The GUI is the presentation of our topology model. On the left side, the architect defines a \"WebService\" node running on a \"Glassfish\" application server of a \"Compute\" VM. He also wires an \"InterceptingWebAgent\" node to the application endpoint capability of the \"WebService\" node to define a \"protect\" relationship between them. On the right side, he can specify the trust capabilities of the \"InterceptingWebAgent\". In the first scenario, the delivery service is from the same organisation, so he chooses the \"direct_trust\" capability and specifies the public key of the shopping service. In this trust model, the shopping service is the \"actor\", and the architect can specify a role (e.g., admin) for the shopping service in the \"actor\" property. In the second scenario, the service consumer is still unknown, so the architect chooses the \"indirect_trust\" capability. In this trust model, the user is the \"actor\", and the delivery service has to authorise the user based on his identity. Here, the architect can specify the endpoint of IDaaS1 as the \"trustee\" to issue user identity. He may allow the service consumer to act on behalf of the user, so he selects the value \"trust.impersonation\" in the \"type\" property (optionally, he may choose \"trust.delegation\"). When he saves his work, the editor generates an equivalent topology description as in Figure 9. We can see that the nodes have been instantiated with the trusted endpoint of IDaaS1 (line 16). The architect also specifies that his application needs an email address and a user group from IDaaS1 (lines 18-20) to propagate to the backend. In the topology for the shopping service (Figure 10a), the architect uses a \"Proxy\" node to intercept outbound requests from the shopping service and connects the \"Proxy\" to a \"PE\" node. Figure 10b shows the generated topology description for the shopping service. Recall that our PEP node is an abstract node that represents a partner service. The architect may use a TOSCA \"node_filter\" to define his trust criteria for selecting a partner service (line 9). If the partner service is known beforehand (e.g., the delivery service), he chooses the \"direct_trust\" capability and specifies the  
Figure 10: Topology editor (**a**) and topology description (**b**) for the shopping service. Figure 9: The topology editor (**a**) and topology description (**b**) for the delivery service. public key of the delivery service. Otherwise, he chooses the \"indirect_trust\" capability and specifies IDaaS1 as one of the trusted endpoints of the Proxy (line 14). _(3) Provisioning:_ In this step, an administrator provisions the delivery service to OpenStack. The orchestrator uses the OpenStack APIs (and the credential of the administrator) to boot a VM, deploys the Web service, and calls the interface \"pre_configure_source\" of the \"InterceptingWebAgent\" to protect it. For direct trust, the public key of the shopping service is imported to the truststore of the application server. For indirect trust, the Web agent is configured to trust IDaaS1 and intercept client requests on the message layer (see the Web agent implementation).