Design and Implementation of Access Control as a Service for ...AWS cloud platform. AWS is a leading...

Design and Implementation of Access Control as a Servicefor IaaS Cloud

Ruoyu WuArizona State UniversityEmail: [email protected]

Xinwen ZhangHuawei Research Center

Email: [email protected]

Gail-Joon AhnArizona State UniversityEmail: [email protected]

Hadi SharifiArizona State UniversityEmail: [email protected]

Haiyong XieUSTC & Huawei Research Center

Email: [email protected]

ABSTRACT

Organizations and enterprises have been outsourc-ing their computation, storage, and workflows toInfrastructure-as-a-Service (IaaS) based cloud plat-forms. The heterogeneity and high diversity of IaaScloud environment demand a comprehensive and fine-grained access control mechanism, in order to meetdynamic, extensible, and highly configurable secu-rity requirements of these cloud consumers. How-ever, existing security mechanisms provided by IaaScloud providers do not satisfy these requirements.To address such an emergent demand, we propose anew cloud service called access control as a service(ACaaS), a service-oriented architecture in cloud tosupport multiple access control models, with thespirit of pluggable access control modules in modernoperating systems. As a proof-of-concept referenceprototype, we design and implement ACaaSRBAC toprovide role-based access control (RBAC) for Ama-zon Web Services (AWS), where cloud customers caneasily integrate the service into enterprise applica-tions in order to extend RBAC policy enforcement inAWS. We describe challenges and lessons in imple-menting ACaaSRBAC , demonstrate how this servicecan be seamlessly integrated with enterprise cloudapplications, and discuss evaluation results.

I INTRODUCTION

Although cloud computing brings many benefits, se-curity issues have impacted its wide adoption forenterprises and organizations. In this paper, wefocus on addressing access control issues in publicInfrastructure-as-a-Service (IaaS) cloud. There areseveral challenges for controlling resource accesses insuch a cloud environment, compared with the prob-lem in legacy systems within an organization. First,a multi-tenant computing environment in clouds de-mands strong isolation between virtualized resourceusages among multi-tenants on the same physical re-sources, while in a legacy enterprise environment, the

single domain owns all computing resources. Sec-ondly, since cloud computing is a service-orientedcomputing model, the access control mechanism of acloud provider should be configurable in very flexibleway such that it satisfies many different customers’organizational security policies, such as role-basedaccess control for enterprises and multi-level secu-rity for government agencies. Current public cloudprovider lacks such an important flexibility. For ex-ample, Amazon Web Services (AWS), the leadingIaaS provider, only supports identity-based autho-rization for cloud customers with its Identity and Ac-cess Management Services (IAM) [2]. Thirdly, com-pletely delegating access control to a cloud provider–including policy management, storage, and securityenforcement–requires strong trust relationship andimplementation dependency between a cloud cus-tomer and the cloud provider. With the separation ofcomputing resource ownership and usage, we believeseparating security policies and their enforcement re-duces these dependencies.

In light of service-oriented computing model, we pro-pose a new cloud service for access control called ac-cess control as a service (ACaaS). The core idea ofACaaS is to outsource access control policy manage-ment and storage to service providers, which providesvalue-added functions for organizations with securityexpertise. A cloud customer (e.g., an enterprise orits security administrators) specifies and manages se-curity policies and configurations with interfaces pro-vided by ACaaS service providers. These high levelsecurity policies are then converted to low level andenforceable policies for individual cloud providers.The separation of this service-oriented security man-agement and customized enforcement in differentcloud providers not only reduces the trust manage-ment cost of cloud providers for enterprise customers,but also offers great flexibility for cloud customers todevelop their own security policies based on organi-zational requirements, without worrying about theirenforcement mechanisms in a concrete cloud environ-ment. Furthermore, ACaaS enables a cloud customer

Page 1 of 16c⃝ASE 2013

to choose different cloud providers for security reasonwithout a permanent lock-in.

We propose a modular architecture for ACaaS forpublic IaaS cloud, where variant security modules canbe plugged in for different cloud customers, e.g., tosupport role-based access control (RBAC) policies,multi-level security policies, Chinese Wall securitypolicy, and so on. Also, our architecture flexibly sup-ports many public cloud infrastructures with web ser-vices based APIs. As a case study and reference im-plementation, we design and implement ACaaSRBAC

for AWS, an ACaaS module that configures RBACpolicies and converts to AWS IAM policies such thatthe access requests to AWS resources from a cus-tomer’s user (e.g., the employees of an enterprise thatuses AWS) are controlled based on the enterprise’s se-curity policies. Specifically, in this paper:

• We propose a new modular architecture foraccess control called access control as a ser-vice (ACaaS) in cloud computing environments,which configures and manages multiple accesscontrol policy models for variant cloud cus-tomers’ security requirements, and converts toenforceable security policies in public cloudproviders. That is, ACaaS enables securely andefficiently outsourcing access control manage-ment of an organization in clouds (Section II);

• We identify the limitations of the existing ac-cess control mechanism of AWS IAM and de-sign ACaaSRBAC , a reference ACaaS architec-ture that supports RBAC policies to addressthose limitations. We articulate the designchallenges as well as formalize a correspondingACaaSRBAC model for AWS ( Section II, III,and IV);

• We implement a prototype system, and provideweb-based administrative tool and web servicesAPIs for third party applications’ integration.We demonstrate the practicality, efficiency, andscalability of our system through a case studyand performance evaluation (Section V).

II ACaaS FOR CLOUDS

In this section, we first present two motivating sce-narios. We then discuss the overview of ACaaS forcloud computing followed by its motivations for AWScustomers.

1 MOTIVATING SCENARIOS

IT sandbox in clouds IT sandbox is an isolatedcomputing environment which can be used for soft-ware development, security testing, pre-productiontestbeds, training and IT labs, among others. Inmany organizations, IT sandbox environments areprovisioned for dynamic workloads but not well com-patible with capital intensive in-house data center re-sources. Therefore, cloud computing environmentshave been considered for addressing such a limita-tion. Various types of sandboxes can be created tomeet different project needs in software developmentlife cycle, such as development sandbox, integra-tion sandbox, demo sandbox, testing sandbox, andproduction sandbox. Those sandboxes are dynami-cally created and terminated using scalable cloud re-sources. For instance, a development sandbox is cre-ated with pre-configured tools (e.g., IDEs, SSH, andSVN) and it consumes cloud services (e.g., EC2, S3,and RDS) for computing and storage. There are var-ious functional roles in each project such as projectmanager, developer, tester, and security administra-tor. Users with different roles have different accessprivileges on sandbox resources. In such a dynamicenvironment, it is critical to ensure that cloud re-sources associated with a certain sandbox can be ac-cessed only by authorized users with a low adminis-trative cost.

