2009 Third International Conference on Emerging Security Information, Systems and Technologies

Generation of Role Based Access Control Security Policies

for Java Collaborative Applications

J. Briffaut, X. Kauffmann-Tourkestansky, J.-F. Lalande W. W. Smari

ENSI de Bourges, LIFO — EA 4022 Electrical and Computer Engineering Department
88 Bld Lahitolle University of Dayton
18020 Bourges Cedex, France Dayton, Ohio 45469 USA
Email: {jeremy.briffaut,xavier.kauffmann- [email protected]
tourkestansky,jean-francois.lalande}@ensi-bourges.fr

Abstract—Java collaborative applications are increasingly and In current Java virtual machines, different security tools
widely used in the form of applets or servlets, as a way to easily are provided [1-3]. This paper will use the Java
download and execute small programs on one’s computer. Authentication and Authorization Service (JAAS) module.
However, security associated with these downloaded Even though this module provides numerous facilities to
applications, even if it exists, is not easily manageable. Most of control the executed code, this work will show that the use of
the time, it relies on the user's ability to define a security policy JAAS is difficult in real collaborative systems.
for his virtual machine, which is undesirable. This paper This paper is organized as follows. In the next
proposes to integrate an RBAC mechanism for any Java subsections, we discuss key ideas necessary for the solution
application. It introduces a simple tag process that allows the
design as well as objectives of this work. Section 2 outlines
developer to incorporate the appropriate policy in the source
the design and implementation of the RBAC based solution.
code of his application. The user is endowed with the ability to
choose a role that corresponds to the required level of trust Section 3 presents the details of how to adapt the solution for
required in order for him to embed the policy in the executed collaborative environments and applications. A case study
code. A case study of a collaborative application shows how that demonstrates how the implementation will work and
works the proposed API for managing roles, generating what happens in case of permission violation attempts is
policies and logging in. At the end, a discussion about the described in Section 4. Before concluding the paper in
dynamic enforcement of the generated policies is presented. Section 6, we address another important aspect of code
security: how to dynamically enforce security policies to
Keywords—RBAC; java; collaborative applications limit unnecessary permissions and thus increase application
security.
I. INTRODUCTION A. RBAC Access Management
The Role Based Access Control (RBAC) model [4] is
This paper deals with the security of a Java application widely used to enforce security between users and objects of
that a user wishes to execute. The user or several users, in a system. On operating systems, the most well-known
the case of collaborative applications, are supposed to implementations are RSBAC [5], grsecurity [6] and SELinux
execute some codes that they do not trust completely. This [7]. With an RBAC policy, the administrator has to define
could be a downloaded application or an application that roles that have certain permissions on types. These types are
could endanger the system or its data. labels that are applied on all objects of the system. The main
It is assumed that the developer that coded the drawbacks of the current implementations in modern
application is also responsible of the security policy operating systems are:
associated with the code. Furthermore, we assume that the • The administrator has to know precisely how the
user has access to the source code. If not, the proposed software works and what permissions are needed on
solution may be run by the developer in order to produce the system's objects.
policy. But to simplify the work, we suppose that the user • A user cannot change the policy he wishes to apply
has access to the code. to a particular software he wants to use, as the
The third role that is considered is the administrator of administrator has already defined the role and the
the user's computer system. He could be responsible of permissions associated to this role.
installing the software on the user's computer and possibly in These drawbacks and the difficulty to configure
charge of the security policy and maintenance of these mandatory access control mechanisms are prohibitive for a
computers. Additionally, the administrator could be in user who wants to test untrusted software. A lightweight
charge of deploying software for several users, and would solution could consist of using JAAS in order to restrict
like to provide them different levels of security to execute permissions at the level of the virtual machine.
the application.

978-0-7695-3668-2/09 $25.00 © 2009 IEEE 224

