The Role Based Access Control List

Published Date: 02 Nov 2017

1. Introduction:

This paper proposes a study on access control model used in cloud environment. Cloud environment is composed of many entities. It is a collection of application servers, data storage servers, node controllers and one administrator entity named cloud service providers. It is very difficu lt to control all of them to make whole system running. Apart fro m that it’s again needed to deploy security mechanisms to protect whole system. As a client of this system one would just think of cloud as a one single entity. In reality cloud is having many dimensions. So, to protect cloud from any threat security should also be applied at different junction. There are at application layer, data storage layer, network layer and at hardware layer. Our main concern is to target access control approach for maintaining truthfulness of user’s data. To protect user’s sensitive data fro m any unauthorized access ACL plays major role. Although many techniques have been designed by many researchers, but all of them are not applicable to cloud environment. In beginning era of technology there are few tradit ional acces s control mechanis m are used. As before few years only stand alone machine were in used. For that kind of machines only simp le access control list approach was used. Although it is not that much secure to maintain truthfulness of stored data. In addition to that ravi sandhu et. al[13] had designed new approach of role based access control mechanisms. Moreover, he had divided RBA C approach in many classes. They are flat, hierarchical, Constraints based and symmet ric role based access control mechanism. Each o f them is having some advantages and disadvantages. Hence, when cloud was invented in 2008, at that time dimensions of cloud is limited. As well as users of cloud are also in limit. At that time role based ACL was applied to control access and provide security to the user’s stored data. After that distributed role based ACL was deployed. As nature of cloud storage servers are distributed. For maintain ing truthfulness of data in this environment distributed role based ACL was used. As dimensions of cloud are increasing day by day, mechanism of DRB ACL needs to be updated. Hence Cloud optimized ACL was Developed and deployed in cloud environment. Th is technique resolves the problem of cross domain authentication by providing three levels of authentication. Although this technique is not secure enough for maintain ing truthfulness of data by preventing random access of data, it is time consuming.

The response time to user’s request was more. Hence, researchers have thought of some other parameter that should be added to RBA C model in order to achieve goal of ACL. So that design of trust and role based ACL was suggested by wenhui wang et. al[20]. Analy zing access request based on trust model is not a feasible solution for cloud environment. As TRBAC A CL is using one additional entity named trust verifier for evaluating requestor’s trust value. Access permission is granted to the users having valid trust value. This system is not secure if we think about the situation where trust verifier is of malicious nature then it would let whole ACL mechanis m down. So to resolve this attribute based ACL is deployed. All this techniques are discussed in following section. To update ACL mechanis m in cloud environment and to make cloud more secure this is a peak time to study all previous techniques. Hence the aim o f this paper is to target and resolve limitation and security loopholes of each of ACL techniques deployed in cloud environment. In today’s scenario, total numbers of cloud users have increased; new attacks are increasing day by day, so there is a need to analyze existing system and to discover hidden facts, which were not analyzed previously. Section II contains related work to describe and analyze different ACL mechanis ms, Section III presents comparative analysis of each of ACL and at the end Section IV carries future work and Conclusion.

2. Related Work:

This section provides an overview of the all A CL models designed for cloud environment. A rationale of each of them is discussed here. This will be helpfu l to all of them who are not aware of access control approaches. All the ACL models discussed below are presented in increasing order of their functionality. Rationale includes the relation between permission assignment and separation of duties. Any organization deploys access control mechanisms to mit igate the risks of unauthorized access to their data, resources and systems. In short, increasing complex data access and sharing requirements drive the need for increasingly co mplex access control models and mechanis ms [3].

2.1 Role Based Access control [RBAC]:

In this model access is granted on basis of the role of the user. The entire user’s requests are evaluated on the basis of their roles. If user is having a valid role to which access is granted then and then permission to access the resource is given otherwise denied. So, that if user is having valid role then access permission is given. Sandhu[13] has classified this RBA C in many types. One type is hierarchical role based access control. This policy says that if user is having one role and this single role if engaged with many resources then accesses to all those resources are accessible as a part of hierarchy of roles. This model has divided access grant in to two parts one is the mapping of user to role and second one is mapping ro le to permission. Performance of whole system lies on the nature of mapping between user to role and then to permission.