Government cloud platform According to a re-cent study by KPMG International [1], 28 % of overallIT expenditures in government agencies would be inclouds by the end of 2012. US NIST has designed itscloud computing program to support accelerated USgovernment adoption. Along with this broad shift,security concerns are the most significant barriers tothe adoption of cloud computing by government sec-tors. Many government agencies must comply withregulatory statutes, such as the Health InsurancePortability and Accountability Act (HIPAA) [10],the Sarbanes-Oxley Act of 2002 (SOX) [20], andthe Federal Information Security Management Act(FISMA) [9] in US. Security and regulatory compli-ance needs vary in terms of different levels of govern-ment sectors such as federal, state, and local govern-ments and different administrative dimensions suchas academia, civil, and military. Therefore, diversesecurity requirements should be accommodated inthe government cloud platform, while a single cloudprovider usually lacks the capability to support all ofthese requirements.


Figure 1: ACaaS vs. security modules in operating system.

2 OVERVIEW

Securely maintaining valuable digital assets in cloudsis critical for both cloud service providers and cus-tomers. The diversity of cloud services across a widerange of organizations and domains requires varioussecurity requirements. Accordingly, a comprehensiveand adaptive access control mechanism needs to bein place to support various security policy models forthe diverse security needs. However, current cloudcomputing platforms such as AWS, Windows Azure,Google App Engine, and Eucalyptus all fail to meetsuch identified needs. Towards this, we propose theconcept of access control as a service (ACaaS) withthe spirit of pluggable access control modules in mod-ern operating systems. As shown in Figure 1, wedraw an analogy between computing, storage, net-work, and other resources provided by IaaS providersand hardware resources in physical machines such asCPU, disk, and network stack. Cloud provider of-ferings can be mapped to operating system servicessuch as process management, memory management,scheduling, I/O operations, and networking. For in-stance, process management conducts basic tasks in-cluding starting and suspending processes, CPU allo-cation, and scheduling for multiple processes. Sim-ilarly, computing services in a cloud handle boot-ing and terminating virtual machines instances, al-locating resources, and scheduling computing tasksand workflows. For security purposes, authorizationmodules and policies in traditional operating sys-tems (e.g., Linux) can be dynamically loaded (e.g.,SELinux modules), and every access to underlyingresources from processes and applications is then becontrolled. Similarly, ACaaS can load different accesscontrol modules and support various security policy

models for different cloud customers, such as manda-tory access control (MAC) [15], the Chinese Wall se-curity policy (CW) [3], and role based access con-trol [17]. This plug & play fashion enables paral-lel evolution of cloud customer’s own policy specifi-cations and a cloud provider’s security enforcementmechanisms.

Figure 2: Security model of AWS IAM.

3 AWS ACCESS CONTROL SERVICEAND ITS LIMITATIONS

To motivate the design and development of ACaaS,we analyze the access control mechanism in AmazonAWS cloud platform. AWS is a leading cloudplatform with a suite of IaaS services, such as elasticcompute cloud (EC2), simple storage service (S3) andelastic block store (EBS), SQL and NoSQL database(SimpleDB and DynamoDB), simple workflow service(SWF), and content distribution services (Cloud-Front). Among various services AWS provides, weparticularly analyze its access control service calledIdentity and Access Management (IAM) [2] whichenables an organization to securely control users’access to the AWS services and resources subscribed


by the organization. IAM defines security policieswith a set of pre-defined components. Figure 2 showsan abstract representation of IAM which consistsof following components: Users, Groups, Actions,Objects, Permissions, Constraints, User-Group-Assignment (UGA), Permission-User-Assignment(PUA), and Permission-Group-Assignment (PGA).Permissions are defined in the form of Actionson Objects under certain Constraints. Note thatsince some AWS action APIs are not necessarilybounded with objects such as CreateKeyPair, whichis an action API of EC2 service to create key pairfor instances, permissions can also contain onlyactions in that case. Objects are identified usingAmazon resource name (ARN). Constraints areimposed on permissions in the form of key-valuepairs. Each key-value pair can be one of followingtypes including String, Numeric, Date and Time,Boolean, and IP address. For example, the state-ment ‘‘DateLessThan":{‘‘aws:CurrentTime":‘‘2012-06-01T00:00:00Z"} uses the Date and

Time type DateLessThan constraint with theaws:CurrentTime key to specify that the requestmust be received before June 1, 2012. Permissionscan be directly assigned to users or groups. Usersexplicitly own permissions assigned to groups theybelong to.

Figure 3: Example AWS IAM policy.

Based on the above-mentioned model components,an IAM policy statement can be formally definedas a 4-tuple P = (user, permission, constraint,

effect), where effect can be Allow or Deny. AnIAM policy can contain several IAM policy state-ments. For example, an IAM policy in JSON formatwith two policy statements is shown in Figure 3. Theuser or group that the policy is attached to is not ex-plicitly shown in the policy statements, who can beany user or group within the root AWS account withID 123456789012. The root AWS account user canexplicitly assign this policy to his users or groups.This policy authorizes users to perform the followingtasks: (i) Create and list the access keys for any userin the AWS account, starting on July 1, 2010; and

(ii) Create and delete Amazon SimpleDB domains inthe 123456789012 AWS account for any region.

AWS IAM enables cloud customers to manage usersand user permissions to secure their resources inclouds. However, we identify several limitations ofIAM for enterprise cloud customers as follows:

1. IAM directly assigns permissions to users.With increasing outsourcing computing infras-tructures to IaaS, the number of users and per-missions can be quite dynamic and in a verylarge scale. The management cost for the map-ping between users and permissions can be ex-tremely high.

2. IAM supports groups to categorize users and letusers explicitly obtain permissions assigned togroups they belong to. However, groups are or-ganized in a flat structure, which cannot reflectthe hierarchical structures of organizations. Forexample, a global sales department of a multi-national company should have all the permis-sions of its regional sales departments. Besides,if an IAM policy is removed from a group, thepermission associated with the policy is revokedas well, which is not necessary in many cases.

3. IAM allows to specify static constraints on per-missions. However, it lacks a systematic sup-port for many other important constraints suchas separation of duty (SoD), a well-known prin-ciple for preventing the potential fraud. SoDdivides the responsibility of a critical task intodifferent people. When many financial and gov-ernmental systems are shifting into cloud plat-forms, SoD issues become even more critical. Ifpermissions with conflict-of-interest issues areassigned to the same user, many valuable as-sets in clouds can be jeopardized.

4. Session management is missing in IAM suchthat all permissions of users are effective all thetimes, which conflicts with the principle of leastprivilege. Users should be able to manage theirsessions for performing tasks. Besides, withoutsession management, dynamic SoD cannot beenforced.

5. IAM does not distinguish administrators andregular users clearly. The root user with theAWS account has both administrative and reg-ular permissions, which also conflicts with theprinciple of least privilege. Ideally, permissionsassociated with an AWS account should be splitinto multiple units.


