## 3 Related Work and Discussions
### Authentication and Authorisation Infrastructure  
Existing solutions for IDaaS (e.g., One Login [36], Ping Identity [37]) provide a central IdP for managing users. Their users have Single Sign-On access to cloud services, which were manually adapted to the IdP before. However, automated trust negotiation between cloud services and privacy-preserving user identity are not supported. On the other hand, several solutions from the  
Figure 2: Identity-as-a-Service proposed model.  
industry provide frameworks for developers to implement AAI but lock an AAI implementation to a vendor-specific application server or an IdP [33]. Therefore, developers have to relearn and implement repetitive tasks using APIs from different vendors. These proprietary APIs also limit the portability and interoperability of cloud services [33]. Our approach provides a holistic approach to adapt AAI for cloud services in multiple cloud providers.  
Work in [38] uses Aspect-Oriented Programming to enforce authentication and authorisation on critical points of an application program (i.e., a component, a class, or a class method). However, administrators may have difficulties to define security policies by looking at the class methods. In addition, this approach adds additional performance overhead on the secured resources [38]. In comparison to our work, we only secure the public APIs of the application component. However, we change the security implementation outside the application component without affecting the running application. As a result, we increase the performance, because the Web server now performs the security-related tasks [39]. Also, we let the security architect define a flexible topology for his application (i.e., he can choose a central Policy Enforcement Point (PEP) to protect multiple application components or a dedicated PEP for a target component).  
In a standard approach, the specification WS-Policy [40] and WS-SecurityPolicy [41] define frameworks for Web services to express their security constraints and requirements. However, they do not specify whether the client may call the Web service with the client identity or impersonate the original user. In such cases, the resource owner of the call is unidentified. Without identifying the resource owner, the Web service cannot authorise and audit a request correctly. Also, the policy specifies the security constraints for a platform-specific implementation only. Our approach fixes these missing gaps by modelling the trust relationships between Web services in a platform-independent model. When the security infrastructure is adapted to a target hosting, the adaptation process generates a WS-SecurityPolicy description that conforms to a trust instance.  
In cloud migration, existing work has focused on migrating application components with functional and non-functional aspects [15; 16; 17; 18] (e.g., replace a database with a Database-as-a-Service). Our approach supports legacy applications by considering them as _unprotected_ components (i.e., components with no security constraints). Then, IDaaS secures them during the cloud migration. However, a security architect supports the adaptation process by describing the topology views of the AAI components.  
Finally, we also need to evaluate the deployment of AAI in a target hosting. In general, a trusted third party may assert certifications for the deployment by using a Trusted Platform Module [42], a monitoring-based [43], or a test-based certification [44]. In this paper, we follow the test-based certification by defining an integration test for each trust capability. At runtime, IDaaS performs the corresponding test to check, whether a deployment conforms to the trust capability.