## 2 The Need for Identity-as-a-Service  
In e-commerce, SPs demand highly secure and flexible access control mechanisms for identity federation. However, this security feature is not a core competency [12]. Therefore, cloud services may prefer outsourcing AAI to a third party so that they can focus on developing their core business functionalities [12]. In such cases, their security infrastructures can be strengthened by a specialised provider to reduce their cost [12]. Migration of existing applications from a local hosting to a cloud provider requires substantial adaptation effort in individual architectural components [13]. A survey of cloud topology and orchestration from 2012 to 2017 identified 91 research efforts, but very few papers have addressed the security aspects [14]. Existing work has focused on migrating application components with functional and non-functional aspects [15; 16; 17; 18]. However, none of them has focused so far on the adaptation of the required security infrastructures. On the other hand, in the past 10 years, many efforts have been taken in protecting PII [19; 20; 21; 22; 23; 24; 25; 26; 27; 28; 29]. These approaches target certain issues but still have limitations. For instance, users require interacting with the SPs over the frontend, they neither protect identity propagation between intermediaries nor against an untrusted host. It is worth mentioning that human-PC link is the weakest link compared to the links between the PC, SP, and IdP [3]. Therefore, the human link is the major target of identity theft [3]. For this reason, we consider reducing human interaction from identity disclosure as much as possible. The open standards organisation, OASIS, mentioned Identity-as-a-Service (IDaaS) as \"an approach to Identity Management in which an entity (individual or organisation) relies on a cloud service provider that allows the entity to perform an electronic transaction, which requires identity data managed by this provider\" [30]. Since the definition is non-standard and coarse, in [8] we revisited the requirements of a traditional IDM system [31] and specify which requirements are still missing in cloud computing. Furthermore, an IDM system is much more likely to succeed when it benefits all parties, including users, SPs and IdP [32]. This was our goal when we proposed two new requirements for IDaaS bringing benefits to both SPs and users: IDaaS adapts an automated trust between cloud services on demand and protects the confidentiality of PII in federated security domains [8]. Figure 2 illustrates a brief overview of our novel architecture design. First, IDaaS adapts the AAI implementation so that cloud services from various security domains can trust each other on demand. Second, a user Bob encrypts his PII in his home IDaaS, which further disseminates the ciphertext on his behalf to a given security domain before he accesses cloud services in this domain. The main contributions of our work can be summarised as follows:  
1. _Trust adaptation:_ In [33], we proposed to separate the security infrastructure from the application business logic as a new virtualization layer. In particular, we move the trust and protection relationship as well as the identity propagation between application components out of the application implementation and model them as a security topology. The topology describes the AAI components, their relationships with the application components in a platform-independent modelling language. Using the topology, IDaaS can adapt the security infrastructure, establishes a dynamic trust relationship between cloud services on demand, and evaluates any changes in the runtime environment to conform to the model. 2. _Purpose-based Encryption:_ In [34], we proposed a broader solution to solve the privacy issues above: We protect PII over an _intended channel_ (i.e., a frontend service), as well as an _unintended channel_ (i.e., a backend service is completely transparent to the user), and against an untrusted host. We also notice that absolute protection does not exist.