DOI 10.1109/SECURWARE.2009.41
Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.
B. Maintaining the Integrity of the Specifications • give the software developer the ability to define
When using a java application, a system policy can be roles and types and also permissions between the
employed to control the virtual machine that executes the two.
program. However, the user likely has no sufficient • provide the end-user the ability to choose a role in
privileges and knowledge to adapt his computer’s system order to obtain the security level he wants the
policy in order to restrict the permissions of the role he uses software to be run at.
to execute the application. This justifies the use of JAAS, The proposed solution will bring an access control API
which is the core security component that enables the user to that automatically:
add permission rules applied by the virtual machine. • deploys the policy into the java application.
The JAAS rules do not use the concept of roles and • eases the role switching when accessing the
types. Rather, permissions are directly assigned to a user
application.
identity on an object of the system. For example, a read
permission on config.txt is made using the following rule: • restricts the given permissions of a given tagged
part of the code using role transitions.
grant Principal test.JAAS.ExamplePrincipal “user”
{permission java.io.FilePermission "config.txt", "read";} II. RBAC INTEGRATION IN JAVA

The consequences are the following: A. Developer Facilities

• The user gains control of the software that he runs. Our goal is to enable the developer to create several sets
He can precisely define permissions dealing with of permissions for different roles within his application.
objects the software may target. These permissions will then be linked to a role as defined in
• The user must know in advance what is needed by the RBAC model. The end-user that downloads this
the software he wishes to run. For example, what application will be able to use it with a fine grained set of
objects are read or written? What socket will be
restrictions and will not have to choose between executing
created on what URI? Is the software allowed to
overwrite the methods used for objects the application in admin mode that could endanger his
serialization? computer or no execution at all. The developer will have
This is really a difficult task for the user that justifies the given him the opportunity to use the Java Security Manager
need for an automatic generation of the final JAAS policy with a custom policy file in order to safely execute the
with more understandable high level concepts. application.
To avoid asking the end-user to define the policy, we In the case of collaborative applications, it would then
propose to delegate to the software developer the ability to fall on to an administrator to manage which role will be
specify the policy rules using special tags in the comments of assigned to a user.
the application’s source code. This implies that the end-user
should trust the developer about the correctness of these B. Tagging Grammar and Syntax
rules, since they will generate the final policy that will Some information is required to create the policy file.
control the application. The end-user will still have the Only the developer or programmer is able to know what
possibility to check and modify the final policy, which is security level his application might require. Thus, the best
extracted from the source code, but the goal is to simplify way to accomplish this task is to include within the code
this task to the end-user and to make the notion of roles itself the information needed to generate the policy of the
available to him. whole software. The location of the information is easy to
If the software is used by multiple users, an administrator incorporate as a Javadoc comment incorporating tags: it is
could be in charge of the application’s policy management left at the developer's discretion and is close to the
for each user [8]. With JAAS current implementation, the commented code.
administrator has to define one policy file for each user. This The syntax of the tag should be as clear and simple as
approach duplicates the rules and requires more work to
possible meaning that the syntax should be security-oriented
maintain those files. Using the notion of roles, already
but user-friendly so as to be as easily added by the
introduced for java collaborative application in [9, 10], this
paper proposes to aggregate the permissions and to assign a developer. Moreover the tag will have to be extracted and
set of roles to each user. Then, at execution time, the user processed which require that the used grammar should be as
will be able to choose his preferred role. generic as possible.
We have therefore chosen to translate the SELinux syntax
C. Objectives of the Study into a Java annotation syntax taking into account all the
The preceding sections lead us to propose the integration elements needed to write permissions into a security policy
of RBAC in all Java applications and to identify a file.
conceptual methodology in order to integrate its RBAC • The type of permission
policy. This conceptual methodology must: • Its name
• Its actions

225

Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.
 From a grammatical point of view, the SELinux syntax
defines that a subject process is allowed to interact with the
permissions precised in <IT> with some objects of the
system:

allow <subject> <IT> <object>

The selected Java annotation syntax for the incorporated

tag is somehow different. We have based ourselves on the
SELinux grammar which is rather natural and user-friendly
but added the type, name and actions of a permission in
order to match the Java security grammar. The syntax of a
Figure 2. JAAS Login Module
security rule is the following:

