2010 CRC PhD Student Conference
Merging Veriﬁable and Evolving Access Control Properties
Supervisors Dr Charles B. Haley, C.B.Haley@open.ac.uk
Dr Yijun Yu, Y.Yu@open.ac.uk
Probation viva not passed
Starting date October 2009
Recent years have seen a strong advance in formal methods for security [J¨r05]. Many success
have been obtained: many security protocols have been proved to be ﬂawed, 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
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.
Speciﬁcally, 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 deﬁned 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 conﬁdence in one’s
access control infrastructure.
2 Veriﬁcation of Access Control properties in UMLsec
The veriﬁcation process we propose is made of three diﬀerent parts: ﬁrst, we want to extend
the existing RBAC speciﬁcation 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 speciﬁcation. Finally, we generate code that conforms to the access control property that
has previously been deﬁned and veriﬁed.
Page 55 of 125
2010 CRC PhD Student Conference
2.1 Extending the UMLsec speciﬁcation 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.
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 deﬁned on one or
several activity diagrams.
Other approaches have been proposed to model RBAC permissions on UML models, like Se-
cureUML [LBD02]. SecureUML diﬀers from UMLsec as it focuses on RBAC only. The way RBAC
properties are represented is also diﬀerent: 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 conﬁguration ﬁles, can also be generated from a SecureUML model.
2.2 Verifying a UMLsec property
Once the UMLsec property has been deﬁned, 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. Veriﬁcation of the enforcement of the access control
deﬁnition 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 deﬁnition 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 speciﬁcation
Once access control permissions have been deﬁned for a model using UMLsec, we want to
generate code that actually enforces those. We compared two diﬀerent code generation approaches
from the existing RBAC UMLsec property. The ﬁrst 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 oﬀer the possibility to generate code for other frameworks as well.
3 Merging conﬂicting access control properties
An interesting case of evolution of a software system is merging conﬂicting 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. Conﬂicting deﬁnition of roles are likely to arise, as well as conﬂicting
Page 56 of 125
2010 CRC PhD Student Conference
Figure 1: Merging access control properties
constraints and assignations. We want to give developers the opportunity to identify possible
Assuming that we have two diﬀerent access control properties deﬁned using UMLsec on the
same model. If we can verify that the model enforces both deﬁnitions individually, then we want
to merge those two deﬁnitions, raise possible conﬂicts to the user, and, once those conﬂicts have
been resolved, the resulting access control will also be enforced by the model. This process is
described in ﬁgure 1.
[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.
[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
[jaa01] Jaas tutorials, 2001. http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/ tutori-
als/index.html (Last accessed September 2009).
u Jan J¨rjens.
u Umlsec tool, 2004. Published at
http://mcs.open.ac.uk/jj2924/umlsectool/index.html (Accessed Sept. 2008).
u Jan J¨rjens. Secure Systems Development with UML. Springer-Verlag, 2005.
[LBD02] Torsten Lodderstedt, David Basin, and J¨rgen Doser. Secureuml: A uml-based mod-
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 uniﬁed standard. In Proceedings of the ﬁfth ACM workshop on Role-based
access control, pages 47–63, 2000.
Page 57 of 125