RH -

Constraints

Role

Hierarc

hy

User

Permissio

n

Assignment

Assignme

P

U

R

User

Role

Permis

s

s

s-ions

U

P

A

A

Figure 1: General Ro le based access control model [13]

This mapping is coded in form of policy rules. To protect data from any of the unauthorized random access this mapping should be done accurately. For evaluating request of users, its role is evaluated then access permission is given. This mapping procedure is shown in above diagram 1. Th is diagram is having bi-directional cardinality between user to role and role to permission. More over this policy supports access on basis of hierarchy of ro les. Apart fro m that sandhu has shown one additional entity known constraints. This entity adds other parameter, constraints for granting data access. In addition to role checking, policy will check constraints provided by data owner for grating access. Hence this single figure 1, depicts all four category of the role based access control. Now, amongst these four categories, only hierarchical role based access control is deployed in cloud. Although, this policy is working well with cloud environ ment, still it is having one major disadvantage. This disadvantage is due to consideration of the role hierarchy. If access is granted on the basis of role hierarchy, then indirectly this policy is providing unlimited access of data to the users. Hence, this policy is not sufficient for maintain ing truthfulness of data and preventing unauthorized access. Moreover, according to the mapping of policy, one can analy ze that roles of users are to be known in advance. Second, disadvantage is that due to public nature of cloud, cross domain authentication is difficu lt. Hence, this policy can be categorized under static mapping. If some additional mechanis m is merged with this HRBAC policy then this limitat ion can be in control. This nature of policy is not good for this cloud environment. This policy was used when cloud is deployed on small scale basis, but for larger scale this will not work well. So, to overcome this limitat ion of hierarchy of role based access control next distributed access control model is distributed role based ACL.

2.2 DRBAC:

This policy had been designed by E. Freudenthal [8].Distributed role based access control policy says that, store roles and data to the same data storage server. In previous policy ro les are stored in database. At the time of authentication of user’s request, those roles are fetched from database and evaluated. According to DRBA C policy it is necessary to store roles along with the data on storage servers.

Figure 2: DRBA C model [8]

Limitation of first policy is that it is providing unlimited access of data. In addition to that for evaluating roles in cross domain, it is not working well. So, DRBA C stores roles of users along with the data on same server. In case there is a situation of cross domain authentication of role for granting access then this policy works well. In this policy, if request from any other domain arrives for data access at that time ro le of requestor will be evaluated fro m data storage server of that particular do main. Th is is shown in figure 2. As shown in diagram, there is a case of two storage server is shown. Here server S1 and

S2 is used to store user’s data. Now, to protect that data fro m the unwanted access distributed Role based access control is deployed. Moreover in this case role of users are stored along with its data on server. Over here, one user wants to access data stored at the storage server 2 and user actually belongs to storage server S1. So, before granting access to the data stored at storage server S2, role of user stored at server S1 is evaluated. If user is having valid ro le then and then access to res ource is granted otherwise it is denied. Fro m above discussion one can analyze that it’s very necessary to map role to permission and this mapping is designed in form of access policy rules for managing access based on role of a user. To better understand this user to role and role to permission mapping follo wing diagram is shown below: By analyzing policy one can understands that although this policy deals well with distributed environment, it is not used widely. In addition to that one major disadvantage of this policy is that although role is evaluated from other storage server S1 but mapping of role to permission is not stronger enough for granting access. With this limitation, DRBA C is not considered as an efficient ACL model for cloud environment. To overcome this limitation, researchers have decided to add more levels for authenticating user and use RBAC model for granting access.

2.3 CoRBAC:

CoRBA C model is designed by Zhu Tianyi et. al[21]. In previous model, because of data and services both are gathered on the same cloud, the DRBAC model faces a problem o f management of user’s identity. Hence to solve this new ACL model is co mbination of DRBA C and RBAC model. CoRBA C inherits dRBA C’s domain and the new condition exp ressions and isolating the different enterprise and organization, maintain ing good scalability without losing efficiency [8]. To overcome the limitation of DRBA C, this model uses 3 level of authentication. This whole follow is shown below in figure 3. According to this policy, at first level certificate of user is directly issued and at this stage domain of user is not known. At second level CA authority issues a certificate without the intervention of third party.