/** processing step involving a database. For example, for the

* @allowIT role {permissions} “objects” */ following tags found on functions:

The following example shows cases of permission tags /**

where all or only some of the parameters are needed. * @allowIT Root {file:(read);file:(write)} "config.txt" */
public void convertConfiguration()
...
/**
/*
* @allowIT Root {all}
* @allowIT Root {file:(read);} "password.txt" */
* @allowIT User{awt} "accessClipboard"
public void authenticate(String password)
* @allowIT User{file:(read);file:(write)} "config.txt" */
...

In this example the root user have all types of possible The parser will populate the database and produce the
permissions. The user role has access to the clipboard object following policy file:
with awt operations and has also read and write permissions
on the config.txt file. grant Principal test.JAAS.ExamplePrincipal "Root" {
permission java.io.FilePermission "config.txt", "read";
C. JAAS Policy Generation permission java.io.FilePermission "config.txt", "write";
Once the permission information has been incorporated permission java.io.FilePermission "password.txt", "read";};
in the application’s code by the developer, it has to be D. RBAC Integration API
extracted gathered and processed in order to generate the
policy file. To do so we have chosen to create a parser that 1) Login System : From the perspective that several
would: users will be using the same application, for example in
• Locate all customized JavaDoc tags in a Java collaborative applications, we might want to authenticate
source code file. the users and give them a role defined by the developer.
• Fill a database that will have to be processed. In the implementation, we have considered that a Login
• Write the policy. Module would be appropriate. Figure 2 shows the JAAS
Since the application is likely to consist of several classes Login Module architecture and mechanism. The module
and therefore several Java source code files, the parser will will use JAAS in order to load the right policy in the virtual
have to take it into account. machine. When used, the login module will propose to the
Figure 1 shows the process of extracting tags from a user to be assigned to a role. This role will protect his
project and parsing them into a new policy file after a computer’s resources from the code itself since the access
has been restricted compared to the admin mode.
2) Role Management: The entities that will deal with
role permissions are not only the developer and the users. It
is needed to introduce a supervisor or administrator that will
write a user/role file where the relation between the two will
be expressed.
This administrator can be a user or the developer itself as
long as it does not compromise the security integrity of the
whole architecture. Figure 3 sum-up the generation process
of the user/role file and Figure 4 shows how multiple users
Figure 1. Parser and File Loader Architecture will obtain a role using the JAAS login module in order to
access to the application.

226

Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.
 policy for the JSM; he will then be able to use the Java
SandBox mechanism in order to execute the code with the
minimal but needed permissions. Figure 5 represents the
sandboxing with a rectangle that contains and isolates the
application.
B. User Authentication
With the proposed solution, the developer will be able to
write a security policy enforced by the JSM that will enable
access restriction for the users. Using the JAAS Login
Module, the user will be authenticated and will obtain one
of the roles before executing the code controlled by JSM.
Figure 3. Java Collaborative Application with RBAC Implementation Figure 5 shows the access of three users to the application
that have to choose a role before being able to execute the
code.
C. Developer Policy Definition
The most noticeable contribution to Java collaborative
applications remains that developers can add security to
their application independently one from the other.
Supposing that two modules of a same application are
developed and tagged separately by two different
developers, the parser can generate a policy file for the
whole application from the source code files of the two
modules. The only restriction is that the developers have to
be coordinated on the name of the roles they use. A solution
could be to impose the developer to use a preset of roles;
nevertheless, he is allowed to create new roles that can be
Figure 4. User File Editor
used by the administrator in order to give special restricted
access.
After having explained how the main modules of our This coordination could be ensured by the administrator.
solution work, the next section shows how to integrate the The administrator will also be in charge of assigning a
solution into a large scale application with the example of a subset of roles for each user of the application. The figure 5
collaborative Java application. Moreover, the section sum-up the administrative aspects of the proposed solution.
presents how RBAC implementation can be used for these
kinds of applications. In this section, we have presented how can be used the
proposed solution in the case of a collaborative application.
In the next section, a case study will be detailed with the
III. COLLABORATIVE APPLICATIONS generated policies and their effect on a standard execution.
For Java collaborative applications, dealing with several
users may be a problem. Since there is no way to dispatch
rights between them or to restrict them from using the
application, there is a real security issue. From the
administrative point of view, the solution helps in several
ways:
• It eases the security policy generation;
• It allows sandboxing the application;
• It adds an authentication security level before using
the application;
• Its simplifies the writing of policies for developers.
A. Sandboxing
The parser which is a module from the solution can also
be used from the user end. Provided that the code has been
tagged by the developer, the user will be able to run the Figure 5. Security Solution for Java Collaborative Applications
code through the parser which will give him a security