AWS recently released a new IAM role feature,which enables an EC2 instance running with a prede-fined IAM role to securely access other AWS serviceAPIs [5]. However, this feature is still too prelimi-nary and coarse-grained to address these limitations.First, it only supports assigning IAM roles to an EC2instance level but not to user level. Hence, all appli-cations running in an EC2 instance assume the sameset of permissions. This violates the least privilegeprinciple, since it is very general that different ap-plications in an EC2 instance run on behalf of dif-ferent users to have different permissions. Second,an IAM role does not support session managementsuch that an EC2 instance can only run with a singleIAM role. Without re-launching the EC2 instance, itis impossible to switch between different IAM rolesduring the runtime. Furthermore, EC2 role does notsupport other important RBAC features such as rolehierarchy and delegation. Fundamentally, we claimthat the EC2 role is more similar to the traditionalconcept of “group” in access control and there is noRBAC model formulated in AWS.

III OVERVIEW OF ACaaSRBAC FOR AWS

In this section, we present the overview ofACaaSRBAC , a reference architecture of ACaaS thatsupports RBAC for Amazon AWS cloud platform.We first give an introduction of RBAC, then ar-ticulate challenges on supporting RBAC for AWScloud platform, followed by presenting a formalACaaSRBAC model for AWS. There are several rea-sons that we choose to support RBAC for AWS cloudplatform. First, RBAC has been widely adopted inenterprise applications. When those applications aremoving to clouds, RBAC should be naturally sup-ported in cloud environments. According to a recentcloud market overview [21], RBAC is one of the keycriteria to evaluate cloud computing solutions. Sec-ond, RBAC is a very generic access control model,and we believe tackling RBAC in clouds requires toaddress many challenges that will be identically ad-dressed for supporting other access control modelswith ACaaS. Third, prior research and implementa-tions [8, 18] have demonstrated that RBAC can ad-dress all the identified limitations of AWS IAM ser-vice.

1 ROLE-BASED ACCESS CONTROL

RBAC has been a widely accepted as an alterna-tive to traditional mandatory access control (MAC)

and discretionary access control (DAC) [18], and isan enabling technology for managing and enforcingsecurity in large-scale and enterprise-wide systems.Among many RBAC models proposed in the pastdecades, NIST has defined a standard RBAC model,which has been widely accepted and implemented.The base model presents the central notion that per-missions are associated with roles, users are assignedto appropriate roles, and users acquire permissionsby being members of roles. Users can be easily reas-signed to from one role to another as needed. Sim-ilarly, roles can have new permissions granted andexisting permissions revoked as an organization ac-quires new applications and systems. Users establishsessions during which they may activate a subset ofthe roles they belong to. Each session maps one userto possibly many roles and each user can establishzero or multiple sessions. NIST RBAC also intro-duces role hierarchies which are natural means forstructuring roles to reflect an organization’s lines ofauthority and responsibility. Senior roles explicitlyinherit permissions of their junior roles. Constraintsare defined for laying out higher level organizationalpolicies such as SoD.

2 CHALLENGES OF SUPPORTINGRBAC FOR AWS

In order to provide RBAC as a service for AWS cloudplatform, there are several critical challenges:

Challenge 1: Efficient role hierarchy management.In cloud computing environments, due to dynamicbusiness needs and scalable resource provisioning, thenumber of roles in an organization could be very largeand fluctuated frequently. Accordingly, role hierar-chies in the organization could be complex and needto be updated. It is crucial to have an efficient way tomanage role hierarchies in terms of both maintenanceand update/change management.

Challenge 2: Session management. Session man-agement should be supported to track users’ inter-actions and meet the least privilege principle. Usersshould be able to activate or deactivate their rolesfor performing certain tasks in their sessions. Withthe nature of highly distributed service-oriented com-puting infrastructure, ACaaSRBAC has to seamlesslysupport session management without compromisingthe security property of RBAC.

Challenge 3: SoD support and management of priv-ileged account. SoD constraints should be speci-fied by administrators and each cloud should be able


to enforce those constraints for avoiding permissionabuse and unexpected fraud. The super user of anAWS account has all privileges upon cloud resources,which should be split into different units or roles inACaaSRBAC .

Challenge 4: System integration and minimal over-head. To leverage the pluggable capabilities providedby ACaaS, ACaaSRBAC services should be easily in-tegrated with customers’ applications. Besides, thisintegration should introduce acceptable performanceand network traffic overheads between customers’ ap-plications and AWS cloud platform.

Our design of ACaaSRBAC addresses all these chal-lenges with a service-oriented RBAC for AWS cloudresources, which is detailedly explained in next sec-tion. In the rest of this section we define a formalmodel for ACaaSRBAC .

3 ACaaSRBAC MODEL FOR AWS

Beyond the existing RBAC96 [17] and NIST RBACmodels [8], ACaaSRBAC integrates the group conceptof IAM into RBAC. Furthermore, ACaaSRBAC intro-duces the concept of administrative scope towards avery comprehensive administration model. In thissection, we formally define the core model and ad-ministration model, while postpone their security as-sessment and safety analysis [13] to our future work.

3.1 CORE MODEL

Similar to NIST RBAC standard, our coreACaaSRBAC distinguishes regular users and admin-istrative users. Beyond this, our model introducesthe concept of group so that we can manage user setsand relatively static permission sets to capture theuser group in AWS IAM. Group can be a good coun-terpart to role for better managing user sets and rel-atively static permission sets. Correspondingly, ouradministrative model supports managing user groups.

Definition 1. [Core Model] We define the compo-nents of ACaaSRBAC core model as follows:

• U, AU, G, R, AR, P, AP, S are sets of reg-ular users, administrative users, groups, roles,administrative roles, user permissions, adminis-trative permissions, and sessions, respectively.

• UR ⊆ U × R is many-to-many regular user torole assignment relation.

• PR ⊆ P × R is many-to-many user permission

to role assignment relation.

• RH ⊆ R × R is a partially ordered role hierar-chy. ri ≥ rj means a role ri is senior to a rolerj and inherits the permissions of rj .

• UG ⊆ U × G is many-to-many regular user togroup assignment relation.

• PG ⊆ P × G is many-to-many user permissionto group assignment relation. Users explicitlyown permissions assigned to groups they belongto and those permissions are activated by de-fault.

• AUAR ⊆ AU × AR is many-to-many admin-istrative user to administrative role assignmentrelation.

• APAR ⊆ AP × AR is many-to-many admin-istrative permission to administrative role as-signment relation.

• Sessions: U → 2S is a function that maps aregular user to a set of sessions.

• Roles: S → 2R is a function that maps a sessionto a set of roles.

• Permissions: S → 2P is a function that derivedfrom PR ∪ PG mapping each session to a setof user permissions.

3.2 ROLE-BASED ADMINISTRATIONMODEL

Based on the components in the core model, we definea role-based administration model for ACaaSRBAC ,which consists of four components: administra-tive resources, administrative actions, administrativescopes, and administrative policies.

