When users submit their personal data to web sites and cloud providers today, they have to trust that the provider will act in accordance with its advertised policies and contract terms. Users typically have no visibility about what happens to their data after it has been given to the provider. Users have little evidence to tell them which providers to trust and have no control over the policy that is applied by the service provider to their data. If users do not agree to the provider’s terms and conditions, they are typically not allowed to use the service. In the case of Amazon S3, for example, the user is presented with a lengthy legal document that has the following clause buried within it [5]:
4.2 Other Security and Backup. You are responsible for properly configuring and using the Service Offerings and taking your own steps to maintain appropriate security, protection and backup of Your Content, which may include the use of encryption technology to protect Your Content from unauthorized access and routine archiving Your Content.
This places a considerable burden on the user (data encryption, backup etc.) and seems to absolve the cloud service provider from all responsibility to keep the data secure, and from any liability should the data be lost, compromised or corrupted. This type of clause represents a significant inhibitor to many users which prevents them from using cloud computing today.
Many researchers similarly assume that cloud service providers cannot be trusted and that all data must be encrypted before it is submitted to the cloud, see for example [6]. Mowbray and Pearson [7] recognize the problem of privacy protection when submitting sensitive information to (untrusted) clouds. Their solution uses a client based privacy manager which obfuscates sensitive data before submitting it to the cloud.
However, organisations have been regularly outsourcing (unencrypted) data and processing to third party providers for decades [8]. Many UK government’s IT services are already run by third party providers and this is expected to grow and migrate to cloud computing [9]. Consequently many organisations are routinely used to trusting third parties with their data and the processing of it. It therefore seems logical to assume that most cloud service providers will similarly assume the ‘trusted data handler’ label in due course. My Private Cloud aimed to facilitate this process by providing cloud service providers (cloud SPs) with the software tools, procedures and services to easily offer trusted cloud services to cloud users, by relying in part on external trusted WSPs.
Current cloud platforms (e.g. Amazon, Google, Eucalyptus etc.) do not support federated access, delegation of authority, or fine grained access control. They primarily use a simple Access Control List (ACL) to provide access to other cloud users. In general, these are coarse grained. Controlling who might invoke a virtual machine is often restricted to everyone or no-one. Amazon’s S3’s ACLs only allows users to specify the following access levels: anonymous access (everyone, including non-Amazon Web Services (AWS) users), all AWS users, or named individual AWS users. All existing ACL based systems are limited in only being able to grant controlled access to other registered users. Amazon has recently extended its Access Control system with Bucket Policies. These policies allow users to manage access to their S3 resources at the bucket level for both the buckets and the objects, providing a more fine grained access control for those resources, but still limited to other registered Amazon users. As pointed out in [10], this rather crude access control mechanism makes it difficult to use S3 as part of a (large) science project involving many collaborators. Also, the lack of a fine-grained delegation mechanism impedes the use of S3 in data-driven science projects where scientists often want to delegate access rights to a particular data set to an application/job running on their behalf.
Different approaches to the cloud access control problem have been published in the literature. V. Echevarrıa et al. [11] have developed a novel approach called Permission as a Service (PaaS) which provides a separate access control service from the other cloud services. In PaaS, user data is encrypted in the cloud, using attribute based encryption (ABE), to maintain confidentiality. Permissions are managed via decryption keys based on the attributes of the users being granted access. Our approach is similar to PaaS, in that access is granted based on the attributes of the user, but there the similarity ends. We assume the cloud service provider can be trusted to keep the information confidential, so encryption is not mandatory (though the cloud provider can encrypt the data, as an optional value added service, if it wishes to). The user is given confidence to do this through the ability to attach “sticky” policies to his data and receive audit summaries from the cloud SP. The permissions in our system are provided by ACLs decided by the user following the discretionary access control model. Moreover, our system permits delegation of access and allows the user to give permission to someone who is not an existing cloud user, as long as they can be authenticated by one of the trusted federation IdPs.
Recent work by Dongwan Shin [12] added fine grained role based access controls to IaaS, by introducing a trusted domain that is used to manage users, roles and access permissions. But all the users, roles and permissions are managed centrally within this domain, thus it does not provide federated access or allow roles and attributes to be assigned by external attribute authorities, as in for example the UK Access Management Federation [13]. We believe that these are essential features for scalability, and they are provided as part of the current project.
Federated identity management, for example, as typified in the Shibboleth implementation [14], comprises a trusted Identity Provider (IdP), Service Provider (SP) and user agent (usually a web browser). The user attempts to access the SP via his user agent, but the SP, not knowing who the user is, redirects the user to its trusted IdP for authentication. If the SP supports multiple IdPs, then it may first ask the user to choose which IdP he wants to use for authentication. When the user’s agent contacts the IdP, the user is asked to authenticate, and if successful, the IdP redirects the user back to the SP, providing the agent with digitally signed assertions to present to the SP. These assertions say that the user has been authenticated by the IdP, and that he has the attached identity attributes. These attributes may include a unique persistent identifier (PID) for the user, so that the SP can provide a personal service for the user on repeated visits. When we apply this model to cloud services, the cloud service provider (cloud SP) becomes the SP, and the IdP can be any existing IdP which the cloud SP trusts, from any existing federation to which the cloud SP belongs.
Delegation of Authority allows a user (the delegator) to delegate any of his privileges to another user or application of his choice (the delegate) [15]. When role based or attribute based access controls are used, then the delegator may delegate a role or attribute instead of a privilege, since privileges are assigned to roles and attributes. This form of delegation is superior to existing grid based delegation that relies on proxy certificates [16], since i) the delegate must authenticate as himself, and not as a child of the delegator as in proxy certificates (which is a form of masquerade) and ii) fine grained delegation is automatically supported by the delegator delegating a subset of his identity attributes. Delegation in federated systems is made more difficult because the cloud SP may not have had contact with the delegate before, therefore does not know how to recognise which user is the chosen delegate.