Key Idea of the Client-Centric Identity and Access Manage- Manage-ment Approach

Having multiple identities across different providers increases the threat of ac-count or service hijacking, which can cause financial losses for clients. Recent years have seen an exponential growth in social engineering attacks. According to the

APWG [9] report a total of 42890 of phishing websites were detected in December 2013 alone with 362 brands targeted by phishing campaigns. The report shows a clear in-crease in the number of phishing attacks worldwide. Clients must ensure the protection of the credentials used when authenticating to cloud-based services. Complex password policies, periodic password resets and security measures against phishing websites offer some protection against the threat of account or service hijacking.

The introduction of complex password policies can protect clients from account hijacking attempts. However, as mentioned by Schechter et al. [108], a typical user would tend to ignore obvious security and privacy indicators. Complex passwords are often hard to remember and when using multiple services clients often tend to ignore the dangers and choose easy to remember, less complex passwords and often use the same password for multiple accounts [108]. Furthermore, choosing the same credentials on different providers also increases a client’s linkability across different domains.

To sum up, the main IAM-related problems facing clients that adopt cloud-based services are as follows³:

Problem 1. Theloss of controlover the client’s data, which implies an additional mis-trust of cloud providers.

Problem 2. The serviceprovider’s tendency to control the customer experience, which leads providers to ask for more data than they actually require.

Problem 3. The competitive cloud market and the threat of provider lock-in, which leads clients to use multiple cloud providers.

Problem 4. With the usage of multiple providers comes the increased task of maintain-ing identity information and access rights across the various cloud services.

Problem 5. For clients represented by companies the maintenance issue is increased by the need foruser provisioningandde-provisioning.

Problem 6. Account or service hijackings throughsocial engineering attacks, such as phishing, make clients vulnerable to financial loss, requiring better security policies.

Problem 7. Having multiple accounts increases the risk ofdata leakage or account hi-jackings, since users tend to choose weaker passwords and to reuse pass-words.

3.1.2 Key Idea of the Client-Centric Identity and Access

stores identity-related data in an identity directory. As this directory contains sensitive information access to it should be kept private. Only authorized users (such as system administrators) and the identity meta-system have access to it. This ensures that exter-nal attackers cannot gain access to the information via the use of known vulnerabilities of the directory’s software.

As shown in Figure 3.1, the client can choose to deploy the meta-system either on-premise, as a cloud-based service within a public, private or hybrid cloud or as hy-brid solution. In the on-premise deployment scenario, the meta-system is deployed on a machine within the client’s demilitarized zone (DMZ). As described by Robertson et al. DMZ “refers to a part of the network that is neither part of the internal network nor directly part of the Internet. Typically, this is the area between your Internet access router and your bastion host, though it can be between any two policy-enforcing com-ponents of your architecture” [103]. This allows users to connect to the meta-system from either within the client’s network or from an external source. The identity direc-tory is also kept on-premise, on a different machine within the client’s network. This scenario has the advantage that everything is kept on-premise and under the control of the client. The disadvantage of this scenario is that it requires two separate machines, thus increasing costs for usage, maintenance and administration.

Figure 3.1: Client-Centric IAM Meta-System Deployment Scenarios

In the case of cloud-based deployment the usage of private clouds is recom-mended, as the client has more control over the entire cloud environment. The de-ployment of the meta-system on public clouds increases the exposure of the client to

threats such as malicious insiders, shared technology issues and data loss or leakage⁴. The client can deploy the meta-system as a cloud service on an IaaS VM. The VM can contain an instance of the identity directory or the identity directory can be deployed on a separate VM. However, in the latter case the client must ensure that only VM housing the meta-system has access to it. The main advantage of this deployment is that it uses the processing power of the cloud once deployed. This means reduced costs, as the client no longer has to buy physical machines and some of the maintenance and admin-istration is done automatically by the cloud provider. The downside is that the sensitive identity-related information is more exposed, with the client having to trust the cloud provider’s security mechanisms. Such a deployment can basically be viewed as a pri-vate Identity Management as a Service (IDaaS), with the advantage that the client has more control over the data.

The client can also choose to deploy the IAM meta-system as a hybrid deploy-ment, where the identity directory is kept on-premise and the meta-system is deployed on a cloud VM. The connection between the identity directory and the meta-system is made secure by the deployment of one of the meta-system’s components in the client’s DMZ⁵. Alternatively, the client can choose to deploy the entire meta-system in the cloud. In such a case the client must establish an entrusted connection between the identity directory and the VM where the meta-system is deployed (e.g. VPN connec-tion). The hybrid deployment scenario combines the advantages of both the previous two scenarios. The more recourse-consuming IAM meta-system can be deployed in the cloud, while the sensitive identity-related information can be stored on-premise in a private identity directory. The key is to make the connection between the two compo-nents as secure as possible. The first hybrid scenario presented has the advantage that it does not fully expose the identity directory, but rather only bits of identity-related information. The disadvantage lies in the requirement of a second physical machine.

