###### Abstract  
In recent years, enterprise applications have begun to migrate from a local hosting to a cloud provider and may have established a business-to-business relationship with each other manually. Adaptation of existing applications requires substantial implementation changes in individual architectural components. On the other hand, users may store their Personal Identifiable Information (PII) in the cloud environment so that cloud services may access and use it on demand. Even if cloud services specify their privacy policies, we cannot guarantee that they follow their policies and will not (accidentally) transfer PII to another party. In this paper, we present Identity-as-a-Service (IDaaS) as a trusted Identity and Access Management with two requirements: Firstly, IDaaS adapts trust between cloud services on demand. We move the trust relationship and identity propagation out of the application implementation and model them as a security topology. When the business comes up with a new e-commerce scenario, IDaaS uses the security topology to adapt a platform-specific security infrastructure for the given business scenario at runtime. Secondly, we protect the confidentiality of PII in federated security domains. We propose our Purpose-based Encryption to protect the disclosure of PII from intermediary entities in a business transaction and from untrusted hosts. Our solution is compliant with the General Data Protection Regulation and involves the least user interaction to prevent identity theft via the human link. The implementation can be easily adapted to existing Identity Management systems, and the performance is fast. identity-as-a-service; federated identity management; privacy-preserving; purpose-based encryption; purpose-based access control; attribute-based encryption; cloud adaptation; cloud migration +
Footnote †: journal:  
0000-0001-5000-0000-0000-00000-00000-0000-00000-00000-00000-00000-00000-00000-00000-00000-000000-00000-000000-00000-000000-00000-000000-000000-000000-  
In federated IDM, SPs from different security domains exchange messages containing authentication and authorisation credentials about users [3]. As a result, federated IDM reduces the cost for SPs because they no longer manage users that are not under their control [4]. SPs form a federation by developing offline operating agreements [4]. For instance, they may specify which PII they want to exchange, which protocol to use (e.g., Security Assertion Markup Language (SAML) [5], or Web Services Federation [6]), and whether the client may act on behalf of a user to access the service. In the end, SPs expect each other to behave accordingly and thus they establish a trust relationship [7]. Afterwards, developers adapt the implementation of Authentication and Authorisation Infrastructure (AAI), depending on these agreements [4]. In cloud computing, SPs come from various security domains; provide themselves as cloud services and may cooperate with each other. From the beginning, they may establish their trust manually. However, as time goes by, cloud services may migrate to another Software-as-a-Service (SaaS) cloud provider and may adapt their trust upon each change [8]. Figure 1 shows various motivation scenarios. In the first scenario (Figure 1a), a shopping service consumes a delivery service in a business-to-business (B2B) scenario. Each time the delivery service migrates from a local host to another cloud provider, developers have to adapt their security infrastructures again manually. As an Independent Service Vendor running on many platforms, cloud services may refuse to change their application implementations to adapt to a given one [8]. On the other hand, users may store their PII in the cloud environment so that cloud services may access and use it on demand. From the user's perspective, users may prefer to access multiple cloud services in federated security domains, but also preserve their privacy [8].