## 5 Trust Adaptation
### Evaluation  
The implementation of the Web agent faces two obstacles of interoperability and portability. Interoperability is the ability of two or more components to exchange information and to use the exchanged information [66]. In our cases, the Web agent needs to exchange the user identity with the application in the backend, but the backend is a black box. Furthermore, developers implement the Web service without knowledge of the AAI implementation at runtime. In our approach, the security architect supports the interoperability between the Web agent and the application in the backend by providing the \"group_mapping\" and \"claims_mapping\" in the trust capability. By reading the \"group_mapping\", the Web agent understands which claim is mapped to the group principal (e.g., [[http://wso2.org/claims/groups](http://wso2.org/claims/groups)]([http://wso2.org/claims/groups](http://wso2.org/claims/groups))). By reading the \"claims_mapping\", the Web agent understands which HTTP headers to propagate to the backend (e.g., HTTP_EMAIL).  
It is worth mentioning that, if we implement the Web agent for scripting languages (e.g., PHP or Ruby), we will use HTTP headers, because identity propagation in HTTP headers is considered as programming and platform independent for any applications to obtain information about a request [36]. If we implement the Web agent for Microsoft.NET applications, we will use the Windows Identity Foundation (WIF) [67]. By using WIF, we will not face the obstacles above, because WIF has standardised its identity model for propagating a SAML assertion [68]. In this paper, we evaluate a Java application, because the Web agent implementation in Java has such obstacles for security adaptation to consider.  
Portability is the ability to move an application from one cloud provider to another one at the lowest possible cost, effort, and time [66]. The TOSCA specification achieves the portability of cloud applications by using _declarative processing_ and _imperative processing_[69]. Declarative processing requires a precise definition of the semantics of node types and relationship types so that any TOSCA compliant orchestration framework can interpret these types and deploy them in a target cloud provider (i.e., the orchestrator has already supported these types and implemented APIs of multiple cloud providers to deploy these types). Because our security nodes inherit from the normative node types of TOSCA (e.g., \"WebApplication\"), the orchestrator can interpret our nodes as a Web application for the deployment. By inheriting the normative relationship types (e.g., \"ConnectsTo\" and \"HostedOn\"), the orchestrator can control the dependency and the life cycle of our components. On the other hand, imperative processing requires explicit instructions on how to manage the components. In our work, we provide deployment artifacts (a Jar archive) and implementation artifacts (shell scripts) for the PEP and the Proxy. These artifacts are examples of imperative processing. Another IDM vendor may replace our artifacts by theirs if they have a specific solution.  
Figure 11: (**a**) Proxy implementation; (**b**) Intercepting Web agent implementation.