Figure 3: CoRBA C model [21]

Hence this model overcomes the limitation of both the DRBA C and RBA C models, by providing 2-3 level of authentication. For accessing mu ltiple services DRBA C forces users to do re-login as a part of a secure authentication. This policy works well for cloud environment but is having some limitation like higher response time. Once the request is send then it will take time to do authentication. Hence response time is more in this policy. To overcome the limitation of this model, another parameter called Trust is added and then on basis of trust and us er’s role access grant is assigned.

2.4 TRBAC:

Today, the problem of trusting cloud computing is a paramount concern for most enterprises. Whether user behavior is trusted and how to evaluate user’s behav ior trust are important research contents in cloud computing [20]. It has been noticed that to prevent data from unauthorized access, behavior of user should be analyzed. More over if this trust parameter is considered and merged with RBAC model for granting access then limitat ion of previous model can be nullified. Hence, for adding this parameter one new entity named Trust verifier is used. If user’s is having valid trust value then user’s role is mapped with that higher trust value and access permission is given.

has static evaluation of trust. So, if Trust verifier entity is of malicious nature then it will let whole TRBA C scheme down. To control unlimited access to the resources attributes and some distinct fields are combined with this Hierarch ical RBA C. Hence, if attributes and hierarchy of roles are combined then it will be beneficial for provid ing access. In particular, the access control models today are mostly static and coarsely grained and not well suited for the service oriented environments like Cloud. So to add dynamic nature in ACL model, attributes are considered. These attributes are distinct fields like Environ ment, subject and object constraints. For considering these additional parameters to grant access one needs to add an intermediate entity named attribute interface for managing access rights.

Figure 4: TRBAC model [20]

One major d isadvantage of this model is that, if trust verifier is of malicious nature then it will let whole ACL model’s performance down. Moreover, this model is appropriate when size of cloud is small, but when size is larger than this is not a feasible solution to be deployed. On other hand, this model will identify users having malicious nature and prevents data access from them. Overall performance statistic is limited to the small size cloud environment.

2.5 ABAC:

Figure 5: General model of ARBA C [3][7]

These rules are coded in form of policy ru les. As attributes of user’s as well resources are stored in database. Hence, if attributes are considered not role then user will not have unlimited access. ABAC model suits well for today’s environment. As decision is taken by considering the attributes, this policy peruses dynamic nature. Hence, all the attributes are not known in advance it will be beneficial if deployed in cloud environment.

Wenhui Wang

et. al[20]

had added Trust based

evaluation to role based ACL approach. Previous model

Parameters

Nature

Rounds

Cross

Response

Parameters Upon wh ich access policy

Of

of

Do main

Time

depends

ACL

Policy

Authentication

Access

Models

RBAC

Static

Single

NOT

Moderate

Depends upon the size of cloud and Roles

Allowed

to be considered

DRBA C

Static

Twice

Allowed

High

Depends upon the size of cloud

CoRBA C

Static

Thrice

Allowed

High

Depends upon the size of cloud

TRBAC

Dynamic

Single

Allowed

Moderate

Depends upon the size of cloud and nature

of Trust verifier Entity

ABAC

Dynamic

Single

Allowed

Moderate

Depends upon the size of cloud and

attributes to be considered

Table 1: Comparative Analysis of ACL models

3. Performance Analysis:

This paper presents a survey of ACL models deployed in cloud environment. In previous section, brief introduction and characteristics of each ACL model is discussed. Now, this section represents the performance analysis of them. Above table shows the parameters upon which one can analyze all ACL models. Above parameters don’t pursue much importance, but one cannot ignore these small parameters of ACL models. On the other hand, performance of ACL can be measured in terms of its response time and on basis of time and space complexity. Moreover, one can do performance analysis on basis of conceptual categorization of A CL model. Over here, general analysis is done.

4. Conclusion:

This paper proposes a study on access control model used in cloud environment. This s urvey paper presents all relevant informat ion necessary to understand need of an ACL model and workflow of them. Th is informat ion is helpful for understanding the limitations of current security mechanisms for maintain ing intactness of user’s stored data. In future one can work on limitations of each of them by revising policy rules or by merging two different policies for resolving current issues by ACL model.