Definition 2. [Administrative Resource] The setof administrative resources RESA ⊆ U ∪ G ∪ P ∪ R.

Definition 3. [Administrative Action] The set ofadministrative actions ACTA = {Create, Delete, As-sign, Revoke}, where action Create and Delete cor-respond to administrative resources including U, R,G and P, and action Assign and Revoke correspondto relations among UR, UG, PR, and RH.

An administrative action can be performed on ad-ministrative resources by an administrative user. Forinstances, Create(u) creates a regular user u ∈ U ,and Assign(u, r) assigns a regular user u ∈ U to arole r ∈ R, which further introduces a regular user torole assignment relation, i.e., (u, r) ∈ UR.

Extended from existing Range notion in the AR-BAC97 model [16], which is only defined on roles


Figure 4: ACaaSRBAC for AWS.

to control user-role assignment, we introduce theconcept of administrative scope to accommodate theuser and group concepts in current AWS IAM pol-icy. Specifically, an administrative scope is a prop-erty of an administrative role, which can be specifiedon particular users, groups, permissions, and roles.An administrative user can perform administrativeactions on administrative resources within the scopesassociated with her administrative roles.

Definition 4. [Administrative Scope] SCO ⊆ 2U

× 2G × 2P × 2R is the set of administrative scopesSCO in ACaaSRBAC .

• Get U: SCO → 2U is a function that maps anadministrative scope to a set of regular usersspecified in that scope.

• Get G: SCO → 2G is a function that maps anadministrative scope to a set of groups specifiedin that scope.

• Get P: SCO → 2P is a function that mapsan administrative scope to a set of permissionsspecified in that scope.

• Get R: SCO → 2R is a function that maps anadministrative scope to a set of roles specifiedin that scope.

• Get RESA: SCO → 2RESA is a functionthat maps an administrative scope to a setof administrative resource; Get RESA(sco) =Get U(sco) ∪ Get G(sco) ∪ Get P(sco) ∪Get R(sco).

• Scopes: AR → 2SCO is a function that mapsan administrative role to a set of administra-tive scopes.

• Scope U: AR → 2U is a function that maps

an administrative role to a set of regular users;Scope U(ar) =

∪sco∈Scopes(ar) Get U(sco).

• Scope G: AR → 2G is a function that mapsan administrative role to a set of groups;Scope G(ar) =

∪sco∈Scopes(ar) Get G(sco).

• Scope P: AR → 2P is a function that maps anadministrative role to a set of user permissions;Scope P(ar) =

∪sco∈Scopes(ar) Get P(sco).

• Scope R: AR → 2R is a function that mapsan administrative role to a set of roles;Scope R(ar) =

∪sco∈Scopes(ar) {r | ∀r‘ ∈

Get R(sco), r‘ ≥ r}.

Table 1 shows administrative actions of an adminis-trative user of a role ar ∈ AR, and its pre- and post-conditions. To authorize administrative actions, weintroduce a formal definition of administrative poli-cies as follows:

Definition 5. [Administrative Policy] An admin-istrative policy is a 4-tuple pa = <ar, act, resa, sco>,where ar ∈ AR, act ∈ ACTA, resa ⊆ Get RESA(sco),and sco ∈ Scopes(ar), which authorizes an adminis-trative user with the administrative role ar to per-form the administrative action act on a set of ad-ministrative resources resa within the administrativescope sco corresponding to ar.

IV SYSTEM DESIGN

1 OVERVIEW

Figure 5 shows the system architecture ofACaaSRBAC . In current AWS platform, enterprise


Table 1: Administrative Actions

Action Preconditions PostconditionsCreate(u) N/A u ∈ U, u ∈ Scope U(ar)Delete(u) u ∈ Scope U(ar) u /∈ U, u /∈ Scope U(ar)Create(g) N/A g ∈ G, g ∈ Scope G(ar)Delete(g) g ∈ Scope G(ar) g /∈ G, g /∈ Scope G(ar)Create(p) N/A p ∈ P, p ∈ Scope P(ar)Delete(p) p ∈ Scope P(ar) p /∈ P, p /∈ Scope P(ar)Create(r) N/A r ∈ R, r ∈ Scope R(ar)Delete(r) r ∈ Scope R(ar) r /∈ R, r /∈ Scope R(ar)

Assign(ri, rj) ri, rj ∈ Scope R(ar) (ri, rj) ∈ RHRevoke(ri, rj) ri, rj ∈ Scope R(ar) (ri, rj) /∈ RHAssign(u, g) u ∈ Scope U(ar), g ∈ Scope G(ar) (u, g) ∈ UGRevoke(u, g) u ∈ Scope U(ar), g ∈ Scope G(ar) (u, g) /∈ UGAssign(u, r) u ∈ Scope U(ar), r ∈ Scope R(ar) (u, r) ∈ URRevoke(u, r) u ∈ Scope U(ar), r ∈ Scope R(ar) (u, r) /∈ URAssign(p, r) p ∈ Scope P(ar), r ∈ Scope R(ar) (p, r) ∈ PRRevoke(p, r) p ∈ Scope P(ar), r ∈ Scope R(ar) (p, r) /∈ PRAssign(p, g) p ∈ Scope P(ar), g ∈ Scope G(ar) (p, g) ∈ PGRevoke(p, g) p ∈ Scope P(ar), g ∈ Scope G(ar) (p, g) /∈ PG

applications are able to access cloud resources onbehalf of enterprise users, where the AWS IAM en-forces security policies defined by enterprise adminis-trators. ACaaSRBAC introduces RBAC as a service(RaaS), which is an RBAC module designed basedon NIST RBAC standard [8] and can be hosted byAWS or any third party service provider. This mod-ule supports and enforces RBAC configurations byleveraging Amazon IAM service for enterprise ad-ministrators. It also provides session capability forenterprise users, e.g., a user or an application canactivate and deactivate roles within a single sessionwhen accessing resources in AWS 1.

Figure 5: ACaaSRBAC system architecture for AWS.

RaaS provides browser interfaces for enterprise ad-ministrators and users to configure RBAC policies.In our prototype (cf. Section V), RBAC policies are

implemented as a relational database which stores therelationships according to our ACaaSRBAC model in-troduced in Section III. RaaS also provides web ser-vices APIs such that operations can be integratedinto administrative tools or applications from the en-terprise side. The results of these configurations areIAM policies that are pushed back to AWS, so thatany further access from enterprise applications will becontrolled by these policies. Since IAM does not sup-port RBAC, RaaS transforms all role-based policiesof a user into AWS permission based policies whichcan be understandable and enforceable by IAM. Thetransformation process is to generate direct relation-ships between users and permissions by removing therole notion between them in the role-based policies.For an enterprise that already has AWS resources inactive use, RaaS provisions the information of users,groups, permissions, objects, and actions from AWSvia IAM APIs.