227

Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.
 IV. A CASE STUDY Authentication succeeded!!

This section focuses on a simple example with two roles Please pick a role:
---- >Root
used in an application. We shows how works the Login Role pick succeeded.
module in the console and what happens if the user tries to
overcome the permissions of the role. Actions done once authenticated..........
The file exists in the current working directory
A. Login Module the file has been read!
The file config.txt was created (write test)!

The next listing shows the case of a user that logs with
the User role. The JSM throws a security exception and the
application is not able to write into the text file.

Password linked to the username in the userfile:

a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
Hash of the inputed password :
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
Authentication succeeded!!

Please pick a role :

---- >User
Role pick succeeded.

Figure 6. Java Test Application Case Study Actions done once authenticated..........
The file exists in the current working directory
the file has been read!
java.security.AccessControlException: access denied
Figure 6 shows the three steps of a test case application: (java.io.FilePermission config.txt write)
the policy file generated with the parser from the tags in the
source code file of the application is loaded into the JSM.
The user then logs in with his username and password and V. DYNAMIC ENFORCEMENT OF POLICIES
chooses a role. Users are managed using the User File
The described methodology allows to generate the whole
Editor. The application then runs with the permissions
policy file corresponding to the tags that the developer adds
associated with the role.
to the code. Recall the following example:
B. Several Users/Roles
/**
The console output of the application will show what * @allowIT Root {file:(read);file:(write)} "config.txt" */
happens when the following permissions are loaded into the public void convertConfiguration()
JSM. These permissions come from a specific policy file ...
/*
that was generated using the parser from our solution. * @allowIT Root {file:(read);} "password.txt" */
public void authenticate(String password)
grant Principal test.JAAS.ExamplePrincipal "Root" { ...
permission java.io.FilePermission "config.txt", "read";
permission java.io.FilePermission "config.txt", "write";
};
The produced policy file will gives the read and write
grant Principal test.JAAS.ExamplePrincipal "User" { access on config.txt and a read access on password.txt.
permission java.io.FilePermission "config.txt", "read"; When enforced in JAAS, any code in the software will be
}; able to write config.txt. This is because the login module of
the proposed solution loads the policy file associated to the
We obtained the two following cases logging with two root role when the user choose this role. This way, the
users and choosing different roles. The policy file indicates method authenticate() will obtain the permission to read
that the role rsoot has the right to read and write into the password.txt but will also have the permission to write the
config.txt text file whereas User only has the right to read it file config.txt, which is useless for this method. This
but not write into it. example shows that, when executing a method, there is
The next listing shows the case of a user that logs with more permissions than needed to execute it.
the Root role and is able to read and write into the file The proposed solution is the following: when a method
config.txt. is executed, a special policy has to be loaded in the JAAS
Password linked to the username in the userfile:
module. This policy corresponds exactly to the policy
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 tagged by the developer. If the methods
Hash of the inputed password : convertConfiguration() calls the method authenticate(),
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

