Lionel Montrieux is a PhD student supervised by Dr. Charles B. Haley and Dr. Yijun Yu in the Computing Department at the Open University. His research focuses on merging verifiable and evolving access control properties. Specifically, he aims to extend UMLsec to specify more complex access control models, verify that UML models enforce access control properties, generate code from UMLsec specifications, and develop a framework to merge conflicting access control properties when systems evolve.

1. 2010 CRC PhD Student Conference
Merging Verifiable and Evolving Access Control Properties
Lionel Montrieux
L.M.C.Montrieux@open.ac.uk
Supervisors Dr Charles B. Haley, C.B.Haley@open.ac.uk
Dr Yijun Yu, Y.Yu@open.ac.uk
Department Computing
Status Full-time
Probation viva not passed
Starting date October 2009
1 Introduction
Recent years have seen a strong advance in formal methods for security [J¨r05]. Many success
u
have been obtained: many security protocols have been proved to be flawed, and many others to
be correct in a precise sense delimiting exactly their applicability.
UMLsec is an extension of UML that allows developers to waive security aspects into a standard
UML model. The UMLsec tool [J¨r04] allows them to check that their models satisfy the security
u
properties they want to enforce.
Yet, the growing demand to evolve systems continuously raises new questions and new research
opportunities. Not only is it necessary to make sure that a system meets security requirements,
but it is also crucial to make sure that those requirements are still met by the system on each
step of its constant evolution. Hence, it is necessary to develop processes and tools that help the
developers ensuring lifelong compliance to security, privacy or dependability requirements.
Specifically, access control plays an important role in protecting assets from unauthorised access.
Several access control models, like Role-Based Access Control (RBAC) [SFK00] or Organization-
Based Access Control (OrBAC) [ABB+ 03] have been defined to help administrators grant permis-
sions to users in an easy and scalable way, while allowing permission changes to be easily made.
With complex software, maintaining a sound access control infrastructure and ensuring properties
like separation of duty can become a challenge. Processes and tools that can verify such properties
against a given model as well as all of its evolutions are necessary to increase confidence in one’s
access control infrastructure.
2 Verification of Access Control properties in UMLsec
The verification process we propose is made of three different parts: first, we want to extend
the existing RBAC specification in UMLsec to allow one to specify more complex access control
properties. Then, we want to verify that a given model actually enforces the UMLsec access
control specification. Finally, we generate code that conforms to the access control property that
has previously been defined and verified.
Page 55 of 125

2. 2010 CRC PhD Student Conference
2.1 Extending the UMLsec specification of RBAC
UMLsec includes a set of properties to specify RBAC permissions, using the RBAC stereotype on
an Activity diagram [J¨r05]. However, it supports only a limited subset of the RBAC standard.
u
We want to develop it to include other levels of RBAC standard compliance, as well as other
similar access control models, like OrBAC. We also want to model authentication procedures using
UMLsec, and to allow one to automatically integrate the UMLsec property into other diagrams,
like class diagrams and sequence diagrams, once the initial property has been defined on one or
several activity diagrams.
Other approaches have been proposed to model RBAC permissions on UML models, like Se-
cureUML [LBD02]. SecureUML differs from UMLsec as it focuses on RBAC only. The way RBAC
properties are represented is also different: instead of using stereotypes and tagged values to an-
notate the model, the SecureUML approach adds classes to a class diagram to describe users,
roles and permissions, and uses OCL [OMG10] to describe additional constraints. access control
directives, like EJB configuration files, can also be generated from a SecureUML model.
2.2 Verifying a UMLsec property
Once the UMLsec property has been defined, we want to make sure that the model actually
enforces it. Not only do we want to make sure that the model doesn’t allow a user to perform
an operation s/he’s not authorised to perform, but we also want to make sure that rules like
Separation of Duty are actually enforced. Verification of the enforcement of the access control
definition by the model already exists for the current UMLsec RBAC property, but is limited to
activity diagrams. With the extended access control model that we propose come new challenges
to verify the suitability of the model. Not only will we have to verify new properties on the activity
diagram, but we will also have to verify the other diagrams of the model that may contain access
control rules: class diagrams, sequence diagrams, . . .
Since the access control definition might be spread over several diagrams, we will also have to
verify that it doesn’t contain any contradiction.
2.3 Code generation from a UMLsec specification
Once access control permissions have been defined for a model using UMLsec, we want to
generate code that actually enforces those. We compared two different code generation approaches
from the existing RBAC UMLsec property. The first one produces Object-Oriented code, while the
second one produces Aspect-Oriented code [IKL+ 97] to enforce the access control permissions,
together with Object-Oriented code for the functional code. It seems that the second solution
provides a better implementation, since the access control enforcement code is clearly separated
from the functional code. It also makes further changes to the code easier to perform, and makes
the traceability between the code and the UMLsec access control property easier to maintain.
Moreover, the current implementation only generates code for the JAAS framework [jaa01]. We
would like to offer the possibility to generate code for other frameworks as well.
3 Merging conflicting access control properties
An interesting case of evolution of a software system is merging conflicting access control prop-
erties. A example might be two companies merging, each running its own software with its own
access control properties. Rationalising the new company’s information system will imply using
only one system, with only one access control property.
We want to propose a framework, based on UMLsec, to allow one to merge several access control
properties on a given model. Conflicting definition of roles are likely to arise, as well as conflicting
Page 56 of 125

3. 2010 CRC PhD Student Conference
Figure 1: Merging access control properties
constraints and assignations. We want to give developers the opportunity to identify possible
conflicts.
Assuming that we have two different access control properties defined using UMLsec on the
same model. If we can verify that the model enforces both definitions individually, then we want
to merge those two definitions, raise possible conflicts to the user, and, once those conflicts have
been resolved, the resulting access control will also be enforced by the model. This process is
described in figure 1.
References
[ABB+ 03] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte,
A. Mi`ge, C. Saurel, and G. Trouessin. Organization Based Access Control, June 2003.
e
[IKL+ 97] John Irwin, Gregor Kiczales, John Lamping, Jean-Marc Loingtier, Chris Maeda,
Anurag Mendhekar, and Cristina Videira Lopes. Aspect-oriented programming. pro-
ceedings of the European Conference on Object-Oriented Programming (ECOOP), June
1997.
[jaa01] Jaas tutorials, 2001. http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/ tutori-
als/index.html (Last accessed September 2009).
[J¨r04]
u Jan J¨rjens.
u Umlsec tool, 2004. Published at
http://mcs.open.ac.uk/jj2924/umlsectool/index.html (Accessed Sept. 2008).
[J¨r05]
u Jan J¨rjens. Secure Systems Development with UML. Springer-Verlag, 2005.
u
[LBD02] Torsten Lodderstedt, David Basin, and J¨rgen Doser. Secureuml: A uml-based mod-
u
eling language for model-driven security, 2002.
[OMG10] OMG. Object constraint language (ocl) 2.2, February 2010.
http://www.omg.org/spec/OCL/2.2/ (last accessed May 2010).
[SFK00] R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST model for role-based access control:
towards a unified standard. In Proceedings of the fifth ACM workshop on Role-based
access control, pages 47–63, 2000.
Page 57 of 125