According to ACaaSRBAC model, RaaS containseight sub-modules: Organization, User, Group, Role,Permission, Session, Constraint and Policy, each ofwhich is exposed as web services. The Organiza-tion sub-module manages (e.g., list, register, anddelete) organizations to support the multi-tenant fea-ture of ACaaSRBAC . The Group sub-module man-ages user groups of a single organization for admin-istrative users, where the user information is provi-

1We note that an RBAC session here is usually different from that in AWS services, e.g., a DynamoDB session, althoughthey can be co-related in an implementation.


sioned from the organization’s AWS account. ThePermission sub-module manages the permissions ofACaaSRBAC . There are two types of permissions:user permissions (P) which are inherited from exist-ing AWS permissions, and administrative permissions(AP), which are effective for RaaS only. The Per-mission sub-module maintains both P and AP, andmanages their assignment relations with roles. Weelaborate the design of sub-modules in the rest ofthis section.

2 USER AND PERMISSION

This sub-module provides management on regularusers (U ), administrative users (AU ), and permis-sions (P), and provides interfaces and APIs to cre-ate, delete, activate, and deactivate U, AU, and P,and manage their group memberships and role mem-berships. In RaaS design, both regular users and per-missions are provisioned from AWS directly, with thecredentials of the AWS account, which is usually theuser who can create other users and policies in IAM.Therefore, RaaS does not store any information forU and P.

Administrative users can be further categorized intotwo types: root administrative users and regular ad-ministrative users. Root administrative users areable to add and delete regular administrative users,and manage their permissions. Regular administra-tive users are able to perform certain administrativeactions (ACTA) on administrative resources (RESA)based on their administrative role memberships. Bydefault, a root administrative user is the AWS userthat owns the IAM account. With the interfaces pro-vided by RaaS, this user can further create regularadministrative users and roles, and their administra-tive scopes. By controlling the user-role assignmentsto regular users and administrative users, RaaS cansupport flexible policies such as splitting privilegedaccounts, and separation of duty constraints.

3 ROLE

This sub-module creates and deletes roles (R) andadministrative roles (AR), and most importantly, itmanages role hierarchies (RH ). RaaS distinguishes Rand AR such that mandatory security policies canbe enforced, e.g., by only assigning necessary regularroles to regular users. For least privilege purposes,RaaS may introduce many primitive regular roles,each of which is assigned with atomic permissions.This usually introduces large number of regular roles

in a system, where role hierarchy becomes necessary.

Towards efficient role-related operations, we adoptthe Nested Set Model [12] for role hierarchy in ourimplementation, which assigns left and right valuesto represent a scope of each role in a role hierarchy.If the scope of a role is inside the scope of anotherrole, it means the former role is junior to the latterrole. Figure 6(a) shows an example of role hierarchy,where left and right values are assigned to each rolein the role hierarchy as well as the Nested Set Modelrepresentation of the role hierarchy. A big advantageof Nested Set Model for managing role hierarchies isthat only one entry for each role needs to be main-tained in the database. This avoids storing a lot ofredundant role relationship information to maintainrole hierarchies. It is also easy to update role hierar-chies by updating associated roles’ left and right val-ues. One limitation of our current design is that, theNested Set Model only supports to represent limitedrole hierarchies in a simple tree structure, i.e., oneof two role hierarchies based on NIST RBAC stan-dard [8]. As our future work, we would extend ourimplementation towards more general role hierarchymanagement.

4 SESSION

This module provides session management includ-ing role activation and deactivation for regular users.Usually, a user can be assigned with several roles atthe same time. In a session, to meet the least privilegeprinciple, only some of those roles which are neededto perform a certain task should be activated. Afterfinishing this task, relevant activated roles can be de-activated. When activating a role, permissions asso-ciated with that role should be effective by enforcingcorresponding Amazon IAM policies such that usersare able to access cloud resources with needed per-missions.

An intuitive way for deactivating a role and activat-ing another role is to remove all permissions of theoriginal role for the user in IAM, and then createnew permissions and policies, and push all new poli-cies to IAM. This is the approach we adopt if thesetwo roles have no overlapped permissions. With theexistence of role hierarchy, it may not be necessaryto generate and enforce Amazon IAM policies for allpermissions of the new role since some permissionsmay have already been effective, e.g., these two roleshave common inherited permissions from role hierar-chy. For an example shown in Figure 6(b), suppose


(a) Role Hierarchy in Nested Set Model. (b) Role Activation and Deactivation

Figure 6: Role hierarchy and usage in ACaaSRBAC system implementation.

only role r2 and r4 are activated and role r1 needs tobe activated. In this case, it is necessary to generateand enforce Amazon IAM policies only for permissionp2, p4, and p6, since r1 has already been effective dueto the activated role r2 and r4.

To improve the efficiency of role activation and min-imize the communication overheads between RaaSmodule and AWS cloud platform, we implement anefficient role activation algorithm to compute a mini-mum permission set when activating a role, as shownin Algorithm 1. This algorithm works as follows: if auser u owns an immediate senior and activated role torole ra which needs to be activated, an empty permis-sion set is returned and no policy needs to be gener-ated and enforced by Amazon IAM. Otherwise, Foreach sibling role and immediate junior role to rolera, their senior-most and activated junior roles areidentified recursively and a corresponding permissionset Pall is constructed. Then for each permission as-sociated with the role ra, if it does not belong toPall, then it will be added to the returned permis-sion set. On the other hand, when deactivating roles,the deactivation should not affect functionalities ofother activated roles when they have overlapped per-missions. For example, suppose only role r2 and r4in Figure 6(b) are activated and role r2 needs to bedeactivated. To avoid affecting the functionality ofrole r4, only permission p8 and p10 should be inef-fective in AWS by enforcing corresponding AmazonIAM policies. Permission p9 remains effective sincerole r4 owns permission p9.

Correspondingly, we implement a role deactivationalgorithm, as shown in Algorithm 2. The algorithmworks as follows: if any senior role to a role rd which

needs to be deactivated is activated, an empty per-mission set is returned and no policy needs to be gen-erated and enforced by Amazon IAM. Otherwise ifrole rd does not have any activated sibling roles, apermission set containing all permissions associatedwith the role rd is returned. Otherwise, a permissionset Pall containing all permissions associated withactivated sibling roles of the role rd is constructed.Then for each permission associated with the role rd,if it does not belong to Pall, it is added into the re-turned permission set.

5 CONSTRAINT

This sub-module provides constraints managementservices including creating, deleting, updating staticconstraints as well as separation of duty constraints.Static constraints are specified on permissions in ex-isting Amazon IAM constraints format discussed inSection 3 and enforced by IAM. Only when the staticconstraints are satisfied, users are able to performcorresponding permissions. When creating an SoDconstraint, a set of potential conflicting roles and acardinality value need to be specified. The cardinal-ity value is a threshold of the total role occurrence inthe potential conflicting role set. When it is reached,IAM security policy of the user will be updated andany corresponding request will be denied. SoD con-straints are enforced by Constraint sub-module itselfwhen administrative users assign users to roles, orusers activate their roles. Those static constraintsare then converted into IAM policies and pushed intoAWS.

