![](bg3.png)
the rules in policy file into different check objects
as introduced above. These objects are stored in
cache. The operation on cloud service executes
through APIs. Before an API takes any action, it
sends a request to the policy engine to check the ac-
cess privilege and receives the result. As part of the
request, a context object which contains user informa-
tion, project information and the action is also sent.
3.2 Nova Policy Logic
In OpenStack, policy is composed by lines of rules.
Each rule contains a string of resource and action,
followed by a rule check. Policy engine looks for
the resource and action string, then perform the re-
quest validation against rule check. The rule check
uses name-value pairs, “and” and “or” logics. The
rule check has three kinds of checks. First two are:
1) “@” or an empty rule means accept all the access;
2) “!” means reject all the access. The third one is
the most common check. It can be expressed in two
forms: a list of lists, or a policy language string. For
the list of lists expression, the innermost lists combine
with “and” logic, and then with “or” logic. The pol-
icy language is similar with list of lists, but with one
more logic of “not” operator(OpenStack, 2013a).
3.3 Problem Area
In the time of cloud, open and sharing, users’ data,
even their infrastructure are shifting from private,
self-owned to public, third party stored. Information
security and protection are never more vital than now.
OpenStack provides a basic functioned access control
method, it can be easy to handle some requirements
of authorization. However, there are still some issues
we found that needs improvements on.
1. Flexibility of access control. OpenStacks
JSON based access control module still cannot com-
pare with XACML access control, which has a so-
phisticated logic of policy validation. OpenStack’s
access control policy language faces a lot of limita-
tions when compared with XACML language. Spe-
cially, XACML version 3 brings more useful features
and combining algorithms.
2. Modification of policy file. If an administra-
tor wants to modify the access privileges for users, he
has to, at first, change the policy file and then restart
the cloud services to reload the policy files in order to
make the effect. Because when cloud service starts,
they load the policy files in the cache, even the pol-
icy file is changed, the policy in cache is still the
same. However, the policy engine provides a method
to reload the policy file, but could not find that there
is a mechanism to call this method. This brings the
trouble that every time policy file changes, the service
will have to restart. That could further affect stability
of cloud services.
3. Policy files management. Each service has its
specific policy file in the installation folder. It is a
challenge for admin to universally manage the access
privileges. Like explained, if an administrator makes
adjustments to the access privileges for a user role,
then he needs to visit each services installation folder,
modify the policy files and restart all the services.
That brings extra workload, and difficulty with the
management of OpenStack access control policies.
4. Security issue of policy files in OpenStack.
Keystone, Nova and all other cloud services simply
put access control files into one JSON file, which is
stored in the installation folder. They are susceptible
to all the users who can visit this folder. This con-
stitutes a security issue and brings risks to the access
control module.
4 ACCESS CONTROL WITH
XACML
XACML, eXtensible Access Control Markup Lan-
guage, an XML implemented access control lan-
guage specified by Organization for the Advancement
of Structured Information Standards (OASIS)(Erik,
2012). It is the one of most popular and widely used
access control standard, and OASIS XACML Techni-
cal Committee includes member from Oracle, IBM,
Cisco, etc.
The advantages of XACML are, firstly, its sim-
plicity and strength which make it suitable for numer-
ous environments. Specially, its independence from
implementation could be utilized in cloud comput-
ing and cloud federation; Secondly, XACML’s RBAC
profile well supports RBAC function and due to the
large and well-adopted XML ecosystem, XACML is
the one of the best RBAC and policy based autho-
rization method; Moreover, compared with IBM’s
Enterprise Privacy Authorization Language (EPAL),
XACML has more features on complex enterprise
policies and is better standardized and implemented
(Anderson, 2005).
This standard defines both policy language and
request/response language. They express the access
control policies, the queries and the answers of the
queries. In the policies, XACML specifies three main
parts, such as PolicySet, Policy, Rule. PolicySet is the
root of other PolicySets or Policies, and Policy could
contain multiple Rules. One Rule in policy is the min-
imum unit of policy check, could return results: per-
EnhanceOpenStackAccessControlviaPolicyEnforcementBasedonXACML
285