The second deployment scenario combines the reduced costs and processing power as-sociated with cloud computing with the enhanced privacy of maintaining an on-premise identity directory.

The proposed client-centric IAM approach is designed to mitigate the threats pre-sented in Section 3.1.1. Figure 3.2 describes the functionalities of the meta-system.

The loss of control over the client’s data (Problem 1) is an issue that affects all aspects of client-to-cloud interaction. Any client should be able to select what identity-related data is sent to cloud-services. A client-centric identity meta-system allows the client to accomplish this. The system ensures the authenticity of the connection between a client and a provider and allows the client to choose which identity attributes are sent to service providers, further increasing the level of trust when using the service.

Service providers tend to control the customer experience (Problem 2), often ask-ing a client for more information than they require. If service providers ask for infor-mation that the client considers to be redundant, he or she can choose not to send that information. The client can refuse to send the information or can send obfuscated infor-mation. The previous section contains an example of age restriction for a service. If a service-provider requires a client to be over a specified age then they will ask the client

4 While these threats apply to any cloud environment, in private clouds the client has more control over the resources, infrastructure and other organizational aspects of the cloud environment, therefore decreasing the level of exposure to the threats.

5 The component in question is the IdMMClientagent and is described in Section 3.2

Figure 3.2: Functionalities of the Client-Centric Identity Management Meta-System to prove his or her age, often by asking for a date of birth. In most instances only the year of birth would be sufficient to gain access to the service so the client can obfuscate the real date of birth by adding or subtracting values to the day and month of birth⁶. A client-centric system allows for this changes to be done automatically. The client only selects the attributes and the services where he or she wants data to be obfuscated and the system does it automatically.

The competitive cloud market can make clients choose multiple cloud provid-ers (Problem 3). A client-centric approach to IAM allows clients to more efficiently use cloud-based services from multiple providers by offering SSO. Clients authenticate once to the client-centric meta-system and are then automatically authenticated to the cloud services. Using multiple providers also means having to maintain the identity-related data across these providers (Problem 4). If any identity attributes change, the client must update the information on each service he or she uses. This is a time con-suming task which can be achieved by the use of a client-centric IAM meta-system. If any information stored in the client’s directory changes then the system automatically makes the required changes on each service used by the client, as shown in Figure 3.2.

If the client is represented by a company having multiple employees (users) then the issues of user provisioning and de-provisioning and the tasks of maintaining access rights across multiple providers become important (Problem 5). As shown in Figure 3.2, the proposed client-centric meta-system allows for automatic user provisioning. When new employees are hired, the system creates the identities in the client’s directory and, when needed, creates accounts on the service provider side. When employees leave the company the system performs automatic user de-provisioning, deleting the service-side accounts and removing or disabling⁷ the identities of the former employees. As the meta-system offers a SSO service, the disabling of identities can be done temporarily (by changing the credentials of the employee for the SSO) or permanently (by also

6 The client might also consider generating random values for the day and month of birth.

7 For auditing and management purposes companies may choose not to delete the identities but rather ensure that the former employee no longer has access to the services he or she used while being employed.

removing all the access rights of the identity).

The adoption of multiple providers also entails challenges in managing creden-tials, increasing the risk of account or service hijackings via social engineering attacks (Problem 6). To mitigate this threat, the system performs automatic authentication to cloud-based services acting as an SSO service. A user will only be aware of his or her credentials to the SSO itself and not to the credentials used for authentication to the cloud service. Once authenticated to the SSO the user will be automatically authen-ticated to the cloud service, upon request (Figure 3.2). Such an approach yields two main advantages. The first is that by using automatic authentication, different complex credentials can be chosen for each service. Since users are automatically authenticated to the cloud service they do not need to remember the credentials, preventing them from choosing weaker passwords or to reuse passwords (Problem 7). The second advantage is that security can be further enhanced, by changing the cloud service credentials at either random or scheduled intervals. Since users do not know the credentials, they cannot fall prey to social engineering attacks.

The usage of an SSO system offers many advantages but comes with one main disadvantage. Povey mentions that “the most obvious risk of moving to a single sign-on system is that it also creates a single point of failure. The compromise of a single authentication credential will allow an attacker access to all systems for which the user who is authenticated by that credential is authorized” [92]. For the IAM meta-system the main risk of single point of failure is represented by social engineering attacks to the SSO itself. If attackers gain the credentials to the system then they can use each service a user is subscribed to. However, this issue can be mitigated by using complex security and credential policies (e.g. using strong passwords augmented by biometrics) when authenticating to the SSO. Huang et al. [56] describe other means of preventing single point of failure.

The adoption of a client-centric approach to cloud computing allows clients to have better control over their identity-related data. A client-centric identity manage-ment meta-system allows clients to select which attributes to send to service providers, as well as to obfuscate certain attributes. When using multiple providers, the system helps the client update attributes, manage access rights and takes care of user provi-sioning and de-proviprovi-sioning. The system also helps the users, by performing automatic authentication to cloud services using complex credentials. The users are not aware of these credentials, increasing the security of clients using cloud services and decreasing the risks of account hijackings.