Dynamic separation of duty (DSoD) constraints are


Algorithm 1: ComputeActivatePermissions(u, ra) → P

Input: A user u wants to activate a role raOutput: A permission set P, of which corresponding IAM

policies need to be enforced1 P ← ⊘;2 Pall ← ⊘;3 ris ← getImmediateSeniorRole(ra);4 if hasRole(u, ris) = TRUE AND active(u, ris) = TRUE

then5 return ⊘;6 else7 ComputeP(u, ra);8 foreach p ∈ Permissions(ra) do9 if p /∈ Pall then

10 add p into P ;11 end

12 end13 return P ;

14 end15 ComputeP(User u, Role ra)16 begin17 R ← getSiblingRoles(ra)

∪getImmediateJuniorRoles(ra);

18 if R = ⊘ then return;19 else foreach r ∈ R do20 if active(u, r) = TRUE then21 foreach p ∈ Permissions(r) do22 if p /∈ Pall then23 add p into Pall;24 end

25 end

26 else27 ComputeP(u, r);28 end

29 end

30 end

Algorithm 2: ComputeDeactivatePermissions(u, rd) →

P

Input: A user u wants to deactivate a role rdOutput: A permission set P, of which corresponding IAM

policies need to be enforced1 P ← ⊘;2 Pall ← ⊘;3 Rsenior ← getSeniorRoles(rd);4 if Rsenior ̸= ⊘ then5 foreach r ∈ Rsenior do6 if active(u, r) = TRUE then7 return ⊘;8 end

9 end

10 end11 Rsibling ← getActivatedSiblingRoles(rd);12 if Rsibling = ⊘ then13 return Permissions(rd);14 else15 foreach r ∈ Rsibling do16 if active(u, r) = TRUE then17 foreach p ∈ Permissions(r) do18 if p /∈ Pall then19 add p into Pall;20 end

21 end

22 end

23 end24 foreach p ∈ Permissions(rd) do25 if p /∈ Pall then26 add p into P ;27 end

28 end29 return P ;

30 end

usually enforced during runtime, e.g., conflicting rolescannot be activated in a single session. Similar con-straints can be defined and checked by the sessionmodule.

6 POLICY

This sub-module provides Amazon IAM policy gener-ation and pushing services to ensure RBAC configu-rations of an enterprise can be reflected in AWS cloudplatform. For example, when a user activates or deac-tivates roles, corresponding Amazon IAM policies aregenerated and pushed to the Amazon IAM policy en-gine for the enforcement. More specifically, for eachpermission in the permission set computed by Algo-rithm 1 or Algorithm 2, a corresponding IAM policyis constructed and sent to IAM for the enforcement.Policy transformation and deployment are also trig-gered by other administration actions that change theregular permissions of a user.

We note that our policy transformation is both com-plete and sound. That is, each state of the RaaS(the ACaaSRBAC relationships stored in its localdatabase) can be translated to a set of IAM policies,

e.g., each regular user has an IAM policy. This isdue to the fact that both the users and permissionsare provisioned from AWS directly. For each RaaSstate, the net result of its configuration is a set ofpermissions that are authorized for a user, after re-volving the constraints such as SoD and DSoD. Sim-ilarly, each translation corresponds to a valid IAMpolicy since the permissions are defined with validresource names and actions defined by AWS.

7 CONCURRENCY CONTROL

As shown in Figure 5, for performance and compati-bility considerations, a AWS user or application canaccess AWS resources by directly calling AWS inter-faces or APIs, while RaaS pushes IAM policies withanother channel. Therefore, there are chances thata user’s session of using AWS resources is ongoing,while any of required permissions is revoked, i.e., dueto some administrative operations in RaaS by an ad-ministrator. This concurrency control issue has beendiscussed in [26] in context of XACML, where a lockmanager is proposed to revoke active permission ordelay the administrative operation. In our design, wetake the conservative approach of delaying the revok-


ing operation, since our RaaS cannot actively revokean ongoing access session in AWS, due to the factthat it runs out of AWS platform.

V IMPLEMENTATION & EVALUATION

Based on our design, we have implemented a proto-type system to provide RBAC services in AWS cloudplatform through a web browser interface as well asweb services. The core services of the system areimplemented in Java based on AWS SDK 1.3.0 andexposed as SOAP-based web services using GlassFishMetro 2.2. A web-based management interface is de-veloped by using JavaServer Pages (JSP) and MySQLCommunity Server 5.1. Both administrative usersand normal users can log into the interface with theirusernames and passwords. Administration tools caninteract with the system by calling the SOAP-basedweb services APIs where the body of messages aresigned with pre-shared secret keys.

All entities of the major components in ACaaSRBAC

model (cf. Section 3) are stored in tables of a rela-tional database, which jointly represents the state ofthe RaaS system. The name spaces of permissions,which are built on resources in AWS, are provisionedthrough AWS APIs. An administrative operation re-sults in calling one or more AWS APIs, e.g., to createa user, a group, a permission, or add or remove anIAM policy in the root user’s AWS account.

We evaluated our ACaaSRBAC system in terms oftwo metrics: efficiency and scalability. Specifically,a scenario-based case study is presented to illustratehow services provided by ACaaSRBAC can be uti-lized by existing cloud applications. We then showthe performance overheads and network traffic over-heads measured on role activation and deactivationservices.

1 SCENARIO DESCRIPTION

IT sandboxes are isolated computing environmentswhich can be used for software development and test.Consider a company called VirtualSoft which devel-ops software systems using IT sandboxes and adoptsRBAC for managing the access to its sandboxes’ re-sources. Due to increasing customers’ needs and costefficiency, VirtualSoft decides to migrate its sandboxenvironments from its on-premise data center to AWScloud platform. However, AWS cloud platform doesnot support RBAC for its authorization mechanism.To bridge this gap, VirtualSoft leverages services pro-

vided by ACaaSRBAC system for RBAC enforcementon AWS cloud platform. Consider two ongoing col-laborative projects – Project 1 and Project 2, usingtwo development sandbox environments – DSE1 andDSE2, respectively. These two sandboxes are built ontwo Amazon EC2 M1 large instances CI1 and CI2 forcomputing and two Amazon RDS instances SI1 andSI2 for database services, respectively. They shareanother Amazon M1 medium instance CI3 which runsPerforce for source code version control, and an Ama-zon S3 bucket B1 for storing collaborative documentsand slides. The role hierarchies of both projects areshown in Figure 7: Project 1 has four roles of PL1,DEV1, QA1, and SE1, and Project 2 has two roles ofPL2 and DEV2. Each role is associated with certainpermissions for accessing various sandbox resourcesbuilt on AWS cloud. For instance, developers work-ing on Project 1 are assigned to the role Dev1, whichenables them to access any resource under DSE1 con-sisting of CI1, SI1, CI3, and B1. Similarly, Project2 developers who are assigned to the role Dev2 areable to access any resource under DSE2 consistingof CI2, SI2, CI3, and B1. Each permission is fur-ther corresponding to an IAM policy generated bythe ACaaSRBAC Policy module (cf. Section 6). Tak-ing an example shown in Figure 7, two IAM policiesPolicy 1 and Policy 2 are respectively in correspon-dence with two permissions p1 and p2 of the roleDev1. Policy 1 is to enable the access to the AmazonS3 bucket B1, and Policy 2 is to enable the accessthe Amazon EC2 instance CI1. Those two policiesare pushed to Amazon IAM service for enforcementwhen a user activates the role Dev1.

