Security is a key aspect of any system. As such, security should also be part of any system modeling approach. We can use models to analyze security configurations (of databases, firewalls, Java EE deployments, content-management systems…). And we should also protect the models themselves from unauthorized accesses (e.g. generating secure compliant model views or watermarking). But most of these security mechanisms rely on basic Role-Based Access Control (RBAC) rules.
But in any non-trivial system, security policies go beyond simple access control rules and must cover more complex and dynamic scenarios while providing, at the same time, a fine-grained level decision-making ability. The Usage Control model (UCON) was created for this purpose. Unfortunately, so far, integration of UCON in mainstream software engineering processes has been very limited, hampering its usefulness and popularity among the software and information systems communities.
To fix this, we are now proposing a Domain-Specific Language to model UCON security policies and their integration in (model-based) development processes.Together with the language, an exploratory approach for policy evaluation and enforcement of the modeled policies via model transformations has been introduced. These contributions have been defined on top of the Eclipse Modelling Framework.
The full details of our approach can be read (open access!) in the paper: A domain-specific language for the specification of UCON policies published in the Journal of Information Security and Applications. In what follows I give you a glimpse of the UCON metamodel at the core of the DSL.
UCON metamodel
We describe the abstract syntax of our UCON DSL The top-level elements of our UCON metamodel are depicted in the following figure. The root element is the Policy metaclass, that acts as a container of the five sets of elements needed to describe access-control in our context, namely: Subjects, Objects, Rights, Rules and Environment. Subject, Object and Right represent respectively the active entity which requests access, the resource being accessed, and the concrete action to be performed with the access. Subjects and Objects may have Attributes which may be mutable or not (note that for simplicity in this version of the metamodel we consider all attributes to have basic types, such as Integer or String). The Environment metaclass is a placeholder used to store environmental and context attributes used by conditions.
Obviously, the core concept of our metamodel is that of Rule. Next figure shows the rule subset of the metamodel. Access-control decisions are described in UCON as implications, meaning that granting (or revoking) a given access implies, depending on the concrete UCON model, the fulfillment of a number of predicates and the execution of update procedures. We organize these concepts by introducing the Rule metaclass, which is not explicitly defined in UCON.
Rules refer to exact one Subject, Object and Right. Rules may require a certain number of UpdateOperations to be performed on attributes before (PreUpdateOperation), during (OnUpdateOperation) of after (PostUpdateOperation) the access is granted. Finally, concrete Rules (the Rule metaclass is abstract) imply the fulfillment of UsageDecisionFunctions.
We define 6 types of Rules : AllowRule, StopRule, ObligationAllowRule, ObligationStopRule, PreConditionAllowRule, and PreConditionStopRule. AllowRule and StopRule imply the fulfillment of a pre or continuous authorization respectively (PreAuthorizations and OnAuthorizations in the metamodel). ObligationAllowRule and ObligationStopRule imply the fulfillment of a list of pre or continuous obligations respectively (represented by the list of Obligations in the PreFulfilled and OnFulfilled UsageDecisionFunctions in the metamodel). Finally, PreConditionAllowRule and PreConditionStopRule imply complying with a list of pre or continuous environmental preconditions (represented as the lists of OnConditions and Conditions in the PreConChecked and OnConChecked UsageDecisionFunctions in the metamodel.
These rules combined with the different (valid) UpdateOperations cover all the 24 basic UCON patterns presented in the seminal UCON paper.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Recent Comments