the authorization 3-tuple <Subject, Privilege, Object>expanded to 5-tuple < Issuer, [User|Role], privilege, interface,ObjectPath > which are explained as follows: Issuer definesthat the User | Role has sufficient privilege on ObjectPath viainterface.Also for assigning the membership of user to a role andsupporting hRBAC, the tripe <Issuer,[User|Role], roleName>has been defined which explained as: Issuer defines that theUser | Role is responsible for the role/sub-role with role name.Therefore, the organizations define their access controlpolicies to their own resources on cloud, by these 5 and 3tuples .Chen Danwei and associates offered access controlarchitecture according to usage control model (UCON) forcloud computing. The majority of this paper is a negotiationmodule in authorization architecture to improve the flexibilityof access control on cloud services. When the requested accesshas not sufficient attributes, a second access choice via anegotiation module will provide, rather than of refusing accessdirectly .The general scenario of access control UCON modeldefined by three specifications in Fig.2. This scenario, dividesthe usage control in three phases: before usage, ongoing usage,and after usage. Decision-making control components(Authorization, Obligations and Conditions) can check andenforce in first two phases . Obligations will notconsider on after usage phase in Core UCON Model, but inpapers  post-obligation are extended for Core UCONModel. In this paper we use the extended model of UCON.UCON is a session based access control model, because itcontrols not only access request, but also the ongoing access.Mutability means that the attributes of objects or subjects canbe updated as a result of an access. There are three types of updates: pre-update, on-update and post-update. Updating theattribute of an object or subject may result in to allow orrevoke current access or another access, according to theauthorizations of the access .
Figure 1. UCON scenario 
There are three main actors in cloud environment: user,vendor and original cloud provider which will consider astenant, service vendor and service creator, respectively. Tenantis an organization that rent the cloud from cloud servicevendors and it can have users.The cloud vendor is an organization that offers the cloudservices to the cloud user with guaranteed quality of experience (QoE) and quality of service (QoS) within theframework of a service level agreement (SLA). Service creatoris a developer service organization which provides access fortenants’ users to its services via service vendors.III.
HE PROPOSED THREE
LAYER ACCESS CONTROL
In the cloud environment, service creators usually defineaccess control policies of end users to a cloud service.However, tenants usually tend to have the most possiblecontrol on their data and be able to enforce more policies thanby the service creators on their access request of their endusers. In addition, vendors tend to offer their services toconsumers in all desired levels. Therefore, cloud accesscontrol mechanism must be able to support these threerequirements. As a result, in this paper; a three-layerarchitecture is proposed for decision and enforcement of access control policies. the layers are as follow:
: as an enforcer of service access controlpolicies.
: as an enforcer of vendor accesscontrol policies.
: as an enforcer of service consumeraccess control policies.
Figure 2. The enforcement of three layers access control on user’s objects
In the service layer, it has been guaranteed that serviceobjects will be available for end users, according to creatoraccess policies. The service creator specifies these policiesbased on a business logic, which is related to that service. Forexample, in a healthcare service, the service creator willdetermine rights of the
role. In this layer, creatorsassign the first limits of the access rights of a cloud service.Therefore, these policies specify the maximum rights of otherlayers.In the provider layer, a service vendor can offer its serviceto its tenants in various levels. Some of service usage contractsare enforced by access control policies in this layer. Vendorsdefine access rights of their tenants. For example, hospital Acan rent a healthcare service only for its laboratory, whilehospital B not only want to rent the laboratory, but also forprescription and diagnosis sections. Therefore, further thancreator layer policy limitations, more policy enforcement ispossible. Hence, more limitations are enforced than servicelayer.In the tenant layer, organizations can enforce morepolicies to the previous layers. Then the least privilegeprinciple can be applied for all their users and objects in a
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 10, No. 1, January 201249http://sites.google.com/site/ijcsis/ISSN 1947-5500