2 EXPERIMENT ENVIRONMENT ANDRESULTS

In our experiment, ACaaSRBAC is hosted in a desk-top machine with Intel Core2 Duo CPU 3.00 GHz4 GB RAM running Ubuntu 11.10. Assume Aliceis a member of the role Dev1 working on Project 1and Bob is a member of the role Dev2 working onProject 2. In order to accomplish a collaborative taskacross projects, Alice needs to be assigned to the roleDev2 to access the resources of DSE2. We measurethe Dev2 role activation for Bob when he logs in thesandbox system and the Dev2 role activation for Alicewhen she is assigned to the role Dev2 in terms of per-formance overhead (T) and network traffic overhead(NT).

Table 2 shows corresponding average results basedon 10 measurements. Performance overhead can be


Figure 7: A Sandbox scenario for software test in AWS with ACaaSRBAC .

divided into two sub parts: policy generation (PG)time and policy transmission and enforcement (PTE)time. The PTE introduced by AWS platform takesup above 95% of total overhead. Note that the sameDev2 role is activated for Alice and Bob. However,both performance overhead and network traffic over-head for Alice are much less than that for Bob. Thisis because the role activation service efficiently iden-tifies the permission overlap between the role Dev1

and Dev2 – both have the permissions to access CI3and B1 – to minimize the communication cost be-tween ACaaSRBAC and Amazon IAM as discussed inSection IV.

To evaluate the scalability of ACaaSRBAC , we createmultiple threads and measure average performanceoverhead and total network traffic overhead while in-creasing the numbers of simultaneous role activationand deactivation requests from different users. Someof the users are the members of role Dev1 and someare members of role Dev2. Figures 8(a) and 8(b)respectively show the average performance overheadper request including PG overhead and PTE over-head, as the number of role activation and deactiva-tion requests increases from 10 to 50. We observethat the average performance overhead for a role ac-tivation request increases smoothly as the numberof simultaneous requests is increased. The PG over-head takes up a smaller portion of a role activationrequest overhead than the PTE overhead does, un-til the number of role activation requests reaches to50. The PTE overhead contributes the most por-tion of the role deactivation request overhead. Fig-ure 8(c) shows the total network traffic overhead asthe number of role activation and deactivation re-quests increases from 10 to 50. The network traffic

overhead for role activation requests is slightly largerthan that of role deactivation requests as the numberof requests increases. When the number of role acti-vation requests is 10, the total network traffic over-head is around 150 kb. When the number of roleactivation requests increases to 50, the total networktraffic overhead is just above 700 kb, which we believeis still manageable. To further enhance the efficiencyand scalability of our implementation, our role activa-tion service is extended to support activating multipleroles as a batch operation. Figure 8(d) shows the av-erage performance overhead on activating one, two,and three roles per request while increasing the num-ber of role activation requests simultaneously from10 to 50. The average performance overhead on ac-tivating two roles as a batch operation per request islower than two times of that on activating one roleper request at the same number of requests. Similarfindings can be observed when comparing the averageperformance overhead of three roles batch activationrequests with that of one role.

VI RELATED WORK

There are several authorization and access control so-lutions in cloud computing. Calero et al. [4] proposean authorization model that supports multi-tenancy,role-based access control, path-based object hierar-chies, and federation. Hu et al. [11] introduce se-mantic web technologies to distributed role-based ac-cess control method and propose a new Semantic Ac-cess Control Policy Language (SACPL) for describ-ing access control policies in cloud computing envi-ronments. Access Control Oriented Ontology Sys-tem (ACOOS) is designed as the semantic basis of


(a) Activation Time (b) Deactivation Time

(c) Network Traffic (d) Batch Activation Time

Figure 8: Overheads of activating and deactivating roles.

SACPL. In [19], Santos et al. propose the design ofa trusted cloud computing platform (TCCP). TCCPprovides the abstraction of a closed-box execution en-vironment for a customer’s VM, guaranteeing thatno cloud provider’s privileged administrator can in-spect or tamper with its content. However, this ap-proach requires the correctness of large and com-plex codebases, such as hypervisor, device drivers,or entire kernels. Cloud computing may face a sce-nario that an attacker shares the same physical re-sources with other tenants. Sharing resources couldlead to information leakage due to known or unknowncovert channels. Zhu et al. [28] design CloudPolice,a distributed access control mechanism implementedin hypervisors, to meet the access control needs of

multi-tenancy, network-independence, and scalabilityin cloud computing environment. Their access con-trol solution is designed from network perspective,which may fail to prevent diverse unauthorized ac-cesses in applications. We note that these approachesattempt to address specific issues in access control,but do not consider a comprehensive approach thatsupports various policy models and can be embodiedas service modules in clouds.

Another line of research work deal with access con-trol issues by leveraging cryptographic techniques incloud computing environments. Echeverria et al. [6]presented an effective solution for de-coupling ac-cess control from services that provide content by


Table 2: Access Control Overheads

T(ms) PG(ms) PTE(ms) NT(kb)Dev2 Activation for Bob 1898.9 91.6 1807.2 15.95Dev2 Activation for Alice 1200.2 47.4 1152.4 14.652

leveraging attribute based encryption (ABE). Yu etal. [27] combine attribute-based encryption, proxy re-encryption, and lazy re-encryption to delegate mostof the computation tasks involved in user revocationto untrusted cloud service providers. Tassanaviboonand Gong [22] propose a new authorization schemethat combats untrusted cloud servers by adoptingCP-ABE, ElGamal like masks, proxy re-encryption,and lazy re-encryption to achieve user-centric andend-to-end security. Wan et al. [23] introduce theHASBE scheme which incorporates a hierarchicalstructure of system users by applying a delegationalgorithm to ASBE. CloudSeal [25] uses proxy re-encryption and broadcast revocation algorithms forflexible content access control in cloud. Even thoughcryptographic approach is effective for some specificrequirements, they have no support for legacy secu-rity policies in enterprises such as role-based accesscontrol.

