2.4 Client-Centric Identity Management in Cloud ComputingComputing
2.4.1 Client-Centric Approaches to Identity Management
Several client-centric approaches are presented in this section. Mather et al. [72] present an enterprise perspective on cloud computing, focusing on security and privacy. An-gin et al. [6] offer an entity-centric approach, focusing on IAM and privacy. Chen et al. [29] propose a decentralized approach for IAM in cloud computing. Finally, Cameron et al. [26] propose a common identity framework, based on a user-centric identity metasystem.
Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance Mather et al. [72] offer an enterprise perspective on cloud computing with focus on security and privacy. With respect to IAM, Mather et al. argue that the most important challenge is managing access for a diverse user community. There are many types of users accessing different types of services. The challenge is increased by user turnover, since users can access resources at different times and peak times exist. Another chal-lenge is the fact that organizations can contain different directories leading to the prob-lem that the access policies are not centralized making the enforcement of the policies a difficult tasks.
Mather et al. [72] offer a detailed view of FIdM standards and recommends the us-age IDaaS such as Ping Identity [57]. Mather et al. argue that the usus-age of IDaaS allows enterprises to outsource the IAM system and processes thus reducing the complexity of interacting with various cloud providers. Since all IAM systems and processes are handled by the IDaaS provider, the client is not forced to update their system whenever a cloud service provider switches to different protocols. It is the IDaaS provider that chooses which FIdM protocols to use when interacting with the provider. Mather et al.
also mention that the usage of IDaaS does come with certain disadvantages: less visibil-ity into the service (including the implementation and architecture details), dependence on the availability of the IDaaS provider and increased complexity in identity attribute management. Other issues regarding security, privacy and trust arise when using IDaaS.
An Entity-Centric Approach for Privacy and Identity Management in Cloud Com-puting
Angin et al. [6] propose an entity-centric approach for privacy and identity management in cloud computing. The approach allows for an IAM system for cloud computing that
does not use trusted third parties and that can be used with either trusted or unknown hosts. The approach is based on active bundles and anonymous identification. Angin et al. define an active bundle as a container with its payload consisting of: sensitive data (content that needs to be protected from privacy violations), metadata (data that describes the active bundle as well as its privacy policies) and a VM (which contains the code required to enforce privacy and access control policies and to validate the bundle integrity).
Active bundles are created by an Active Bundle Coordinator which offers a ’yel-low pages’ service associating entities with service descriptions. In addition to the active bundle coordinator, three other agents are used: SSA, TEA, and ASA. The SSA agent maintains a database of information about active bundles, information which is then used to encrypt and decrypt the sensitive data and metadata of an active bundle.
The TEA agent is used to obtain information about the trust level of a service while the ASA agent is used to monitor activities for audit purposes. The behaviour of an active bundle is described as “a sequence of initialization, building, and enabling steps that followed” [6]. The initialization of the active bundle is done by the active bundle coordinator. Once the active bundle is initialized the active bundle communicates with the SSA agent in order to build a secure encryption of the sensitive data stored in the active bundle. Finally, the enabling of the active bundle entails the process of obtaining information about the trust level of a service (via the TEA agent), of enforcing the pri-vacy and access control policies (via the active bundle’s VM) and of recording each of the enforcements (by communicating with the ASA agent).
For usage in cloud computing, Angin et al. propose an IDM Wallet, based on the active bundle scheme. Zero-knowledge proof is used for authentication, with the added advantage that the authentication is done without disclosing the identifier of an iden-tity. Angin et al. name this processanonymous identification. To achieve anonymous identification the Fiat and Shamir [43] identification and signature scheme is used. The scheme consists of two protocols: one for issuing an identity to an entity and one for verifying the identity of an entity. The main advantages of the IDM Wallet approach, as stated by Angin et al. [6], are:
• The IDM Wallet is independent and trustworthy, because “the interaction is only between the SP and the user” [6].
• The IDM Wallet gives minimum information to the service provider.
• The portability of the IDM Wallet, since it can be carried on either mobile devices or flash drives.
The main disadvantage of the IDM Wallet comes from the fact that the authentica-tion scheme requires the cloud service provider to support the Fiat and Shamir protocol for verifying the identity. As such, the IDM Wallet can only be used when the cloud service provider offers an implementation of the protocol, making the IDM wallet un-usable with the most common PaaS and SaaS providers.
Privacy-Enhanced User-Centric Identity Management
Ahn et al. [1] discuss a privacy-enhanced user-centric IAM metasystem based on the Seven Laws of Identity [25]. A use case scenario is presented where a user named John utilizes MegaBank.com (an identity provider for online credit card services) to purchase books from Armageddon.com. In the process of buying the books John
pro-vides identity-related information using his self-issued information card (for shipping purposes) and his information card managed by MegaBank.com (for credit card infor-mation). Ahn et al. conclude that the “current identity selector agents lack appropri-ate privacy mechanisms that check conflicts in privacy preferences for the requested claims” [1] and that there is a need for a more systematic privacy solution to allow for the precise specification of privacy preferences from both relying parties and individual users.
To create a privacy-enhanced solution privacy labels (similar to security labels in MAC) are used. The labels are used to describe privacy policies using the W3C P3P framework [131]. The relying party defines the claims using OBJECT and XHTML statements in the web page, linking the privacy policies to the claims using the P3PLite language. When applying the privacy labels to the user’s privacy claims (which are given by the information card) three cases are considered. The first case entails applying the privacy labels to each claim. The second calls for applying privacy labels to each information card (instead of each claim). Finally, the third case considers the usage of categories of information cards (e.g. financial category containing the information cards that have financial-related claims) and applies the privacy label to each claim in the category’s claim list.
Ahn et al. [1] offer a Java-based proof-of-concept implementation of the iden-tity metasystem. Figure 2.9 shows the main components of the Ideniden-tity Selector. The system is compatible with CardSpace [75] and has 7 components: Information Card Manager, Graphical User Interface, Card Store, iButton/Smartcard Agent, Local STS/-Token Issuer, libraries and Privacy Labels Agent [1]. The Information Card Manager is used to handle any events triggered by the user and systems. The information is presented to the user via a screens (e.g. self-issues card screen) and stored in XML for-mat in the Card Store. The iButton/Smartcard Agent handles communication with any Smartcard compatible devices while the STS/Token Issuer generates CardSpace [75]
compatible security tokens. Finally, the Privacy Labels Agent is used to manage the privacy settings for the user and to evaluate the user’s privacy preferences against the privacy policy specified by the relying party.
Figure 2.9: Components of Java-based Identity Selector [1]
The main advantage of the user-centric identity metasystem proposed by Ahn
et al. is that it helps “users control private attributes before sharing them with relying parties by examining relying party’s privacy policy and the user’s privacy preferences for the requested claims” [1]. However, as Schechter et al. [108] mention, typical users tent to ignore obvious security and privacy indicators. In addition the usage of such a system entails extra overhead for users as they must be very careful in defining and checking the claims for each service.
A Decentralized Approach for Implementing Identity Management in Cloud Com-puting
Chen et al. [29] argue that “current approaches to IdM are often implemented as user-centric, service-centric and network-centric solutions” [29] and, according to their anal-ysis, “it’s not a good solution for implementing IdM in a centralized way with the scale of cloud and the number of users surging” [29]. As such, Chen et al. propose a decen-tralized approach.
Services that frequently communicate with each other (e.g. services under an SSO) are bundled together into groups, each group dubbed a TC (Trust Context). The aim is to build a Weighted Undirected Acyclic Graph (WUAG) where the vertices of the graph represent cloud services. If services or TCs communicate with each other a weighted edge will connect the two components, with the wait being computed from statistical data regarding communication. Chen et al. [29] present the algorithm used to create the graph. The goal of the algorithm is to group services based of the frequency of the communication between them. Based on the graph, the client (or cloud provider) can choose to distribute their IAM system. Figure 2.10 shows an example of such a distribution.
Figure 2.10: Decentralized IdM In Cloud Computing [29]
Proposal for a Common Identity Framework: A User-Centric Identity Metasys-tem
In the paper “Proposal for a Common Identity Framework: A User-Centric Identity Metasystem” [26], Cameron et al. propose a user-centric IAM framework. While the framework itself is not specifically aimed at cloud computing, the service-oriented ar-chitecture can be easily adopted for cloud-based services. The model introduces the concept of abstract services that can be instantiated through given protocols. The goal of the proposed metasystem is to facilitate the interworking of various IAM components
from different manufactures and under different managements (or levels of complexity).
The model takes into account that the different IAM components can be based on dif-ferent protocols of difdif-ferent ages, which employ difdif-ferent syntaxes and convey difdif-ferent semantics [26]. Cameron et al. propose several requirements for both the system and the actors using the system:
Requirements of sites and services using the system. Service providers must be willing to adopt the proposed model. To facilitate this, the design of the model includes components that reduce the risk and liability of service provid-ers. Providers need to ensure access to authorized users and prevent unauthorized of fraudulent access. In addition, they also need comply with relevant statuses, standards and audit. The requirements of service providers should “be an auto-matic outcome of the Identity Metasystem as instances are deployed” [26].
Requirements of people using the system. Cameron et al. describe three key requirements for users of the identity metasystem:
Strict control of information flows by users. As a core requirement of the user-centric metasystem, users should have control over the flow of identity-related information. This entails the presentation of human inter-faces to users allowing for transparency and disclosure when presented with choices over the flow of information.
Data minimization. The processes of collection, aggregation, storage, re-tention, replication, distribution and linkage of data should work with the minimum amount of identity-related data.
Contextual separation. To facilitate data minimization, identity-related data should only be offered on a contextual basis. This requirement means that relaying parties cannot build ’super-dossiers’ of users, and instead only receive the information they need in order to provide the functionality of their services.
Information protection framework. A key requirement of the metasystem is to ensure the protection of sensitive identity-related information. This entails the usage of adequate mechanisms of “of encryption, access control, separation of duties, auditing and physical control” [26]. In order to minimize the impact of any potential breaches, four partitioning approaches are used:
1. Reducing the number of collocated records.
2. Reducing contents of each record.
3. Controlling access to these records based both on application and role.
4. Separation of identifiers that link directly to natural persons from other information.
Freedom of choice. Cameron et al. identify freedom of choice as crucial for both users and relying parties. In order to prevent provider lock-in users need to have the ability to choose between various service providers. This entails interoper-ability as a prerequisite for choice. Service providers should also invest in inter-operable services as this can attract more clients.
Requirements of governments. Different challenges arise when governments act as replying parties or identity providers. Governments usually have much stricter requirements when it comes to identities of natural persons. In addition
“data protection and minimization precautions necessary in any identity system apply even more strongly to government systems, given the sensitive nature of the
information and the difficulty of adequately compensating its compromise” [26].
Given the above mentioned requirements, the identity metasystem proposed by Cameron et al. defines:
1. "A mechanism, called claims, for describing subjects, that works across all constituent identity systems.
2. A taxonomy of claims.
3. A taxonomy of parties present in the system, including subjects.
4. The components through which the users interact with the system.
5. The abstract services offered by the components.
6. The privacy and security threats arising from the information flows.
7. The system requirements arising from these threats.
8. The establishment and use of technical policies" [26].
Aclaim is defined as an assertion made by a subject about another subject that can be ’in doubt’ only until passing a claims approval. Once the claim has passed this stage the relying parties can consider the assertion as valid. Cameron et al. consider five different types of claim:
Static. Attributes of the subject that are static within some window of time (e.g.
date of birth, name).
Relationship. Details about the relationship of the subject with other subjects (e.g. members of an assigned role).
Derived. Claims that offer the minimum information necessary (e.g. over 18 years old, married male in his 30’s).
Capability. Claims used for authentication and authorization (e.g. can-read-email).
Contextual claims. Useful in evaluation the security presentation (e.g.: location, time).
The model identifies six participating actors: the subject, the claims provider, the relying party, the Subject Acting As (SAA), the technical policy provider and the administrative domain. The subject is the consumer of a digital service (i.e. the user).
An individual or organization can issue claims using a claims provider. A relying party is an organization or service provider that depends on the claims issued by the claims provider to control access and personalize a service for a given subject. A subject that acts on behalf of another subject is referred to as an SAA. A technical policy provider is an organization responsible for the creation of the policies employed by the relying party. Finally, an administrative domain is an entity is responsible for maintaining a set of metasystem components and the development of the legal and technical policies used by the components.
The metasystem proposed by Cameron et al. [26] is composed of several agents.
Figure 2.11 shows the interaction between the agents. First the user makes a request to a service provider (1). The provider responds with a technical policy requirement informing the user that it requires identity-related information (2). The user will present the information with the assistance of the Claims Selector agent. If the user instructs the Claims Selector agent to release the required information the agent contacts the claims provider (3) in order to obtain the required claims (4). Optionally, the Claims Selector
may use a claims cache to store and quickly obtain claims in case there are no lifetime constraints (3a and 4a). Finally, the Claims Selector forwards the claims to the service provider (5).
Figure 2.11: Information flow in Identity Metasystem [26]