PolicyDSL: A Model-Driven Approach for the Definition and Enforcement of Access Control Policies

Access control is a fundamental concern in software systems, playing a crucial role in protecting resources from unauthorized access. As data-driven applications continue to grow and development environments become more distributed, robust and flexible authorization mechanisms are increasingly important. In practice, access control in data-driven applications is often implemented at the code level. Modern applications also require consistent enforcement across both back-end and UI layers.

Also, existing model-driven approaches (e.g., SecureUML, IFML) address either authorization or UI modeling, but not unified multi-layer policy specification and enforcement.  Fine-grained multi-layer access control remains under-explored in model-driven engineering. Low-Code and No-Code (LCNC) platforms are a new style of model-driven development. Despite their popularity and impressive code-generation capabilities, they also show the same limitations. Commercial low-code platforms (e.g., OutSystems and Mendix) provide access control features, but their granularity and integration across UI and data layers vary.

We propose a unified model-driven approach for specifying and enforcing access control across the core application layers within the BESSER low-code framework. To this purpose, we introduce PolicyDSL, a platform-independent metamodel for defining fine-grained policies over both data and GUI elements in a single specification.

Indeed, in our work (accepted at the SAM 2026 Conference), PolicyDSL goes beyond approaches that focus mainly on back-end authorization or coarse-grained UI control. It supports fine-grained access control across multiple application layers, covering elements such as screens, widgets, fields, and actions. This approach ensures consistent authorization across layers and eliminates discrepancies between data and interface behaviour. Download the full paper or keep reading for a summary.

The Pipeline: Definition and Enforcement of Fine-Grained Access Control Policies

The pipeline includes two main components:

• PolicyDSL language: an extension of B-UML (BESSER Universal Modeling Language) that incorporates a dedicated package for the specification of access control policies.
• Generation architecture: The end-to-end generation pipeline that supports the definition and enforcement of fine-grained access control policies.

Let’s see both aspects.

A brief overview of the PolicyDSL language

The DSL metamodel

As usual, at the core of the language, we have its metamodel (Figure 2). It links and reuses existing B-UML metaclasses to keep policies connected to the underlying structural and GUI models. In particular, the NamedElement concept allows policies to target both Structural and GUI elements.

Figure 2: The PolicyDSL Metamodel

The design of this metamodel is founded on three principles: (i) data- and GUI-level granularity, (ii) fine-grained permission types beyond CRUD, and (iii) separation of concerns between Policy, Structural, and GUI models.

PolicyDSL defines policies through subjects (users or roles), resources, permissions, optional constraints, and effects. It supports standard CRUD permissions as well as UI-specific actions such as showing, hiding, enabling, disabling, and masking elements. Multiple rules can be grouped into policies, with a deny-overrides strategy to resolve conflicts. These policies can then be enforced at both the back-end and front-end, keeping access control consistent across the generated application.

Policy Authoring: Programmatic and Natural Language Approaches

The policies cover screen-, action-, and field-level constraints. Rules can be authored in three ways.

1. Programmatic Authoring. As B-UML is the backbone of BESSER, policies can be defined in Python by instantiating metaclasses of the PolicyDSL metamodel (e.g., Role, PolicyRule, PermissionType, EffectType, Policy) and referencing Structural and GUI NamedElements. This provides full control over the definition of the rules.
2. Natural-language Authoring. The user describes the intended access rules in natural language and an LLM performs the transformation into the same metaclass instances. To make this reliable, we use a carefully engineered prompt built with standard prompt-engineering practices to extract subjects, resources, permissions, and effects. For example, “Students cannot view author email addresses” is mapped to a DENY rule for the Student role with VIEW permission over Author_email. The generated rules are validated against the metamodel and directly integrated into the existing pipeline, reducing the barrier to policy definition while preserving correctness.
3. Graphical Policy Authoring in the BESSER Web Modeling Editor. We are also integrating PolicyDSL into the BESSER Web Modeling Editor to support graphical policy specification. Users can define access policies directly on class diagram elements through an access-control panel, including roles, CRUD permissions, and field-level visibility. Policy information is stored together with the model and can then be used by the policy-aware application generator. This integration is currently under development and will be released soon.

Generation Architecture: From Policy Models to Policy-Aware Applications

As illustrated in the figure headlining this post, the architecture supports two enforcement scenarios:

1. Scenario A (back-end-first enforcement): Policies are enforced at the back-end level using a FastAPI middleware that validates incoming requests and applies authorization decisions at run-time; the resulting decisions are then propagated to the front-end.
2. Scenario B (front-end only enforcement): Policies are enforced within the front-end using a React-based policy context that dynamically adapts the user interface by hiding or disabling UI components, restricting access to screens, and masking sensitive data.

Together, these scenarios illustrate the flexibility of the approach while preserving a unified policy definition.

What makes our approach unique?

The main idea of PolicyDSL is to treat access control as a modeling concern rather than implementing it separately in application code. The approach combines:

• Unified policy specification across data and GUI elements.
• Fine-grained permissions, including CRUD and UI-level actions such as view, hide, enable, disable, and mask.
• Multi-layer enforcement, generating policy-aware back-end and front-end behaviour from the same policy specification.
• Multiple authoring options, including programmatic, natural-language, and graphical policy definition.
• Model-driven generation, where policies are transformed together with the application models into a policy-aware application.

The entire system has been built on the open-source BESSER platform, which uses B-UML to represent both Structural and GUI aspects of an application in a common modeling environment.

Running Example: Library Management Application

To demonstrate the nature of the pipeline, the approach was applied to a simplified Library Management application, with three roles: Librarian, Faculty, and Student. The system includes core entities such as Book, Library, and Author. As illustrated in Structural model (see Figure 3), a Library contains multiple Book entities, and each Book is associated with one or more Authors. The GUI model, rendered as the Book page (see Figure 4), defines the main screens, including a Book screen with CRUD operations and data binding to the Book entity. Access control requirements (see Figure 5) are defined at multiple levels: a Librarian has full permissions; a Faculty member has restricted actions and masked sensitive fields (e.g., Release date and Author email); and a Student has further restricted or hidden screen access. This example illustrates fine-grained, cross-layer access control, which is typically implemented manually and is therefore error-prone due to scattered logic across back-end and front-end components.

Figure 3: UML Class Diagram of the Library Management Structural Model

 

Figure 4: Book Page for the Library Management Application

Figure 5: Excerpt of PolicyDSL rules for the Library Management case study

The figures below show the generated UI pages for the Library Management example. For the Librarian role (see Figure 6), all fields and CRUD actions are available. In contrast, the Faculty role (see Figure 7) has restricted editing and masked sensitive attributes. Similarly, in Figure 8, sensitive data such as the Author email is masked. These variations demonstrate how a single interface dynamically adapts based on access control policies.

Figure 6: Librarian – full access (Book Page)

 

Figure 7: Faculty – restricted actions (Book Page)

 

Figure 8: Faculty – masked data (Author Page)

Evaluation & Results

We evaluated the approach on 200 policy variants covering coarse-, medium-, and fine-grained policies, covering correctness, robustness, and run-time performance. Results show correct multi-layer enforcement, robustness against adversarial inputs, and low run-time overhead across both layers.

Try It Yourself

The entire infrastructure is available as an open-source project. If you’re interested in trying our tool, check out the GitHub Repository.