There are also industrial efforts on building RBACsupport in cloud computing platforms. The latestAWS IAM enables EC2 instances to run with pre-defined IAM roles to securely access AWS serviceAPIs [5]. However, it only allows assigning IAMroles to EC2 instances not to users. Hence, all ap-plications running in an EC2 instance assume thesame permission set of the IAM role. XenServer [24]only provides 6 pre-established roles with capabilitiesto modify permissions on them but no functionalityto add or delete roles. OpenStack [14] realizes therole notion by using user assigned tokens. Eucalyp-tus [7] integrates existing Microsoft Active Directoryor LDAP systems to capture the role notion for man-aging the access over cloud resources. In our analysis,all of above solutions fail to accommodate core RBACfunctions such as role hierarchy, session management,and role-based administration and delegation; there-fore, none of them provides a comprehensive built-inRBAC model.

VII CONCLUSION AND FUTURE WORK

We articulate the critical need of a comprehensive andfine-grained access control mechanism to meet dy-namic, configurable, and extensible security require-ments in public IaaS cloud computing environments.

To accommodate this need, we propose a new mod-ular architecture towards access control as a service(ACaaS) for supporting multiple access control mod-els. As a reference implementation, we design and im-plement ACaaSRBAC , a service architecture that sup-ports configurations of RBAC as a service for Ama-zon Web Services. Our case study and system per-formance evaluation demonstrate the practicality andefficiency of our approach. For future work, we wouldevaluate our system with real-world datasets. In ad-dition, we would enhance our system with flexibledelegation mechanisms and accommodate revocationrequirements, and design a more generic architectureto support other access control policies such as multi-level and general mandatory access control policies.

ACKNOWLEDGEMENT

The work of Ruoyu Wu, Gail-Joon Ahn and HadiSharifi was partially supported by the grants fromNational Science Foundation and Department of En-ergy. The work of Haiyong Xie was supported inpart by NSFC Grant No. 61073192, by 973 Pro-gram Grant No. 2011CB302905, by NCET ProgramGrant No. NCET-09-0921, and by USTC Grant No.WK0110000014.

References

[1] Exploring the Cloud: A Global Study of Gov-ernments’ Adoption of Cloud. Technical report,KPMG International Cooperative, 2012.

[2] AWS Identity and Access Management (IAM).http://docs.amazonwebservices.com/IAM/latest/UserGuide.

[3] D. Brewer and M. Nash. The chinese wall se-curity policy. In Security and Privacy, 1989.Proceedings., 1989 IEEE Symposium on, pages206–214. IEEE, 1989.

[4] J. Calero, N. Edwards, J. Kirschnick,L. Wilcock, and M. Wray. Toward a multi-tenancy authorization system for cloud services.Security & Privacy, IEEE, 8(6):48–55, 2010.


[5] AWS Document, Working with Roles.http://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html.

[6] V. Echeverria, L. Liebrock, and D. Shin. Per-mission management system: Permission as aservice in cloud computing. In Computer Soft-ware and Applications Conference Workshops(COMPSACW), 2010 IEEE 34th Annual, pages371–375. IEEE, 2010.

[7] Cloud Computing Software from Eucalyp-tus — Leader in Cloud Software, 2012.http://www.eucalyptus.com/.

[8] D. Ferraiolo, R. Sandhu, S. Gavrila, D. Kuhn,and R. Chandramouli. Proposed nist standardfor role-based access control. ACM Transactionson Information and System Security (TISSEC),4(3):224–274, 2001.

[9] Federal Information SecurityManagement Act (FISMA).http://csrc.nist.gov/drivers/documents/FISMA-final.pdf.

[10] U.S. Department of Health and HumanServices. The Health Insurance Portabil-ity and Accountability Act (HIPAA), 2011.http://www.hhs.gov/ocr/privacy/.

[11] L. Hu, S. Ying, X. Jia, and K. Zhao. Towardsan approach of semantic access control for cloudcomputing. Cloud Computing, pages 145–156,2009.

[12] M. J. Kamfonas. Recursive hierarchies. The Re-lational Journal, 1992.

[13] N. Li and M. Tripunitara. Security analysis inrole-based access control. ACM Transactionson Information and System Security (TISSEC),9(4):391–420, 2006.

[14] OpenStack Compute Administration, 2012.http://docs.openstack.org/essex/openstack-compute/admin/content/.

[15] R. Sandhu. Lattice-based access control models.Computer, 26(11):9–19, 1993.

[16] R. Sandhu, V. Bhamidipati, and Q. Munawer.The arbac97 model for role-based administrationof roles. ACM Transactions on Information andSystem Security (TISSEC), 2(1):105–135, 1999.

[17] R. Sandhu, E. Coyne, H. Feinstein, andC. Youman. Role-based access control models.Computer, 29(2):38–47, 1996.

[18] R. Sandhu and P. Samarati. Access control:principle and practice. Communications Mag-azine, IEEE, 32(9):40–48, 1994.

[19] N. Santos, K. Gummadi, and R. Rodrigues. To-wards trusted cloud computing. In Proceedingsof the 2009 conference on Hot topics in cloudcomputing, page 3. USENIX Association, 2009.

[20] The Sarbanes-Oxley Act of 2002(SOX).http://sec.gov/about/laws/soa2002.pdf.

[21] J. Staten and L. E. Nelson. Market Overview:Private Cloud Solutions, Q2 2011. Technical re-port, Forrester Research, Inc, 2011.

[22] A. Tassanaviboon and G. Gong. Oauth and abebased authorization in semi-trusted cloud com-puting: aauth. In Proceedings of the second in-ternational workshop on Data intensive comput-ing in the clouds, pages 41–50. ACM, 2011.

[23] Z. Wan, J. Liu, and R. Deng. Hasbe: A hier-archical attribute-based solution for flexible andscalable access control in cloud computing. In-formation Forensics and Security, IEEE Trans-actions on, (99):1–1, 2011.

[24] Available Role Based Access Con-trol Permissions for XenServer, 2012.http://support.citrix.com/article/CTX126441.

[25] H. Xiong, X. Zhang, D. Yao, X. Wu, and Y. Wen.End-to-end content protection in cloud-basedstorage and delivery services. In Proc. of ACMConference on Data and Application Securityand Privacy (CODASPY), 2012.

[26] M. Xu, D. Wijesekera, and X. Zhang. Runtimeadministration of rbac profile for xacml. IEEETransactions on Services Computing (TSC),(4):286–299, 2011.

[27] S. Yu, C. Wang, K. Ren, and W. Lou. Achiev-ing secure, scalable, and fine-grained data accesscontrol in cloud computing. In INFOCOM, 2010Proceedings IEEE, pages 1–9. IEEE, 2010.

[28] Y. Zhu, H. Hu, G. Ahn, D. Huang, and S. Wang.Towards temporal access control in cloud com-puting. In INFOCOM, IEEE, 2012.


Date post:	17-Sep-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Design and Implementation of Access Control as a Service for ...AWS cloud platform. AWS is a leading...

Documents