228

Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.
when authenticate() is executed, the code have to unload the user to choose a role in order to obtain the required level of
current policy of JAAS (the policy for trust required so that he is able to insert the security policy
convertConfiguration()), then load the policy for in the application. The policy is automatically generated
authenticate() giving only the permission of reading from the user perspective and a methodology that allows for
password.txt. Then, when authenticate() finishes and returns the dynamic enforcement of the policy for each method of
to convertConfiguration(), the policy corresponding to this the code was also presented. A case study and examples
function have to be reloaded. show that this approach does provide a more robust security
In order to achieve this mechanism, the code of the measure for Java based collaborative applications.
application has to be patched at each entry and exit point of The next challenges for this work are several. First, how
the functions that have special policy tags. Each role can be to make it possible for the user to analyze the policy
declined into subroles that have only a subset of permission. implemented by the developer. For example, a “malicious”
In this example, the root role is derivated in: developer could propose a permission that is not really
• root_convertConfiguration, that has read and write needed by the code, hence weakening the security.
permissions on config.txt. Moreover, a standard policy elaborated by the user could be
• root_authenticate that has only read permission on compared to the policy written by the developer. The
password.txt. comparison could help the user to decide whether the
The introduced patch just automatically change of role developer's policy is similar or totally different. This could
from root to root_convertConfig when entering the provide vital indication to the user about the level of trust he
convertConfig() method. This process is really similar to can associate to the policy's developer.
dynamic and automatic transition in SELinux. It can be
achieved as shown in the following listing: REFERENCES
[1] S. Oaks, “Java Security”, 2nd Edition, O’Reilly & Associates, Inc.,
/** Sebastopol, California, USA, 1998.
* @allowIT Root {file:(read);file:(write)} "config.txt" */ [2] Sun Microsystems, Inc., “Java security overview”, White Paper, April
public void convertConfiguration() { 2005, Santa Clara, California, USA.
RBAC.loadPolicy("root_convertConfiguration"); [3] L. Gong, G. Ellison, and M. Dageforde, “Inside Java™ 2 Platform
RBAC.unloadPolicy("root_convertConfiguration"); Security: Architecture, API Design, and Implementation”, 2nd
} Edition, Prentice Hall, O’Reilly & Associates, Inc., Sebastopol,
/* California, USA, 2005.
* @allowIT Root {file:(read);} "password.txt" */ [4] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman, “Role-
public void authenticate(String password) { based Access Control Models. IEEE Computer”, 29(2) : 3847, 1996.
RBAC.loadPolicy("root_authenticate");
RBAC.unloadPolicy("oot_authenticate"); [5] A. Ott, “Rule Set Based Access Control as Proposed in the
} 'Generalized Framework For Access Control' Approach In Linux.
Master Thesis, Universität Hamburg, 1997.
[6] B. Spengler, “Detection, Prevention, and Containment : A study of
This approach increases drastically the security of the Grsecurity”, in Libre Software Meeting 2002 (LSM2002), Bordeaux,
code: if a bug or an attack succeeds in interfering with that France, 2002.
application during the execution of the authenticate() [7] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen and J.
method, the perturbation is unable to access the config.txt. It Lepreau, “The Flask Security Architecture : System Support for
guarantees that each method has no more than the necessary Diverse Security Policies”. Proceedings of The Eighth USENIX
Security Symposium, Washington, D.C., USA, 1999, pp. 123-129.
permissions.
[8] M-Tech Identity Management, “Beyond Roles: A Practical Approach
to Enterprise User Provisioning”, White Paper, 2006.
VI. CONCLUSION
[9] H. Shen and P. Dewan, “Access control for collaborative
This paper discussed the possibility of increasing the environments”, In Proceedings of the ACM Conference on
security of Java based collaborative applications using role Computer-Supported Cooperative Work, Toronto, Ontario, Canada,
1992.
based policies. More specifically, it presented the
[10] W.K. Edwards, “Policies and roles in collaborative applications”, in
introduction of RBAC model as a security solution in any Proceedings of the 1996 ACM Conference on Computer Supported
collaborative Java application. The implementation allows a Cooperative Work, Boston, Massachusetts, United States, 1996.

229

Authorized licensed use limited to: Amrita School Of Engineering - Kollam. Downloaded on May 16,2025 at 11:31:51 UTC from IEEE Xplore. Restrictions apply.