Analyzing Action Interference of Administrative Obligations for SMT-Based Verification

Abstract

Obligations in the Next-Generation Access Control (NGAC) standard enable the development of security-intensive workflow systems where access privileges evolve over time. However, specifying obligations for dynamic access requirements poses challenges, with errors having the potential to cause significant harm to the authorization state in NGAC applications. To identify and rectify such errors, our work aims to verify obligations by translating NGAC policies into logical formulas in SMTs (Satisfiability Modulo Theories). A primary challenge lies in the formalization of procedural obligations into declarative SMT formulas, given the potential for interference among administrative actions within an obligation. To address this issue, this paper analyzes all conflicts among obligation actions and formalizes them as logical formulas for the correct SMT-based verification of obligations in NGAC policies. We implemented the approach using the cvc5 solver and applied it to real-world systems. The results illustrate the successful formalization and verification of access control requirements.

1. Introduction

Obligations associated with access privileges play a crucial role in establishing accountability and maintaining privacy, which rely on the meticulous execution of security procedures by both the system and the user [1]. While access control primarily governs authorized user access to specific resources, data, or services, it fails to guarantee the proper execution of obligatory actions. A common practice is to incorporate obligations into access control policies rather than embedding them directly into system functionality. This is exemplified in the XACML 3.0 standard [2] and its associated extension [3], the Usage Control model [4], and the Next-Generation Access Control (NGAC) standard [5].

In traditional obligation models [1,6,7,8], the system and user obligations linked to access events typically do not alter access privileges upon execution. The authorization components of access control remain immutable in the face of obligatory actions, such as sending email notifications. In contrast, NGAC integrates administrative actions within obligations to handle dynamic access control requirements that modify the authorization elements and access privileges during runtime. We refer to the collective authorization elements at a specific moment in NGAC as a “configuration,” encompassing assignment, association, and prohibition relationships among associated users, user attributes, objects, obligation attributes, and access rights. An initial configuration and a set of administrative obligations define an NGAC policy. An obligation consists of a sequence of conditional actions that modify the configuration’s assignment, association, prohibition relationships, or other elements. Access privileges are determined by applying the decision procedure to the given configuration. When a permitted access event occurs under the initial configuration, it triggers associated obligations to modify the initial configuration, thereby transforming the initial configuration into a new one. Consequent obligation-associated access events can further update this new configuration. In this way, administrative obligations enable the implementation of workflow systems with changing access privileges.

However, the specification of administrative obligations for dynamic access requirements can be complex and error-prone. The obligations can transform the initial configuration into possible configurations through different event sequences. As discussed in the NGAC standard specification, due to complex run-time configuration and privilege changes, the application of NGAC has the potential to cause “grave harm to the authorization state through error or intent” [5]. Therefore, ensuring that administrative obligations are correctly implemented to meet dynamic access requirements is very important.

To verify NGAC policies, in our prior work, we developed an approach to formalizing the access decision procedure, individual configurations, and obligations as SMT (Satisfiability Modulo Theory) formulas [9]. The obligation formalization assumes that the actions within each obligation are independent—the execution of one action will not affect other actions. In other words, it cannot capture interdependencies between actions, such that one action’s postcondition falsifies the next action’s precondition or cancels the postcondition of a preceding action. However, it is critical to accurately formalize sequences of administrative actions as SMT formulas for SMT-based verification of NGAC policies.

To address this issue, this paper presents a thorough examination of the interdependencies inherent to administrative actions and formalizes them as SMT formulas to facilitate SMT-based verification of NGAC policies. To this end, we formalize the logical preconditions and postconditions of individual actions and the conflicting conditions among administrative actions within each obligation. To our knowledge, no prior work on NGAC, ARBAC, UCON+, or any other access control model has formally studied or encoded intra-obligation dependencies in a form that is verification-capable. This is the first formal approach to verifying dynamic, obligation-driven access control policies with intra-obligation dependencies that modify the permission state at runtime. Unlike other access control verification efforts, which primarily focus on static policies or administrative policies that can be modified by administrators, our work represents a novel approach to the formal verification of obligation-enabled dynamic access control.

Specifically, our contributions include the following:

1.

A complete formalization of all built-in NGAC administrative actions, specifying precise preconditions and postconditions for each in SMT logic.

2.

The first comprehensive study of obligatory actions’ interdependencies, conflicts, and verification, a topic that was not studied in prior research. It enables SMT-based verification that supports intradependency-aware reachability analysis of complex obligations.

3.

An implementation in POMA (POlicy Machine Analyzer) [10], our open-source toolkit for visualizing, testing, and verifying NGAC policies, integrated with the cvc5 SMT solver [11].

4.

A demonstration with real-world case studies that the proposed research enables the detection of semantic errors and policy safety violations that were previously unverifiable due to the dependence on subtle interactions between sequential actions.

The remainder of this paper is organized as follows: Section 2 reviews related work. Section 3 provides the preliminaries to make the paper self-contained. Section 4 describes the SMT-based approach to NGAC policy verification. Section 5 elaborates on the interdependence analysis of administrative actions. Section 6 presents the case studies, and Section 7 concludes this paper.

2. Related Work

We review related work in the areas of obligation models, verification of administrative access control policies, and SMT-based policy verification.

2.1. Obligation Models

Traditional obligation models focus on conditional access and non-administrative tasks (e.g., sending an email), rather than administrative changes to the authorization elements. Park and Sandhu [8] introduce obligations as requirements that have to be fulfilled by the subject after access is allowed. They describe two kinds of obligations: pre-obligations and ongoing obligations. Pre-obligation is a predicate that verifies that certain activities were performed before the main activity, while ongoing is a requirement that has to be satisfied continuously. Irwin et al. [1] propose a formal metamodel for capturing a system and its possible state from the perspective of obligations, where obligations are some actions that the subject must take in the future. As these obligations are based on specific actions that the user should take but may not take, they are unenforceable (e.g., the reviewer is required to submit a review of the paper by the deadline but may not do so). While XACML provides a syntax for obligation specification, the execution and interpretation of obligations are left to the policy execution engine or application. Li et al. [3] have extended XACML to support practical obligation specification by enriching the obligation syntax and semantics. The obligations are modeled as state machines communicating with access control systems. Margheri et al. [12] present obligations as additional actions connected to the access control system that must be executed by the Policy Enforcement point and usually correspond to logging, sending a message, or executing a command (e.g., sending an email, compressing a file, etc.). The UCON+ model [13], an extension to UCON, uses obligations in session transitions represented as different phases of access: pre-, ongoing, and post-access. The obligations are represented as additional, non-administrative actions that must be performed with access decisions. Furthermore, Shopp et al. [14] present the formal specifications for the UCON+ model, which uses obligations as directives that must be carried out before or after access is approved. Interestingly, their obligations can change attributes that may affect further access states (for example, to prohibit concurrent access to more than five users). However, such changes still cannot be considered administrative as they modify the environment and not the access policy.

2.2. Verification of Administrative Access Control Policies

Access control models fall into two categories: administrative and non-administrative. A non-administrative policy specifies the authorization elements with an access decision procedure. It remains unchanged during execution and may be updated offline by an administrator. For example, role-based access control (RBAC) specifies access privileges in terms of user–role assignment (URA), role–role assignment (RRA), and permission–role assignment (PRA). These assignments do not change at runtime. An administrative policy includes administrative operations to change the non-administrative counterpart. For example, Administrative RBAC (ARBAC) adds administrative commands to RBAC to update the URA, RRA, and PRA relations in an RBAC policy.

A substantial amount of work has been carried out on the verification of administrative attribute-based access control (ABAC) and RBAC policies. Jha et al. [15] have investigated the specification and verification of separation of duty (SoD) constraints in an ABAC model based on access control rules defined over subject, object, and environment attributes. They addressed the SoD enforcement with respect to the modifications of attributes and rules. Jha et al. [16] have also proposed ADABAC (Administrative ABAC) and used Alloy to analyze certain safety and liveness properties. They have further proposed AMABAC, an administrative model for the rule-based ABAC model, and used the datalog-based tool $\mu$Z to verify AMABAC policies [17]. AMABAC provides administrative relations and commands for managing the subject, object, and environment attributes and access control rules. Users can apply individual commands manually to modify the policy elements and, thus, the access privileges.

Table 1. Verification methods for ARBAC.

Related Work	Key Techniques	URA	RRA	PRA	iRR	O
Cree [19]	Bounded model checking (smv)	✓	X	X	X	X
Ferrara et al. [20]	Model checking (smv,z3,cbmc,etc.)	✓	X	X	X	X
Gupta et al. [21]	Reachability analysis	✓	X	X	✓	X
Mohawk + T [22]	Bounded model checking (smv)	✓	X	X	X	X
Truong & That [23]	Reachability analysis, SMT (asapxl)	✓	X	X	✓	X
This work	SMT-based verification (cvc5)	✓	✓	✓	✓	✓

shows the main methods based on the ARBAC97 model [18]. They deal with administrative changes to URA but not RRA or PRA. iRR (Initial Role-to-Role assignments) means the corresponding method considers the initial role hierarchy before any administrative changes are made. A method without iRR does not handle role hierarchies at all. O stands for obligation-containing policies.

Our work is comparable to the above studies, as NGAC is more general than RBAC and ARBAC. In NGAC, roles in RBAC correspond to user attributes, and URA (or RRA) maps to NGAC’s user–user attribute (or user attribute–user attribute) assignment. PRA is similar to NGAC’s association relation. However, this work offers the first comprehensive analysis of privilege-changing policies through administrative obligations, a problem not addressed in the previous literature. Our approach not only applies to the URA, RRA, and PRA of ARBAC but also extends to NGAC’s unique features, such as object attribute hierarchies and obligations. Additionally, we verify systematic access control requirements of who can do what and when, rather than merely focusing on user–role relations as in previous studies.

One key distinction between NGAC and administrative access control lies in how NGAC encapsulates a series of administrative commands into a module (e.g., obligation), automatically triggered by a matching access event. In contrast, administrative access control typically addresses individual administrative commands. Consequently, the proposed verification approach must diverge from existing research by addressing sequences of administrative commands. Notably, the interdependency analysis of administrative commands within an NGAC obligation poses a unique challenge not encountered in previous work.

2.3. Policy Verification with SMT

There are also works on the verification of non-administrative ABAC policies using SMT. Such verification involves only a static policy (similar to the initial configuration in NGAC without administrative obligations). Margheri et al. [12] introduced a comprehensive framework leveraging SMT to specify, analyze, and enforce attribute-based access control (ABAC) policies. This framework’s core is a specially designed language named the Formal Access Control Policy Language (FACPL). The framework can automatically verify properties using the authorizations mandated by individual policies and the relationships between multiple policies. FACPL can be translated into the SMT formulas without losing its semantic meaning. Arkoudas et al. [24] introduced SMT-based formal theories and logical frameworks for expressing and verifying access control policies. The authors reduce access adjudication to logical formulas and provide analyses on consistency, coverage, and change impact. Although the frameworks distinguish between policy administrators and policy users, only the administrators can manually change the access privileges. Zelkova [25] is a tool that encodes statically defined AWS policies as logical formulas and then uses SMT solvers to query the properties of these policies, providing users with a mechanism to detect misconfigurations of their policies. Notably, Zelkova is an at-scale industry software invoked millions of times daily. Zelkova does not consider policy changes made by administrators or any form of dynamic evolution of the access policy state.

2.4. Testing of Access Control Policies

This paper differs from testing NGAC policies [10] and obligations [6,7]. Policy testing is an alternate approach for quality assurance of access control policies. Unlike verification, policy testing aims to find errors by executing the policy with a set of test cases (i.e., access requests). The policy is faulty if the policy decision for any request is incorrect. Recent research has focused on test generation methods and policy mutation analysis [26]. Policy mutation is the widely applied approach for evaluating the effectiveness of these methods. It creates a set of mutants of a correct policy and then exercises each mutant against the tests generated by a testing method. A mutant is a modified version of the original policy where a policy element is mutated according to a fault model of representative types of errors. A mutant is said to be killed if at least one test fails; otherwise, it is a live mutant. The effectiveness of the testing method is indicated by the ratio between the total number of mutants killed and the total number of non-equivalent mutants [27]. Chen et al. [28] present a fault-based testing approach to detect errors within NGAC policies, which hypothesizes about potential errors according to the fault model, generates the correct policy versions as mutants, and validates the hypothesis by executing tests.

3. Preliminaries

3.1. Administrative Obligations in NGAC

We refer to privilege configuration as a collection of assignment, association, and prohibition relations on the sets of basic policy elements. Thus, an NGAC policy comprises an initial configuration $C_0$ and a set of obligations $\Phi$. An obligation specifies the response to the access events that match an event pattern, represented by $EVENT(SS,SAR,ST)$, where $SS,SAR$, and $ST$ are sets of subjects (user or user attributes), access rights, and target policy elements (users, user attributes, objects, and object attributes). The response is triggered if an access event $e(s,ar,t)$ matches the event pattern, i.e., $s\in SS$, $ar\in SAR$, and $t\in ST$, where s is a subject, ar is an access right, and t is a target policy element. The access event refers to the occurrence of a granted access request, i.e., request $(s,ar,t)$ is permitted under the current privilege configuration.

3.1.1. Configuration and Access Adjudication

The decision to grant or deny an access request is adjudicated according to the current configuration. Formally, a configuration C is a 9-tuple (U, UA, O, OA, AR, PC, ASSIGN, ASSOCIATION, PROHIBITION), where ASSIGN, ASSOCIATION, and PROHIBITION are relations on the sets of users U, user attributes UA, objects O, object attributes OA, policy classes PC, and access rights AR. ASSIGN and ASSOCIATION specify what is permitted. The permissions can be overridden by PROHIBITION. The policy class is a mechanism for policy modularization; each user, user attribute, object, and object attribute should be contained within a policy class.

Assignments

The assignment relation is defined as a subset of the union of the Cartesian products of policy element sets as follows: $ASSIGN$ $\subseteq (U\times UA)$ $\cup (UA\times UA)\cup$ $(UA\times PC)$ $\cup (OA\times OA)\cup$ $(OA\times PC)$.

A user can be assigned to a user attribute, a user attribute can be assigned to another user attribute or policy class, and an object attribute can be assigned to another object attribute or policy class.

Definition 1

(Containment). x is said to contain y, i.e., contains(x, y), defined as follows: (1) contains(x,y) if (y,x) ∈ ASSIGN; (2) contains(x, x) if x ∈ UA ∪ OA; (3) contains(x,z) if contains(x,y) and contains(y,z).

As a policy class is a container of certain users, user attributes, objects, and object attributes, its assignment relation can be represented as a directed acyclic graph, i.e., $\neg contains(y,x)$ if $contains(x,y)$ and $x\ne y$. It comprises a user/user attribute hierarchy and an object/object attribute hierarchy. For example, the user $u_1$ is contained by $u{a}_2$, i.e., $contains(u{a}_2,u_1)$, if the following holds: $\{(u_1,u{a}_1),(u{a}_1,u{a}_2)\}\subseteq ASSIGN$, i.e., there exists a hierarchical relation between $u_1$ and $u{a}_2$.

Associations

The association relation is defined as $ASSOCIATION\subseteq UA\times 2^{AR}$ $\times AT$, where AR is the set of all access rights and $AT=UA\cup OA$ is the set of user attributes and object attributes. Each association (ua, ars, at) specifies one or more access rights ars between a user attribute ua and an object (or user) attribute at.

Prohibitions

Prohibitions define the negation of associations to constrain access rights. They are specified by the conjunctive and disjunctive operators and the inclusion or exclusion complement operators on the assignment and association relations (i.e., the user/object attribute hierarchies and the permitted access rights). The prohibition syntax is $\langle s,ars,$ $(op$, $($ ${\alpha }_1,c_1)$, …, $($ ${\alpha }_n,c_n\left)\right)\rangle$, where s is a subject; $ars$ is a set of access rights; $op$ is an operator, either $conjunctive$ or $disjunctive$; $($ ${\alpha }_i,c_i)$ describes a prohibition container; ${\alpha }_i$ is a complement operator, either inclusive or exclusive; and $c_i$ is a container (user attribute, object attribute, or policy class).We adopt the formalization of prohibitions provided in [9,10] in this work.

Below, we present the formal definition of access event adjudication that utilizes all the aforementioned relations.

Definition 2

(Access adjudication). Given a configuration C = (U, UA, O, OA, AR, PC, ASSIGN, ASSOCIATION, PROHIBITION) and access request (s, ar, pe), where s is a subject (user or user attribute), ar is an access right, and pe is a policy element (user, user attribute, object, or object attribute), the access decision is “permit”, if the following conditions hold; otherwise, it is “deny”:

• Request (s, ar, pe) is permitted by ASSIGN and ASSOCIATION. In other words, there exists (ua, ars, at) $\in ASSOCIATION$ in each policy class pc containing pe such that (1) contains (ua, s), (2) $ar\in$ ars, (3) contains(at, pe), and (4) contains (pc, at).
• No prohibition precludes request (s, ar, pe), i.e., there is no prohibition (u,ars,tps) ∈ PROHIBITION such that (1) s = u, (2) $ar\in$ ars, and (3) $pe\in$ tps, where tps is the prohibition set or policy elements that are targets of prohibition.

Figure 1 shows a portion of the EditingPolicyClass in the GPMS (Grant Proposal Management System) case study. GPMS, an open-source application developed alongside the NGAC standard’s reference implementation, aims at web-based automation of the grant proposal approval workflow at an academic institution. The workflow involves various users in the completion of a proposal data sheet. GPMS is the only open-source real-world NGAC application with complex authorization elements and 19 non-trivial obligations [29]. When a PI-eligible faculty user creates a proposal data sheet (PDS), EditingPolicyClass is instantiated for the new PDS as part of the initial configuration. The configuration also includes three other policy classes. It changes dynamically due to obligation-triggering access events. In Figure 1, there are several user attributes, i.e., UA = {PI,CoPI,SP}. For the object attributes, we use PDSWhole and PDSSections to reference the entire PDS object and the specific data sections of the PDS object, respectively. This is because access rights, such as submit and delete, apply to the entire PDS rather than a specific data section. PDSSections fall into two groups: PIEditable and CoPIEditable. There are several objects, i.e., O = {ProjectInfo, BudgetInfo, UnivCommitmentsInfo, ComplianceInfo, Collaboration Info}. This part of the assignment relation is {(PI, CoPI), (CoPI, SP), (SP, EditingPolicyClass), (ProjectInfo, PI Editable), (BudgetInfo, PIEditable), (PIEditable, PDSSections), (PDSSections, EditingPolicyClass), (PDSWhole, EditingPolicyClass), (UnivCommitmentsInfo, CoPIEditable), (ComplianceInfo, CoPIEditable), (CollaborationInfo, CoPIEditable), (CoPIEditable, PDSSections), (PDSSections, EditingPolicyClass)}. The association relation directly specifies the following privileges: {(PI, write, PIEditable), (PI, submit, PDSWhole), (CoPI, write, CoPIEditable), (PI, delete, PDSWhole), (SP, read, PDSSections), (PI, addCopi, CoPI), (PI, deleteCopi, CoPI), (CoPI, addSP, SP), (CoPI, deleteSP, SP)}. The user attribute hierarchy and object attribute hierarchy also imply the following privileges: {(CoPI, read, PDSSections), (SP, read, BudgetInfo)}, etc.

3.1.2. Response

The response of an obligation is a sequence of one or more conditional actions:

${\left\{\left[if\langle condition\rangle \right]then\langle action\rangle \right\}}^{+}$. There are five types of actions: create, assign, grant, deny, and delete. A create action adds a new policy element. An assign action adds a new assignment (x, y) to the assignment relation, i.e., $ASSIG{N}^{\prime }=ASSIGN$ $\cup \left\{\right(x,y\left)\right\}$. A grant action adds a new association (ua, ars, at) to the association relation, i.e., ASSOCIATION’ = ASSOCIATION$\cup \left\{\right(ua,ars,at\left)\right\}$. A deny action adds a new prohibition, i.e., PROHIBITION’ = PROHIBITION $\cup \left\{\right(s,ars,tps\left)\right\}$. A delete action removes the specified policy elements. As such, the response of an obligation updates the current configuration’s assignment, association, and prohibition relations, thereby changing the access decisions.

The condition or action part in $[if\langle condition\rangle then]\langle action\rangle$ may reference built-in functions of the NGAC implementation and custom functions in the application code (e.g., in Java). For example, in an assign action that adds a new assignment (x,y) by assigning user x to user attribute y, x (or y) may be obtained from the invocation of a custom function rather than a predefined value.

In GPMS, there are 19 obligations. One of them, submit_proposal, is triggered when a PI user performs the operation submit on a PDSWhole. This obligation will remove all the permissions except read from PI, CoPI, and SP and grant the approval powers to Chair. The updated editing policy class is presented in Figure 2, and the obligation is described as follows:

• Event: A PI user performs submit on the PDSWhole editing policy class.
• Response:
  (1) Remove association (PI, {submit, delete}, PDSWhole);
  (2) Remove association (PI, {addCoPI, deleteCoPI}, CoPI);
  (3) Remove association (CoPI, {addSP, deleteSP}, SP);
  (4) Grant chair approval and disapproval access rights on PDSWhole;
  (5) Grant chair access rights on chair approval.

3.2. Satisfiability Modulo Theories

SMT builds upon a propositional satisfiability problem (SAT) that determines if the variables of a given Boolean formula can be assigned consistently to true or false values such that the formula evaluates to true. If such an assignment exists, the formula is satisfiable; otherwise, it is unsatisfiable. For example, $a\wedge b$ is satisfiable because it evaluates to true when both a and b are true. $a\wedge \neg a$ is unsatisfiable because it is false for all possible assignments of a. Although SAT is the first problem proven to be NP-complete, heuristic algorithms in modern SAT solvers often handle hundreds of thousands of variables, sufficient for many practical problem instances. SMT extends SAT by using first-order logic (FOL), providing reasoning for objects and their relations as predicates and quantifiers and thus making the constraints more expressive. Specifically, SMT allows Boolean variables in SAT formulas to be replaced by predicates from various background theories, such as the theories of integers, real numbers, sets, and relations. A predicate is a Boolean variable with parameters representing an operation or relation. Suppose x is an integer and y is a set. The SMT formula $(x>0)\wedge \neg (y=\varnothing )$, involving theories of integers and sets, is obtained from the SAT formula $a\wedge \neg b$ by replacing a and b with the predicates $x>0$ and $y=\varnothing$, respectively.

Our work leverages the theory of finite sets with cardinality constraints [30]. This theory allows us to express policy elements and policy relations as sets and predicates, check for set membership (∈), and reason with union (∪), intersection (∩), set minus (∖), subset (⊂), and an empty set (∅). For example, adding an assignment can be expressively encoded using union as $ASSIGN\cup \left\{\right(x,y\left)\right\}$, where the new assignment $\left\{\right(x,y\left)\right\}$ is represented as a singleton of a tuple of size 2. Additionally, we use the theory of finite relations [31], which includes reasoning about relational structures. Its operators, such as join (⋈) and transpose ${(}^{-1})$, along with tuples of various sizes, allow for expressive encoding of and reasoning about complex NGAC relations. Notably, while cvc5 supports transitive closure, we found that using transitive closure significantly degrades performance in comparison with our current approach, which recalculates only the portion of the containment relation that has changed. A summary of symbols and notations is provided in

Table 2. List of symbols and notations.

Symbol	Description
$C_0$	Initial configuration
$ASSIGN$	Assignment relation
$ASSOCIATION$	Association relation
$PROHIBITION$	Prohibition relation
$\Phi$	A set of obligations
$\varphi$	An obligation
U, UA, O, OA, AR, PC	Sets of users, user attributes, objects, object attributes, access rights, policy classes
SS, SAR, ST	Sets of subjects, access rights, and target policy elements of EVENT(SS,SAR,ST)
${\left[v\right]}_k$	Variable or formula v at bound k
$\psi \left(e\right)$	The SMT encoding of expression e
$\left[obligationFiring\right($$\varphi$${\left)\right]}_k$	The firing of obligation $\varphi$ at bound k
$g_{pre}$	An optional goal condition on the configuration that triggers the target obligation
$e(s,ar,t)$	An obligation-triggering access event by subject s requiring access right $ar$ on target t
$goalObligation(s,ar,t)$	An optional goal obligation triggered by access event $e(s,ar,t)$
$g_{post}$	A required goal condition of the target configuration
permit(s,ar,pe)	The permission adjudication of subject s, access right $ar$, and policy element $pe$
a	An obligation action
p(a)	The precondition of action a
q(a)	The effect of action a
$c{i}^{-}\left(a\right)$	Disabling causal interference of action a
$c{i}^{+}\left(a\right)$	Enabling causal interference of action a
G	The guarding condition
$CMS(a,RELATION)$	The configuration modification set of an action a in relation RELATION
M	A model that satisfies the SMT encoding and mapping variables and formulas to values such that all constraints are satisfiable.

.

4. Overview of the Verification Approach

Our approach aims to verify access control requirements that specify who (i.e., the subject–user or user attribute) can perform what actions (i.e., access rights) on what resources (i.e., objects or object attributes), and under what conditions. The focus is on tracking privilege changes that result from a sequence of obligation executions.

The verification is formalized as the following reachability problem [9]:

Definition 3

(Reachability problem). Given an NGAC policy $(C_0,\Phi )$ and a goal property $(g_{pre},$ goalObligation(s,ar,t), $g_{post})$, the reachability problem is to determine if there exists a sequence of obligation firings, $\langle C_0,$ ${\varphi }_1$,$C_1,$ ${\varphi }_2$ $,C_2$, …, $C_{n-1}$ ${\varphi }_n$ $,C_n\rangle$, such that (1) $\langle C_{i-1},$ ${\varphi }_i$ $,C_i\rangle$ ($1\le i\le n$) is a valid obligation firing, (2) $g_{pre}$ and $g_{post}$ are satisfied by $C_{n-1}$ and $C_n$, respectively, and (3) ${\varphi }_n$ matches $goalObligation(s,ar,t)$, including the access event $e(s,ar,t)$ if s, ar, or t is given.

In the goal property $(g_{pre},goalObligation(s,ar,t),$ $g_{post})$, $goalObligation(s,ar,t)$ is the goal obligation triggered by access event $e(s,ar,t)$, $g_{pre}$ describes the condition on the configuration that triggers the target obligation, and $g_{post}$ specifies the condition on the target configuration. While all three are optional, at least one of them must be given. When goalObligation(s,ar,t) is not specified, it refers to any obligation. When goalObligation(s,ar,t) is given, s, ar, and t are optional. If s is not specified, the event that fires the obligation may be performed by any subject (user or user attribute). This is similar when ar and t are not specified.

The general architecture of the verification approach is presented in Figure 3. It has three main components: reachability analyzer, configuration encoder, and obligation encoder. The reachability analyzer includes the verification algorithm and the logic to process the goal property, while the configuration and obligation encoders are responsible for transforming an NGAC policy into SMT formulas. Additionally, the obligation encoder can be extended by implementing custom functions via the custom function interface. The reachability analyzer uses the NGAC reference implementation to read the policy from JSON and YML files and cvc5 to run our encoding, verify the reachability of the goal, and report the result along the path of obligations and their access events back to the user.

Our approach to solving the reachability problem aims to find a sequence of obligation firings that reaches the given goal from the initial configuration. To this end, we represent the policy elements and relations of each configuration as bound-tagged variables and access decisions as bound-tagged formulas in the form of ${\left[v\right]}_k$ (i.e., variable or formula v at bound k). Each obligation firing is translated into a formula that describes the transition of the configuration state from each bound $k-1$ to k according to the obligation’s event pattern and response. Let $\psi \left(e\right)$ be the SMT encoding of expression e and $\left[obligationFiring\right($ $\varphi$ ${\left)\right]}_k$ represent the firing of obligation $\varphi$ at bound k. $\psi$ $\left(C_0\right)$, $\psi$ $\left(g_{pre}\right)$, $\psi$ $\left(goalObligation\right(s,ar,t\left)\right)$, and $\psi$ $\left(g_{post}\right)$ are bound-tagged as $\psi [$ $\left(C_0\right){]}_0$, $\psi$ ${\left[\left(g_{pre}\right)\right]}_{k-1}$, ${\left[goalObligation(s,ar,t)\right]}_k$, and $\psi$ ${\left[\left(g_{post}\right)\right]}_k$, respectively. A solution at the given bound k exists if $\psi$ ${\left[\left(C_0\right)\right]}_0{\wedge }_{k=0}^{k}T(k-1,$ $k)\wedge$ $\psi$ $[\left(g_{pre}\right){]}_{k-1}\wedge$ ${\left[goalObligation(s,ar,t)\right]}_k \wedge [$ $\psi$ $\left(g_{post}\right){]}_k$ is satisfiable, where $T(k-1,k)$ is the disjunction of the state transition formulas of all obligation firings from $k-1$ to k; otherwise, we continue with a new bound $k+1$.

Algorithm 1 describes the verification procedure. Variable $policyFormula$ holds the SMT code of the configurations and obligations (to be discussed in subsequent sections). The outer loop iterates (lines 4–16) over the bounds until a solution is found. The solution includes the path of obligation firings and all user-defined variables in the property. If no solution exists at the bound k, the next bound reuses the encoding from all the previous iterations and only deals with the encoding for the new bound. The inner loop (lines 6–8) obtains the encoding of the state transitions of all obligation firings for the current bound. Their disjunction, i.e., $T(k-1,k)$, is asserted on line 10 using exactly one constraint, ensuring that only one obligation is fired at each bound. And lines 11–14 assert the goal based on the input, while line 15 sends the $policyFormula$ and $goalAssertion$ to solver.

Algorithm 1: SMT-based verification

While our approach bears similarity to SAT-/SMT-based planning [32,33] and bounded model checking [34], our SMT-based encoding is distinct. The configurations and obligations of NGAC policies are rather complex. As described in Section 3.1, access adjudication is determined by ASSIGN, ASSOCIATION, and PROHIBITION. The decision procedure involves reasoning about the user attribute hierarchies and object attribute hierarchies implied by $ASSIG{N}^{\ast }$, the transitive closure of ASSIGN. Thus, an SAT-/SMT-based approach must correctly encode the reasoning of hierarchies as a logical formula. There are two possible techniques: (a) applying transitive closure constraints to deal with the hierarchies directly and (b) flattening the hierarchies by calculating the transitive closure, i.e., enumerating every pair $(x,y)$ in $ASSIG{N}^{\ast }$. Solving constraints with transitive closure is generally an undecidable problem [31]. Our experiment has shown that the transitive closure implementation in cvc5 cannot solve the constraints in our case studies. In this paper, we calculate $ASSIG{N}^{\ast }$ when encoding the assignment relation as an SMT formula. This requires recalculation of $ASSIG{N}^{\ast }$ whenever an obligation firing changes ASSIGN. To deal with the complex structures of NGAC configurations, our approach builds upon SMT solvers for the Theory of Sets [30] and finite relations [31].

4.1. Configuration Encoding

Given the inherent support for set theory in the cvc5 SMT solver, we represent a set as a predicate, allowing the elements of the set to be determined by a predicate that can vary based on a bound. Previous work has largely encoded each element as a single proposition (true or false in logic). However, this approach is inefficient in the context of NGAC, where extensive operations on sets and evolving set membership are common. Given C=$(U,UA,O$, $OA$, $AR$, $PC$, ASSIGN, ASSOCIATION, PROHIBITION), encoding of configuration C is defined as follows:

$\psi$ $\left(C\right)$=$U\wedge UA\wedge O\wedge OA\wedge AR\wedge PC\wedge$ $ASSIGN\wedge ASSIG{N}^{\ast }\wedge ASSOCIATION\wedge$

$PROHIBITION\wedge permit(s,ar,pe)$.

The encoding of set S depends on what a relation or set of policy elements S represents. For example, set U is encoded as a set of all users. And the relation ASSIGN is represented as a set of tuples (ancestor,descendant). Other policy elements and relations are encoded similarly.

We encode both ASSIGN and $ASSIG{N}^{\ast }$ for reasoning about the explicit assignment, implicit assignment, and containment. The predicate permit(s,ar,pe) corresponds to the permission adjudication of subject s, access right $ar$, and policy element $pe$. Its SMT formula is defined as follows:

$\psi$$\left(permit\right(s,ar,pe\left)\right)=$

$(s,?sa)\in ASSIG{N}^{\ast }\wedge$

$(?sa,ar,?at)\in ASSOCIATION\wedge$

$(pe,?at)\in ASSIG{N}^{\ast }\wedge$

$(u,ar,pe)\notin PROHIBITIO{N}^{\ast }\wedge$

$(pe,?pc)\in ASSIG{N}^{\ast }\wedge$

$(?at,?pc)\in ASSIG{N}^{\ast }\wedge ?pc\in PC$

We utilize the operations of finite relations to derive the set of implicit prohibitions, PROHIBITION*, based on the PROHIBITION, $ASSIG{N}^{\ast }$, and $tp{s}^{\ast }$ sets:

$\psi$ $\left(PROHIBITIO{N}^{\ast }\right)=[UA\bowtie ASSIG{N}^{\ast }]\bowtie$ $PROHIBITION\bowtie {(tp{s}^{\ast }\bowtie ASSIG{N}^{\ast })}^{-1}$, where $tp{s}^{\ast }$ is derived as follows:

$\psi$$\left(tp{s}^{\ast }\right)=ite$

$isConjunctive$

$((\left\{p{e}_1\right\}\bowtie ASSIG{N}^{\ast })\cap \dots \cap (p{e}_n\bowtie ASSIG{N}^{\ast }))$

$((\left\{p{e}_1\right\}\bowtie ASSIG{N}^{\ast })\cap \dots \cup (p{e}_n\bowtie ASSIG{N}^{\ast }))$

and $isConjuctive$ means whether the prohibition set is conjunctive or disjunctive. $ite$ is the if–then–else structure in cvc5. If any prohibition set is marked as exclusive, each $p{e}_n\bowtie ASSIG{N}^{\ast }$ resulting set is subtracted from $U\cup UA\cup OA$.

4.2. Event Encoding

As previously described, an obligation is fired if an event (i.e., permitted access request) matches the obligation’s event pattern EVENT(SS,SAR,ST). We encode the obligation firing implication for the event using access adjudication based on the configuration encoding of the previous bound $k-1$:

$\psi$$\left({\left[EVENT(SS,SAR,ST)\right]}_k\right)=$

$\left[obligationFiring\right($$\varphi$${\left)\right]}_k\Rightarrow {\left[permit(?s,?ar,?t)\right]}_{k-1}\wedge$

$?ar\in SAR\wedge$

$(?s\in SS\vee$

$((?s,ua)\in {\left[ASSIG{N}^{\ast }\right]}_{k-1}\wedge ua\in SS))\wedge$

$(?t\in ST\vee$

$((?t,at)\in {\left[ASSIG{N}^{\ast }\right]}_{k-1}\wedge at\in ST))$

Predicate $permit(?s,?ar,?t)$ represents a permitted access request. Its occurrence will trigger the obligation if (a) subject ?s is either included in the subject set SS or contained by a user attribute ua in SS; (b) target policy element ?t is either included in target set ST or indirectly included via containment by a user or object attribute at; and (c) ?ar is contained by the set of access rights SAR.

4.3. Response Encoding

The response consists of one or more conditional actions. The precondition specifies under which configuration the action applies, whereas the effect describes the action’s changes to the configuration. The relation between the action’s condition and effect is denoted as “if” or implies(⇒). We encode each action’s condition $p\left(a_i\right)$ and action effect $q\left(a_i\right)$, where i is the index of the conditional action in the obligation $\varphi$:

$\psi$$\left({\left[\mathrm{RESPONSE}\right]}_k\right)=$$\left[obligationFiring\right($$\varphi$$)\Rightarrow$

${\bigwedge }_{i=1}^n({\bigvee }_{j=1}^{i-1}(c{i}^{+}\left(a_{i-j}\right)\vee p\left(a_i\right)\Rightarrow q\left(a_i\right))\wedge$$\neg {\bigvee }_{j=1}^{i-1}c{i}^{-}\left(a_{i-j}\right){\left)\right]}_k$

The above formula demonstrates possible disabling causal interference $c{i}^{-}\left(a_{i-j}\right)$ by every preceding action $a_{i-j}$ on every consequent action $a_i$. Such interference may disable consequent actions by falsifying their precondition. Additionally, the above formula includes enabling causal interference, $c{i}^{+}\left(a_{i-j}\right)$, which enables action $a_i$ by satisfying the condition that was not satisfied prior to action $a_{i-j}$ execution.

We define causal interference below:

Definition 4

(Causal interference). Action $a_i$ has enabling causal interference $c{i}^{+}\left(a_i\right)$ on action $a_{i+1}$ if the effect of $a_i$ enables $a_{i+1}$ by satisfying its condition $p\left(a_{i+1}\right)$ and disabling interference $c{i}^{-}\left(a_i\right)$ if the effect of $a_i$ disables $a_{i+1}$ by falsifying its condition $p\left(a_{i+1}\right)$. The causal interference is disabling if both $a_i$ and $a_{i+1}$ are augmentative or reductive and enabling if one is augmentative and the other is reductive.

The calculation of causal interference depends on the precise formalization of the precondition and effect of each individual action provided in Section 5. The interdependency analysis and encoding of conflicting actions will be shown in Section 6.

We categorize actions into two types: augmentative and reducing. Augmentative action expands ASSIGN and ASSOCIATE relations, while reductive actions shrink the relations.

Additionally, we need to encode the reason for a change to express why the NGAC configuration was changed based on which part of the configuration was affected by the actions of obligation $\varphi$. The reason for the change in ASSIGN, ASSOCIATION, and PROHIBITION is represented informally as follows: if there exists at least one obligation ${\varphi }_i$ and one action $a_j$, where the firing of ${\varphi }_i$ entails $a_j$, and if there is a change to the ASSIGN relation, then $a_j$ must be related to modifying assignments; if there is a change to the ASSOCIATION relation, then $a_j$ must be related to modifying associations; if there is a change to PROHIBITION, then $a_j$ must be related to modifying prohibitions. Formally, we represent this as follows:

$\exists i\exists j\left(\right[obligationFiring($${\varphi }_i{\left)\right]}_k\vDash a_j)\wedge$

$({\left[ASSIGN\right]}_{k-1}\ne {\left[ASSIGN\right]}_k\Rightarrow$ $assign\_modifying\left(a_j\right))\wedge$

$({\left[ASSOCIATION\right]}_{k-1}\ne {\left[ASSOCIATION\right]}_k\Rightarrow$ $association\_modifying\left(a_j\right))\wedge$

$({\left[PROHIBITION\right]}_{k-1}\ne {\left[PROHIBITION\right]}_k\Rightarrow$ $prohibition\_modifying\left(a_j\right))$

4.4. Soundness and Completeness of SMT-Based Verification

The reachability problem in Definition 3 is undecidable, as shown in [9]. This result is consistent with the classical undecidability of the access matrix model [35] and highlights the additional complexity introduced by dynamic obligations. Nevertheless, the undecidability of the general problem does not preclude the development of practical verification techniques for real-world applications.

To enable formal reasoning in real-world scenarios, we introduce a terminal bound K and analyze reachability within this finite horizon. In this section, we formally prove the soundness and completeness of Algorithm 1 with respect to the bounded reachability formulation. We begin by defining symbolic encoding, model interpretation, and operational semantics.

Let C denote a configuration and let $e(s,ar,t)$ denote an access event. The transition semantics of NGAC are defined inductively by the relation

$$C_i\stackrel{e(s_i,a{r}_i,t_i)}{\to }{C}_{i+1}$$

which holds if and only if

1.

The access request $e(s_i,a{r}_i,t_i)$ is authorized in $C_i$.

2.

Any obligations triggered by $e(s_i,a{r}_i,t_i)$ are instantiated according to $\Phi$.

3.

The execution of these obligations results in a state change to $C_{i+1}$.

We say a configuration $C_k$ satisfies $goalObligation(s,ar,t)$, written as follows:

$$C_k\vDash (g_{pre},goalObligation(s,ar,t),g_{post})$$

if there exists a step $j<k$ such that

1.

$C_j\vDash g_{pre}$;

2.

$e(s_j,a{r}_j,t_j)$ is executed at step j;

3.

The corresponding obligation $\varphi$, which is the same as the specified goal obligation $goalObligation(s_j,a{r}_j,t_j)$, is triggered by $e(s_j,a{r}_j,t_j)$;

4.

The obligation response actions are completed successfully in the trace;

5.

The resulting configuration $C_k$ satisfies $g_{post}$.

Let $\psi (C_0,\Phi ,K)$ denote the SMT encoding of NGAC execution semantics and obligations over K steps. This encoding yields a formula $policyFormula$ such that any model M satisfying $policyFormula$ corresponds to a sequence of events $\left\{e(s_1,a{r}_1,t_1),\dots ,e(s_k,a{r}_k,t_k)\right\}$ that induce the following transitions:

$$C_0\stackrel{e(s_1,a{r}_1,t_1)}{\to }{C}_1\stackrel{e(s_2,a{r}_2,t_2)}{\to }\dots \stackrel{e(s_k,a{r}_k,t_k)}{\to }{C}_{k+1}$$

We assume that $policyFormula$ is the correct abstraction of the NGAC semantics:

$$M\vDash policyFormula\Rightarrow \exists \{C_0,\dots ,C_{k+1}\},\mathrm{such}\mathrm{that}\forall i\le k,C_i\stackrel{e(s_i,a{r}_i,t_i)}{\to }{C}_{i+1}$$

4.4.1. Soundness

Theorem 1

(Soundness). Let $(C_0,\Phi )$ be the initial configuration, $(g_{pre},goalObligation(s,ar,$ $t),g_{post})$ be the goal property, and K be a terminal time bound. If Algorithm 1 returns a $SOLUTION$ at bound $k\le K$, then there exists a valid sequence of access events {$e(s_1,a{r}_1,t_1),\dots ,e(s_{k-1},a{r}_{k-1},t_{k-1})$}, such that starting from configuration $C_0$, these events lead to configuration $C_k$, where the goal property $(g_{pre},goalObligation(s,ar,$ $t),g_{post})$ is satisfied:

$\exists \{e(s_1,a{r}_1,t_1),\dots ,e(s_{k-1},a{r}_{k-1},t_{k-1})\},C_k\vDash goalObligation(s_j,a{r}_j,t_j).$

Proof. 

We prove the soundness of Algorithm 1 by induction on the length k of the access event trace, where $k\le K$ and the SMT solver returns a satisfying model at bound k.

Let $policyFormula$ be an SMT formula encoding NGAC semantics and goal satisfaction over k steps. Suppose that the SMT solver finds a model $M\vDash policyFormula$. We aim to show that this model corresponds to a valid NGAC execution trace $\{C_0,\dots ,C_k\}$ such that $C_k\vDash (g_{pre},goalObligation(s,ar,t),g_{post})$.

Base case ($k=1$): The model M encodes a single access event $e(s_1,a{r}_1,t_1)$ such that

1.

$g_{pre}$ holds in $C_0$;

2.

$e(s_1,a{r}_1,t_1)$ is executable in $C_0$ and triggers the obligation $goalObligation(s,ar,t)$;

3.

The obligation executes fully within one step, resulting in configuration $C_1$, where $g_{post}$ holds.

By the correctness of the transition relation, we conclude the following:

$$C_0\stackrel{e(s_1,a{r}_1,t_1)}{\to }{C}_1,\mathrm{and}{C}_1\vDash (g_{pre},goalObligation(s,ar,t),g_{post}).$$

Inductive case ($k=n+1$): Assume the inductive hypothesis holds for all $m\le n$. Any model $M_n\vDash policyFormula$ corresponds to a valid execution trace $\{C_0,e(s_1,a{r}_1,t_1),\dots ,$ $e(s_n,a{r}_n,t_n),C_n\}$ such that $C_n$ satisfies the goal if the SMT encoding requires it.

Now suppose the SMT solver returns $M_{n+1}\vDash policyFormula$ at bound $n+1$, encoding the access events:

$$\{e(s_1,a{r}_1,t_1),\dots ,e(s_{n+1},a{r}_{n+1},t_{n+1})\}$$

Through the construction of $policyFormula$, the event $e(s_{n+1},a{r}_{n+1},t_{n+1})$ is enabled in $C_n$, which is a result of executing the prior n events. That is,

$$C_0\stackrel{e_1}{\to }{C}_1\stackrel{e_2}{\to }\dots \stackrel{e_n}{\to }{C}_n\stackrel{e_{n+1}}{\to }{C}_{n+1}$$

From the inductive hypothesis, we know the following:

$$\forall i\le n,C_i\stackrel{e_i}{\to }{C}_{i+1}$$

and the semantic preconditions for $e(s_{n+1},a{r}_{n+1},t_{n+1})$ hold in $C_n$.

Furthermore, $policyFormula$ encodes the goal satisfaction condition as follows:

• $g_{pre}$ holds in $C_n$;
• $e(s_{n+1},a{r}_{n+1},t_{n+1})$ is triggered;
• The obligation $goalObligation(s,ar,t)$ has completed execution;
• $C_{n+1}\vDash g_{post}$.

Hence, $C_{n+1}\vDash (g_{pre},goalObligation(s,ar,t),g_{post})$

Conclusion: Through induction on k, any satisfying model of the SMT encoding ${\varphi }_k$ corresponds to a valid NGAC execution trace of length k that satisfies the goal. Therefore, if Algorithm 1 returns SOLUTION, the goal is reachable within $k\le K$ steps in the NGAC semantics.   □

4.4.2. Completeness

Theorem 2

(Completeness). Let $(C_0,\Phi )$ be the policy, $(g_{pre},goalObligation(s,ar,t),g_{post})$ the goal property, and K a terminal time bound. If there exists a valid access event sequence

$$\{e(s_1,a{r}_1,t_1),\dots ,e(s_k,a{r}_k,t_k)\}$$

such that, starting from configuration $C_0$, the trace induces transitions

$$C_0\stackrel{e_1}{\to }{C}_1\stackrel{e_2}{\to }\dots \stackrel{e_k}{\to }{C}_k,$$

and $C_k\vDash (g_{pre},goalObligation(s,ar,t),g_{post})$ with $k\le K$, then Algorithm 1 returns SOLUTION at bound k; that is, the SMT encoding $policyFormula$ is satisfiable and a model $M\vDash policyFormula$ exists.

Proof. 

We prove the completeness of Algorithm 1 by construction. Assume there exists a valid execution trace

$$\{C_0,e(s_1,a{r}_1,t_1),C_1,\dots ,e(s_k,a{r}_k,t_k),C_k\}$$

such that each transition

$$C_i\stackrel{e(s_{i+1},a{r}_{i+1},t_{i+1})}{\to }{C}_{i+1},\mathrm{for}0\le i<k$$

respects the NGAC operational semantics and $C_k$ satisfies the goal property

$$C_k\vDash (g_{pre},goalObligation(s,ar,t),g_{post})$$

We aim to show that the SMT encoding $policyFormula$ produced by Algorithm 1 at bound k is satisfiable and that there exists a model $M\vDash policyFormula$.

Let $\{e(s_1,a{r}_1,t_1),\dots ,e(s_k,a{r}_k,t_k)\}$ be the sequence of access events in this valid trace and let $\mathcal{C}=\{C_0,C_1,\dots ,C_k\}$ be the corresponding sequence of configurations. Since all transitions are valid and respect NGAC semantics by assumption, we now define a model M such that

1.

For each $i\le k$, the valuation of state variables in M at step i corresponds exactly to the configuration $C_i$.

2.

The event variables ${\left[e(s_i,a{r}_i,t_i)\right]}_i$ are assigned to represent the events executed at each step.

3.

The valuation of any obligation-firing variables and state predicates (e.g., ${\left[g_{pre}\right]}_j$, ${\left[g_{post}\right]}_k$) matches the satisfaction conditions in the concrete trace.

Such a model M satisfies the transition constraints in $policyFormula$ because all transitions are valid according to the NGAC semantics. Furthermore,

• $g_{pre}$ holds at $C_{k-1}$;
• $e(s_j,a{r}_j,t_j)$ is executed, triggering $goalObligation(s,ar,t)$;
• the obligation completes execution before step k;
• $C_k\vDash g_{post}$.

So the goal satisfaction constraints encoded in $policyFormula$ are also satisfied.

Therefore, we define model M over k steps such that:

• $M\left(C_i\right)=\mathrm{NGAC}\mathrm{configuration}\mathrm{state}{C}_i$;
• $M\left({\left[e(s_i,a{r}_i,t_i)\right]}_i\right)=\mathrm{true}$, and all other event variables at step i are false;
• $M\left({\left[obligationFiring\left(\varphi \right)\right]}_j\right)=\mathrm{true}$ if $\varphi$ is fired at step j;
• $M\left({\left[\psi \left(g_{pre}\right)\right]}_j\right)=\mathrm{true}$ and $M\left({\left[\psi \left(g_{post}\right)\right]}_k\right)=\mathrm{true}$.

Therefore, this concrete execution trace induces an assignment to all symbolic variables that makes $policyFormula$ true. Hence, the SMT solver will find model $M\vDash policyFormula$, and Algorithm 1 will return SOLUTION at bound k.

Conclusion: If a valid execution trace satisfying the goal exists within bound K, then the SMT encoding $policyFormula$ is satisfiable and Algorithm 1 will find a solution.   □

Remark: Since the encoding $\psi (C_0,\Phi ,K)$ yields a quantifier-free formula in decidable SMT theories (e.g., sets, relations, integers, uninterpreted functions), satisfiability is decidable. Thus, soundness and completeness together imply that Algorithm 1 is a decision procedure for the bounded reachability problem.

5. Formalization of Individual Actions

To analyze the interdependencies of actions, we examine the preconditions and postconditions of each action. In this section, we provide specifications for the precondition p(a) and effect q(a) for each built-in action a in the NGAC standard, encoding these actions as SMT formulas.

5.1. Create Policy Element

The precondition for creating a policy element consists of three predicates: the policy element pe should not exist before its creation and the descendant d of the new policy element must exist and must be an object attribute for object attributes and objects, a user attribute for user attributes and users, or a policy class for attributes. Therefore, the precondition $p\left(create\right(pe,d\left)\right)$ is formalized as follows:

$p\left(create\right(pe,d\left)\right)=pe\notin PE\wedge d\in UA\cup OA\cup$

$PC\wedge (at\in UA\wedge pe\in U\cup UA)\vee$

$(d\in OA\wedge pe\in O\cup OA)\vee$

$(d\in PC\wedge pe\in U\cup UA)$

The effect of creating a policy element $q\left(create\right(pe,at\left)\right)$ must ensure that the policy element exists and the assignment to its descendant also exists.

$q\left(create\right(pe,d\left)\right)=pe\in U\cup UA\cup OA\wedge$$(pe,d)\in ASSIGN$

Note that a policy class is unlikely to be created using obligations, but it is possible. In this case, there will be no need to check the descendant; the “policy class existence” check will be the only precondition required.

5.2. Delete Policy Element

The precondition for deleting a policy element should ensure that the policy element $p{e}_1$ exists. If such a policy element is a descendant of any other policy element $p{e}_2$, such policy elements should have another descendant attribute $at$. This ensures that we delete only one policy element.

$p\left(delete\left(p{e}_1\right)\right)=p{e}_1\in U\cup UA\cup OA\cup PC\wedge$$(p{e}_1\notin UA\cup OA)\vee (p{e}_1\in UA\cup OA\wedge$

$(p{e}_2,p{e}_1)\in ASSIGN\wedge$$(p{e}_2,at)\in ASSIGN\wedge pe\ne at\left)\right)$

The effect ensures that the policy element does not exist and the assignment to the last descendant d is deleted:

$q\left(delete\left(p{e}_1\right)\right)=p{e}_1\notin PE\wedge (pe,d)\notin ASSIGN$

5.3. Add Assignment

The precondition for adding an assignment ensures that ancestor a and descendant d exist, that a is not a policy class, that d is an attribute, that the assignment $(a,d)$ does not exist, and that the assignment $(d,a)$ does not exist, as cycles are not allowed.

$p\left(assign\right(a,d\left)\right)=a\in U\cup UA\cup OA\wedge d\in UA$$\cup OA\cup PC\wedge a\notin PC\wedge d\in UA\cup U\wedge$

$(a,d)\notin ASSIGN\wedge (d,a)\notin ASSIGN$

The effect ensures that the assignment has been created:

$q\left(assign\right(a,d\left)\right)=(a,d)\in ASSIGN$

5.4. Delete Assignment

The precondition for removing an assignment ensures that assignment $(a,d)$ exists and that ancestor a has at least one other assignment to another attribute at. This ensures that we do not delete a policy element by deleting an assignment.

$p\left(deleteassignment\right(a,d\left)\right)=$$(a,d)\in ASSIGN\wedge (a,at)\in ASSIGN\wedge at\ne a$

The effect ensures that the assignment (a,d) has been deleted:

$q\left(deleteassignment\right(a,d\left)\right)=(a,d)\notin ASSIGN$

5.5. Grant

The precondition for granting an access right or creating an association ensures that an association with the user attribute ua, access right ar, and attribute at does not exist and that the user attribute and the attribute of the association do exist and are of a correct policy element type.

$p\left(grant\right(ua,ar,at\left)\right)=$$(ua,ar,at)\notin ASSOCIATION\wedge$$ua\in UA\wedge at\in UA\cup OA$

The effect of the grant action ensures that the association $(ua,ar,at)$ has been created.

$q\left(grant\right(ua,ar,at\left)\right)=$$(ua,ar,at)\in ASSOCIATION$

5.6. Delete Association

The precondition for removing an association ensures that the association $(ua,ar,at)$ exists, where $ua$ is a user attribute of the association, $ar$ is the access right, and $at$ is the attribute of the association.

$p\left(deletegrant\right(ua,ar,at\left)\right)=$$(ua,ar,at)\in ASSOCIATION$

The effect, meanwhile, ensures that the association $(ua,ar,at)$ has been deleted.

$q\left(deletegrant\right(ua,ar,at\left)\right)=$$(ua,ar,at)\notin ASSOCIATION$

6. Action Interdependencies Analysis

To encode the obligation response correctly, we need to capture the exact sequence of the actions’ execution steps within an obligation, ensuring that they are executed in the correct order and that their interdependencies are accurately captured. For example, consider two sequential actions, $a_1$ and $a_2$. These actions have respective preconditions $p\left(a_1\right)$ and $p\left(a_2\right)$ and effects $q\left(a_1\right)$ and $q\left(a_2\right)$. The execution of the procedure is as follows: $p\left(a_1\right),q\left(a_1\right),p\left(a_2\right),q\left(a_2\right)$. In the absence of any conflict, the procedure can be encoded using the commutative logical operator ∧. As multiple state transitions can occur before the execution of the obligation, altering the ASSIGN and ASSOCIATION relations, conflicts may not be detectable until the obligation is executed.

Next, we define causal interference and present the interference rules and the SMT encoding of the interference within an obligation.

6.1. Interference Between Actions

While obligations are synchronized, no other obligation can change the configuration before the obligation completes its actions; an action’s effect within an obligation can affect the preconditions of subsequent actions. We separate actions into two groups: augmentative and reductive. An augmentative action adds either an assignment or association to a configuration relation, while a reductive action removes them from a configuration relation. For example, a reductive action like “delete policy element” will disable the augmentative action “assign” if the policy element is an ancestor or descendant of the former assignment. In this case, both actions are within the same relation, $ASSIGN$. Similarly, actions acting on two different relations can also interfere. The “delete policy element” action will also disable the “grant” action if the policy element is a user attribute or an attribute of the association being added.

To identify actions that cause interference with another action, we perform a static analysis of the actions before encoding. Consider Figure 4, where action $a_1$ has a disabling causal interference $c{i}^{-}\left(a_1\right)$ on action $\left(a_2\right)$. Possible action executions are represented as a binary tree, with each path from event(s,ar,t) to the leaf representing a possible execution path for these two actions. If action $a_1$ is augmentative and action $a_2$ is disabling, we encode the precondition of $a_2$ as a conjunction of interference $c{i}^{-}\left(a_1\right)$ and the precondition of action 2, $p\left(a_2\right)$. If the precondition $p\left(a_1\right)$ is satisfied, then the effect $q\left(a_1\right)$ may interfere with the precondition action $\left(a_2\right)$.

Formally, without disabling conflict(e.g., no $c{i}^{-}\left(a_1\right)$), the actions are represented as follows:

$event(s,ar,t)\Rightarrow p\left(a_1\right)\Rightarrow q\left(a_1\right)\wedge$$p\left(a_2\right)\Rightarrow q\left(a_2\right)$

Now, considering $c{i}^{-}\left(a_1\right)$, the resulting encoding needs a disjunction of two traces: one trace represents the case where disabling causal interference $c{i}^{-}\left(a_1\right)$ does not prevent the effect of action $a_2$. This encoding is presented below:

$event(s,ar,t)\Rightarrow (p\left(a_1\right)\Rightarrow q\left(a_1\right)\wedge c{i}^{-}\left(a_1\right)\wedge$$p\left(a_2\right)\Rightarrow q\left(a_2\right))\vee (p\left(a_1\right)\Rightarrow q\left(a_1\right)\wedge$

$\neg (c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)))$

Of course, the above formula can be further simplified by extracting the independent action as follows:

$event(s,ar,t)\Rightarrow p\left(a_1\right)\Rightarrow q\left(a_1\right)\wedge$$((c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\Rightarrow q\left(a_2\right))\vee \neg (c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)))$

Now let’s consider Figure 5, where three consecutive actions and action $a_1$ affects $a_2$ and $a_3$, while action $a_2$ also affects $a_3$. Each path from the root node event(s, ar, t) to a leaf node represents a possible execution trace conditioned on whether an action’s precondition holds or not. The branching corresponds to evaluating the truth values of preconditions $p\left(a_1\right)$, $p\left(a_2\right)$, and $p\left(a_3\right)$. If $p\left(a_1\right)$ holds, then $q\left(a_1\right)$ executes. However, this may invalidate the precondition of $a_2$, expressed as the interference condition $ci\left(a_1\right)\wedge p\left(a_2\right)$. If $a_2$ is not disabled, then $q\left(a_2\right)$ may also interfere with $a_3$ through another interference condition $ci\left(a_2\right)\wedge p\left(a_3\right)$.

The tree structure explores all combinations of interference or non-interference:

• The leftmost leaf represents the case where $a_1$ and $a_2$ both interfere with $a_3$, and $p\left(a_3\right)$ holds. Hence, $a_3$ executes only if $ci\left(a_1\right)\wedge ci\left(a_2\right)\wedge p\left(a_3\right)$.
• The leaf $\neg (ci\left(a_1\right)\wedge ci\left(a_2\right))\wedge p\left(a_3\right)$ represents the complementary case where at least one interfering condition fails, so $a_3$’s precondition can still hold.
• Other branches show intermediate scenarios, such as $a_1$ interfering but $a_2$ not interfering, or vice versa.

Thus, Figure 5 models all possible interference paths and highlights the cumulative effects of nested conflicts. This interference-aware encoding ensures that verification only considers sound execution traces during bounded reachability analysis.

In the absence of disabling conflicts, the actions are formulated as follows:

$event(s,ar,t)\Rightarrow p\left(a_1\right)\Rightarrow q\left(a_1\right)\wedge$$p\left(a_2\right)\Rightarrow q\left(a_2\right)\wedge$ $p\left(a_3\right)\Rightarrow q\left(a_3\right)$

The formalization of the actions with conflicts is as follows:

$event(s,ar,t)\Rightarrow$

$(p\left(a_1\right)\Rightarrow q\left(a_1\right))\wedge (c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\Rightarrow q\left(a_2\right))\wedge$

$(c{i}^{-}\left(a_1\right)\wedge ci\left(a_2\right)\wedge p\left(a_3\right)\Rightarrow q\left(a_3\right))\vee (\neg (c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right))\wedge$

$(c{i}^{-}\left(a_1\right)\wedge p\left(a_3\right)\Rightarrow q\left(a_3\right)))\vee (\neg (c{i}^{-}\left(a_2\right)\wedge p\left(a_3\right))\wedge$

$(c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\Rightarrow q\left(a_2\right)))\vee (\neg (c{i}^{-}\left(a_1\right)\wedge c{i}^{-}\left(a_2\right)))$

The reason why encoding multiple traces is essential for accurately encoding NGAC obligations is due to the fluidity of the policy resulting from the obligation. It is unknown whether a conflict will occur before the obligation is triggered, and this depends on the configuration before the obligation is executed.

6.2. Interference Rules: Enabling Actions

In the previous subsection, we presented several examples of disabling causal interference between actions. This subsection describes every enabling causal interference using the configuration modification set defined below:

Definition 5

(configuration modification set). The configuration modification set (CMS) is a function of the action’s effect and the configuration relation changed by the action, which produces a subset of assignments or associations that are either added or removed by the effect, formally CMS(a, RELATION).

To find a correct interference, we utilize policy elements of the actions and the configuration modification set, which are extracted during the actions’ encoding phase and available for the analysis and encoding of the interference. For example, if there is an action “$assign(x_1,y_1)$” followed by “$removeassign(x_2,y_2)$”, the causal interference of action $a_1$ on action $a_2$ is as follows: $c{i}^{+}\left(a_1\right)=(x_2,y)\in CMS(assign(x_1,y_1),ASSIGN)$ $\wedge y\ne y_2$, because CMS may contain the assignment $(x_2,y),y\ne y_2$, enabling a “remove assign” action as it requires an ancestor to have at least one other assignment. Such a condition of “at least one other assignment” is a guard (G). Therefore, we consider such interference enabling, as “assign” enables a “remove assign” action. The path condition for the enabling interference is $G\vee c{i}^{+}\left(a_1\right)$, meaning that either the guard has to already be true before the former “assign” action execution or ci should be true, enabling the consequent “remove assign” action. Clearly, if the former action “assign” does not execute, the CMS will be empty, and therefore, ci will evaluate to false and the path condition will only rely on G. This approach avoids the need to build execution trees while conveniently utilizing CMS, which is calculated during the execution of actions. Below, we explain each enabling interference rule we use in our analysis.

6.2.1. Remove Assign Action Enables Assign Action

Given a remove assign action $a_1$, “$remove$ $assign(x_1,y_1)$” followed by an assign action $a_2$, “$assign(x_2,y_2)$”, the causal interference affecting $a_2$ is represented as follows:

$c{i}^{+}\left(a_1\right)=(x_2,y_2)\in$$CMS(removeassign(x_1,y_1),ASSIGN)\vee$ $(y,x_2)\in CMS(removeassign(x_1,y_1),ASSIG{N}^{\ast })$

The left part of the disjunction represents removing an assignment that will be created; therefore, the precondition of $(x_2,y_2)$ must not be fulfilled before the execution of action $assign(x_2,y)$. The right part fulfills the precondition that no circular implicit or explicit assignment is allowed; hence, $CMS$ is based on $ASSIG{N}^{\ast }$.

6.2.2. Create Policy Element Action Enables Remove Assign Action

Given a create policy element action $a_1$, creating policy element $x_1$ contained by $y_1$, followed by a remove assign action $a_2$, removing the assignment $x_2,y_2$, the causal interference affecting $a_2$ is as follows: $c{i}^{+}\left(a_1\right)=(x_2,y)\in CMS(createpolicyelement(x_1,y_1),ASSIGN)\wedge$ $y\ne y_2$.

The causal interference may enable $a_2$ because the ancestor of the deleted assignment, in this case, $x_2$, must be contained by another policy element to remove the assignment, and $a_1$ may create such an assignment $(x_2,y)$. While it may seem that $x_1$ is necessarily equal to $x_2$, this may not always be true. NGAC obligations have standard $current\_user$ and $current\_target$ built-in functions that we also encode. These functions dynamically retrieve the user executing an event, triggering the obligation and the policy element on which the action was executed. Therefore, while $x_1$ may equal $x_2$, there may be execution paths where they are not equal, and causal interference will not enable $a_2$.

6.2.3. Create Policy Element Actions Enable Grant Action

Given a create policy element action $a_1$, creating a policy element $x_1$ contained by $y_1$, followed by a grant action $a_2$, creating an association $(x_2,ar,y_2)$, the causal interference affecting $a_2$ is as follows:

$c{i}^{+}\left(a_1\right)=(x_1=x_2\vee x_1=y_2)$

This conflict represents an interesting case where a preceding action affects the action that changes a different relation (in this case, $ASSOCIATE$). Therefore, our algorithm, presented in Section 6.4, analyzes both interfering actions of the same type and those where the type differs. Also, this is one of the cases where CMS is not utilized in calculating $ci$.

6.2.4. Delete Policy Element Actions Enable Create Policy Element Action

Given a delete policy element action $a_1$, removing the policy element $x_1$, and a create policy element action $a_1$, creating policy element $x_2$ contained by $y_2$, the causal interference affecting $a_2$ is represented as follows:

$c{i}^{+}\left(a_1\right)=(x_1=x_2)$

This interference represents perhaps the most straightforward conflict, where deleting a policy element enables the creation of a policy element, as the policy element is not a duplicate anymore.

6.2.5. Grant Action Enables Remove Grant Action

Given a grant action $a_1$, creating an association $(x_1,\{a{r}_1,a{r}_2,\dots a{r}_n\},y_1)$, followed by a delete grant action $a_2$, deleting an association $(x_2,ar,y_2)$, the causal interference affecting $a_2$ is as follows:

$c{i}^{+}\left(a_1\right)=((x_2,ar,y_2)\in CMS\left(remove\right(grant$$x_1,\{a{r}_1,a{r}_2,\dots a{r}_n\},y_1),ASSOCIATE)$

In the above formula, $ci$ represents the predicate where $a_1$ creates an association with access rights $\{a{r}_1,a{r}_2,\dots a{r}_n\}$ and the consequent $a_2$ deletes either some access rights created by $a_1$ or the created association entirely.

6.2.6. Delete Grant Action Enables Grant Action

Given a delete grant action $a_1$, deleting an association $(x_1,\{a{r}_1,a{r}_2,\dots a{r}_n\},y_1)$, followed by a grant action $a_2$, creating an association $(x_2,\left\{ar\right\},y_2)$, the causal interference affecting $a_2$ is as follows:

$c{i}^{+}\left(a_1\right)=((x_2,ar,y_2)\in CMS\left(grant\right(x_1,\{a{r}_1,$$a{r}_2,\dots a{r}_n\},y_1),ASSOCIATE)$

Similarly to the previous case, the conditional interference is based on the association of the previous action. $a_1$ may enable the association created by $a_2$ by deleting the previous action.

As all the above cases handle enabling causal interference, the complete precondition in each of the described cases of $a_2$ becomes $c{i}^{+}\left(a_1\right)\vee p\left(a_2\right)$, meaning that either the precondition (based on the RELATION of the previous step) is true or the enabling interference (based on changes in the previous action) is true.

6.3. Interference Rules: Disabling Actions

Similarly to enabling interference, a disabling interference calculation also relies on policy elements and CMS. For example, a “create policy element” action, which creates a policy element $x_1$ and assigns it to a specified descendant $y_1$, may disable the consequent “$assign(x_2,y_2)$” action, which may create a duplicate assignment, or it may lead to a cycle within the configuration. The G of the “assign” action is $(x_2,y_2)\notin ASSIGN\wedge (y_2,x_2)\notin ASSIG{N}^{\ast }$, meaning that there cannot be a conflicting assignment, and $x_2$ should not be contained by $y_2$; otherwise, the assignment will produce a cycle. Therefore, the causal interference is $(x_2,y_2)\notin CMS\left(assign\right(x_1,$ $y_1),ASSIGN)\wedge (y_2,x_2)\notin CMS(assign(x_1,y_1),$$ASSIG{N}^{\ast })$. Every action that produces disabling interference has the following execution path condition: $G\wedge c{i}^{-}\left(a_1\right)$. Note that, unlike in enabling interference, the execution path must contain the conjunction of the guard and the causal interference because both G and ci must be satisfied for an action to be executed, unlike with enabling action, where either G or ci must be true for an action to be eligible for execution.

6.3.1. Assign Action Disables Assign Action

Given an assign action $a_1$, “$assign(x_1,y_1)$”, followed by an assign action $a_2$, “$assign(x_2,y_2)$”, the causal interference affecting $a_2$ is represented as follows:

$c{i}^{-}\left(a_1\right)=(x_2,y_2)\notin CMS(assign(x_1,y_1),$ $ASSIGN)\wedge (y,x_2)\notin CMS(assign(x_1,y_1),$ $ASSIG{N}^{\ast })$

The left part of the conjunction checks for duplicate assignment; therefore, the precondition of $(x_2,y_2)$ must not be fulfilled before the action $assign(x_2,y)$ is executed. The right part fulfills the precondition that no circular implicit or explicit assignment is allowed; hence, $CMS$ is based on $ASSIG{N}^{\ast }$.

6.3.2. Remove Assign Action Disables Remove Assign Action

Given a remove assign action $a_1$, “$remove$ $assign(x_1,y_1)$”, followed by a remove assign action $a_2$, “$removeassign(x_2,y_2)$”, the causal interference affecting $a_2$ is represented as follows:

$c^{-}\left(a_1\right)=(x_2,y)\notin CMS(removeassign(x_1,y_1),$ $ASSIGN)\wedge y\ne y_2$

The above condition represents a case where $a_1$ deletes a possible next-to-last remaining assignment of the ancestor $x_2$. This case arises, and the descendants of both actions are different.

6.3.3. Delete Policy Element Action Disables Remove Assign Action

Now consider a delete policy element action $a_1$, removing the policy element $x_1$, followed by a remove assign action $a_2$, removing the assignment $x_2,y_2$, demonstrated as follows:

$c{i}^{-}\left(a_1\right)=(x_2,y)\notin CMS(deletepolicyelement$$\left(x_1\right), ASSIGN)\wedge y\ne y_2$

Like the previous conflict, $a_1$ may delete a possible next-to-last remaining assignment of the ancestor $x_2$.

6.3.4. Delete Policy Element Action Disables Grant Action

Given a delete policy element action $a_1$, removing the policy element $x_1$, followed by grant actions $a_2$ and $a_1$, creating an association $(x_2,\left\{ar\right\},y_2)$, $ci$ is a follows:

$c{i}^{-}\left(a_1\right)=(x_1\ne x_2\wedge x_1\ne y_2)$

This interference occurs when a preceding action deletes a policy element of the association, preventing the grant action from being executed.

Notably, unlike other types of disabling interference, this conflict involves both an augmentative and a reductive action, which does not adhere to Definition 4 and is treated as an exception, where all disabling interference rules should involve actions of the same type. We treat this as a special case.

6.3.5. Grant Action Disables Grant Action

Given a grant action $a_1$, creating an association $(x_1,\left\{ar\right\},y_1)$, followed by grant action $a_2$, creating an association $(x_2,ar,y_2)$, the causal interference disabling $a_2$ is as follows:

$c{i}^{-}\left(a_1\right)=((x_2,ar,y_2)\notin CMS(grant(x_1,\left\{ar\right\},y_1),$ $ASSOCIATE)$

This causal interference represents the possible creation of a duplicate association by $a_1$ before the execution of $a_2$.

6.3.6. Delete Grant Action Disables Delete Grant Action

Given a grant action $a_1$, deleting an association $(x_1,\left\{ar\right\},y_1)$, followed by a delete grant action $a_2$, deleting an association $(x_2,ar,y_2)$, the causal interference disabling $a_2$ is as follows:

$c{i}^{-}\left(a_1\right)=((x_2,ar,y_2)\notin CMS\left(deletegrant\right(x_1,$$\left\{ar\right\},y_1),ASSOCIATE)$

This causal interference describes the case where an association is removed before removing the association again, stopping the consequent action $a_2$ from being executed.

6.4. Interference Encoding

To encode the causal interference, we exploit the fact that the actions within obligations are sequential, and the sequence does not change. Therefore, our preprocessing algorithm is bounded by a time complexity of $O\left(n^2\right)$ and space complexity of $O\left(n\right)$. In the algorithm, we process each action once and save the prerequisite, a collective term for CMS(a, relationType) and actionType, in a list of all prerequisites. During each iteration, the algorithm uses all prerequisites found so far and calculates the causal interference of the current action using rules described in the previous subsection. As there is a possibility that all prerequisites will impact the consecutive actions and the algorithm will have to find causal interference based on the prerequisites found so far (e.g., the series of prerequisites applied at each step is 1 + 2 + 3 + … + n), the time complexity will be bound by $O\left(n^2\right)$. Since one prerequisite is extracted per action, the space complexity is bound by $O\left(n\right)$, where n is the number of obligations. Note that the presented time complexity is only for the preprocessing of actions. The time complexity of reachability analysis will remain exponential, as previously described.

Algorithm 2 describes the procedure of encoding the causal interference. Prerequisites represent an ordered list of attributes that describe an action, such as the configuration modification set (a relation that the action modifies), the relation type, and the action type. The outer loop (lines 2–15) iterates over all the actions within an obligation, saving the action attributes. These attributes will be used to calculate causal interference within the inner loop (lines 5–12). The causal interference is calculated according to the rules described in the previous section based on each prerequisite extracted from the preceding actions. The first conditional (lines 6–8) describes enabling causal interference encoding, where the action type of the action and the action of the prerequisite differ, while the next conditional (lines 9–11) describes disabling causal interference encoding, where the action type is the same. The causal interference is amended to the precondition as a conjunction or disjunction based on the action type, as demonstrated. Finally, line 14 adds the prerequisite of the current action to the list of prerequisites to encode the subsequent actions. The prerequisite of the current action will not be used on itself.

Algorithm 2: Conditional interference encoder

To encode possibly interfering actions, we first extract the configuration modification set (CMS) from the preceding action (1st action). The CMS describes the change in the configuration in terms of relations that are added or removed from the assignments or associations. Using the CMS, we find a causal interference that may occur in every subsequent action (second action). Such interference varies between actions and depends on the guard (or condition) of the subsequent action. There may be multiple types of guards. Additionally, if an action has a user-specified condition, that condition becomes part of the guard. After the causal interference is found and appended as a part of the actions’ precondition, we encode the obligation traces as a disjunction of all the obligation action traces. The encoding of obligation $\varphi$ with actions $a_1$ and $a_2$, where $a_1$ affects $a_2$ and both actions are of relation type ASSIGN with the same action type, “augmentative” (e.g., add assignment), is as follows:

$\psi$$\left(\right[RESPONSE($$\varphi$${\left)\right]}_k)=p\left(a_1\right)\Rightarrow$$ASSIG{N}_{a_1}=CMS(a_1,ASSIGN)\wedge$

$(c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\wedge ASSIG{N}_{a_2}=\varnothing )\vee$$(\neg c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right))\Rightarrow$

$ASSIG{N}_{a_2}=CMS(a_2,ASSIGN)\left)\right)$

Note the distinction between CMS(a, ASSIGN) and $ASSIG{N}_a$. The former is constant and represents the set being modified by the action. The latter is variable, can be empty if the action’s condition is not satisfied, and will be equal to CMS(a, ASSIGN) if the action is executed. Afterward, we combine the changes executed by $a_1$ and $a_2$ and the encoding of $ASSIG{N}_{k+1}$ by either performing a union or set minus operation, depending on whether the action type is augmentative or reductive. In this case, both actions are augmentative:

$\psi$$\left({\left[ASSIGN\right]}_{k+1}\right)={\left[ASSIGN\right]}_k\cup$$(ASSIG{N}_{a_1}\cap ASSIG{N}_{a_2})$

Similarly, when there are three actions, $a_1$ affects $a_2$ and $a_3$, and action $a_3$ is reductive, the response encoding is as follows:

$\psi$$\left(\right[RESPONSE($$\varphi$${\left)\right]}_k)=p\left(a_1\right)\Rightarrow ASSIG{N}_{a_1}=CMS(a_1,ASSIGN)\wedge$

$(c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\wedge ASSIG{N}_{a_2}=\varnothing )\vee$

$(\neg c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\Rightarrow ASSIG{N}_{a_2}=CMS(a_2,ASSIGN))\wedge$

$(\neg ci\left(a_1\right)\wedge \neg p\left(a_3\right))\wedge ASSIG{N}_{a_3}=\varnothing )\vee$

$(c{i}^{+}\left(a_1\right)\vee p\left(a_3\right))\Rightarrow ASSIG{N}_{a_3}=CMS(a_3,ASSIGN))$

Now, because $a_3$ is reductive, the ${\left[ASSIGN\right]}_{k+1}$ encoding becomes as follows:

$\psi$$\left({\left[ASSIGN\right]}_{k+1}\right)={\left[ASSIGN\right]}_k\cup$$(ASSIG{N}_{a_1}\cap ASSIG{N}_{a_2})\setminus ASSIG{N}_{a_3}$

When the action ASSIGN is related, we must calculate the causal interference for the flattened version of the assign relation, $ASSIG{N}^{\ast }$. The encoding of $ASSIG{N}^{\ast }$ is similar to the above; however, the configuration modification set, $CM{S}^{\ast }$, is more complex as it captures the change in the ASSIGN relation and the changes that occur due to the containment relation within $ASSIG{N}^{\ast }$. For the above example, the encoding is as follows:

$\psi$$\left(\right[RESPONSE($$\varphi$${\left)\right]}_k)=p\left(a_1\right)\Rightarrow$

$ASSIG{N}_{a_1}^{\ast }=CMS(a_1,ASSIG{N}^{\ast })\wedge$

$(c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\wedge ASSIG{N}_{a_2}^{\ast }=\varnothing )\vee$

$(\neg c{i}^{-}\left(a_1\right)\wedge p\left(a_2\right)\Rightarrow ASSIG{N}_{a_2}^{\ast }=$

$CMS(a_2,ASSIG{N}^{\ast }))\wedge$

$(\neg ci\left(a_1\right)\wedge \neg p\left(a_3\right))\wedge ASSIG{N}_{a_3}^{\ast }=\varnothing )\vee$

$(c{i}^{+}\left(a_1\right)\vee p\left(a_3\right))\Rightarrow ASSIG{N}_{a_3}^{\ast }=CM{S}^{\ast }(a_3,$$ASSIGN\left)\right)$

And the ${\left[Assig{n}^{\ast }\right]}_{k+1}$ encoding is as follows:

$\psi$$\left({\left[ASSIG{N}^{\ast }\right]}_{k+1}\right)={\left[ASSIG{N}^{\ast }\right]}_k\cup$$((ASSIG{N}_{a_1}^{\ast }\cap ASSIG{N}_{a_2}^{\ast })\setminus ASSIG{N}_{a_3}^{\ast })$

Due to the changes in containment relations caused by assignment-related actions, the presence or absence of causal interference cannot be predicted before the obligation is executed. Therefore, the encoding of execution traces with and without interference is crucial. Importantly, we are not attempting to find the interference; we only aim to encode the actions correctly. The interference can then be found using the properties within our reachability analysis.

It is important to note that Algorithm 2 and the corresponding interference encoding do not constitute a decision procedure for detecting interference. Rather, the goal of the encoding is to conservatively capture all possible causal interference scenarios that may arise in the execution of obligations. The SMT constraints simply ensure that interfering paths are not prematurely excluded from the reachability formulation.

Because the interference encoding is structural and syntactic, based solely on the configuration modification sets and action attributes, it is not necessary to prove its soundness or completeness in a semantic sense. The correctness of the overall analysis is instead deferred to the reachability analysis itself, which operates over the fully encoded transition space. In this context, interference constraints serve as symbolic guards within SMT formulas and are not required to be semantically minimal. Thus, the correctness is subsumed under the soundness and completeness of the bounded reachability encoding presented in Section 4.4.

7. Case Studies

Our approach was based on the Java-based NGAC reference implementation [36] and the cvc5 solver. This section applies the approach to two NGAC policies, GPMS and LawFirm, from the recent literature [10,37].

7.1. The NGAC Applications

GPMS is the first fully fledged open-source NGAC application that utilizes obligations to address runtime privilege changes [37]. It automates an academic institution’s grant proposal approval workflow, involving various users such as faculty members (principal investigators/PIs; co-investigators/Co-PIs; and senior personnel/SP), department chairs, deans, business managers, IRB officers, and research administrators. Such workflows exist in many other domains, such as healthcare and finance.

GPMS has 30,249 lines of Java code. Its policy has four policy classes and 19 obligations. Each proposal data sheet (PDS) carries its own policy instance, where the configuration depends on the workflow status and the users involved. Consider a small portion of the workflow: a principal investigator (PI)-eligible faculty member initiates a PDS, works with CoPI and senior personnel (SP) users (added and deleted dynamically), edits the PDS, and submits it for approval by all PI and CoPI chairs (added and deleted dynamically).

LawFirm is an NGAC policy for case tracking at a law firm. Many law firms utilize case tracking systems to manage cases, billing, and file sharing. A law firm has attorneys of various ranks (lead attorneys and available attorneys), each with distinct access privileges. The dynamic changes are carried out via obligations. LawFirm has one policy class with two hierarchies of attributes. The user attribute hierarchy deals with the employees, and the object attribute hierarchy manages the cases. Unlike GPMS, LawFirm has no application code.

7.2. Conflict Identification in Verification of Access Control Requirements

For GPMS, we analyzed 197 requirements, and for LawFirm, we analyzed 92 requirements. As it is not hard to ensure the correctness of initial configurations, we focused on the obligation requirements. The primary goal was to verify the access control requirements arising from conflicting actions.

For example, consider the following example of a disabling action from a real-world faulty scenario:

• Event: A PI user performs deleteCoPI on the PDS’s CoPI data.
• Response:
  (1) Delete policy element copiuser;
  (2) Delete assignment (ChairFor(copiuser), Chair);
  (3) Delete assignment (BMFor(copiuser),BM);
  (4) Delete assignment (DeanFor(copiuser), Dean).

Let us break down the actions of the above scenario into preconditions (p) and effects (q).

1.

$p\left(delete\right(copiuser\left)\right)=copiuser\in U\cup UA\cup$ $OA\cup PC\wedge (copiuser\notin UA\cup OA)\vee$

$(copiuser\in UA\cup OA\wedge (p{e}_2,copiuser)\in$ $ASSIGN\wedge (p{e}_2,at)\in ASSIGN\wedge pe\ne at\left)\right)$

$q\left(delete\right(copiuser\left)\right)=copiuser\notin PE$;

2.

$p\left(removeassign\right(ChairFor\left(copiuser\right),Chair)=$ $copiuser\in PE\wedge$

$\left(ChairFor\right(copiuser),Chair)\in ASSIGN$

$q\left(removeassign\right(ChairFor\left(copiuser\right),Chair)=$ $\left(ChairFor\right(copiuser),Chair)\notin ASSIGN$;

3.

$p\left(removeassign\right(BMFor\left(copiuser\right),BM)=$ $copiuser\in PE\wedge$

$\left(BMFor\right(copiuser),BM)\in ASSIGN$

$q\left(removeassign\right(BMFor\left(copiuser\right),BM)=$ $\left(BMFor\right(copiuser),BM)\notin ASSIGN$;

4.

$p\left(removeassign\right(DeanFor\left(copiuser\right),Dean)=$ $copiuser\in PE\wedge$

$\left(DeanFor\right(copiuser),Dean)\in ASSIGN$

$q\left(removeassign\right(DeanFor\left(copiuser\right),Dean)=$ $\left(DeanFor\right(copiuser),Dean)\notin ASSIGN$.

In the above scenario, action (1) disables actions (2), (3), and (4) because by performing the delete policy element copiuser, it invalidates the common precondition of the action $copiuser$ $\in PE$, as the copiuser must exist to find their chair, business manager, and dean. This is an example of a disabling action. This particular policy error could be fixed by making action (1) the last action. The following access control requirements can be used to detect this error:

$g_{pre}=contains(ChairFor(?copiuser),Chair)\wedge$$contains\left(BMFor\right(?copiuser),BM)\wedge$

$contains\left(DeanFor\right(?copiuser),Dean)$

$goalObligation(s,ar,t)=$$deleteCoPI(?piuser,deleteCoPI,?copiuser);$

$g_{post}=contains(ChairFor(?copiuser),Chair)\wedge$$contains\left(BMFor\right(?copiuser),BM)\wedge$

$contains\left(DeanFor\right(?copiuser),Dean)$

The above property verifies that if $ChairFor(?copiuser)$, $BMFor(?copiuser)$, and $DeanFor(?copiuser)$ are still contained by the respective attributes, the chair, BM, and dean, after the obligation $delete\_copi$ runs, this means that actions (2), (3), and (4) were disabled due to conflict with action (1).

An example of an enabling action is demonstrated below:

• Event: A PI user performs addSP on the PDS’s SP data.
• Response:
  (1) Create policy element $spuser$ in $SPEligibleFaculty$;
  (2) Assign $spuser$ to SP if $spuser$ is eligible (i.e., is contained by $SPEligibleFaculty$).

Similarly, the precondition and effect are demonstrated below:

1.

$p\left(create\right(spuser,SPEligibleFaculty\left)\right)=$$(spuser,SPEligibleFaculty)\notin ASSIGN$

$q\left(create\right(spuser,SPEligibleFaculty\left)\right)=$ $(spuser,SPEligibleFaculty)\in ASSIGN$;

2.

$p\left(assign\right(spuser,SP\left)\right)=$$(spuser,SPEligibleFaculty)\in ASSIGN$

$q\left(assign\right(spuser,SP\left)\right)=$ $(spuser,SP)\in ASSIGN$.

Here, action (1) is enabling as it enables the precondition of action (2) $(spuser,$ $SPEligibleFaculty)$ $\in ASSIGN$ by creating a policy element contained by SPEligibleFaculty. In this case, the enabling interference does not represent an error and is intentional because in order to assign $spuser$ to $SP$ attribute, this user needs to be eligible to be $SP$. To verify the correctness of this obligation, it is enough to simply check whether $spuser$ is contained by attribute $SP$ after obligation addSP is triggered:

$goalObligation(s,ar,t)=$$addSP(?piuser,addSP,?spuser);$

$g_{post}=contains(?spuser,SP)$

As discussed in Section 2, most prior methods rely on bounded model checking or specialized reachability analyses to verify administrative changes such as user–role assignments (URA), role–role assignments (RRA), permission–role assignments (PRA), inverse role reachability (iRR), and object permissions (O). These approaches typically assume a centralized administrator making predefined changes, without capturing real-time, user-triggered administrative events.

In contrast, the case studies in this section and the next section demonstrate that our SMT-based verification method supports policies in which relations similar to URA, RRA, PRA, and iRR emerge dynamically as part of user-driven obligations. Our approach verifies these changes not in isolation but as part of complex obligation chains triggered by real-world events. Both the GPMS and LawFirm workflows exhibit dynamic creation and deletion of users, hierarchical changes, and access grants, capturing the semantics of URA, RRA, and PRA, all controlled via obligations rather than static administrative actions.

Thus, our work not only statically verifies access control properties but also supports full verification of dynamic, user-initiated administrative workflows. This makes our contribution fundamentally more expressive and realistic for modern distributed systems. The ability to analyze obligations with conflicting actions further distinguishes our approach.

8. Scalability Analysis

To analyze the scalability of our approach, we created several GPMS test policies. These policies are described in

Table 3. GPMS synthetic policies.

Policy	No. of Assignments	No. of Assignments*	No. of Obligations (Assign/Grant)
$GPM{S}_{assign}$	25	39	6/0
$GPM{S}_{assign+grant}$	27	46	3/11
$GPM{S}_{grant}$	27	46	19

in terms of the number of assignments, flattened assignments, access rights, and obligations (we separate assignment- and association-related obligations as assign actions are significantly more complex due to hierarchical changes). Each obligation has up to five actions, with at least two conflicting actions.

For each policy, we conducted several experiments where we performed a reachability analysis and attempted to trigger a particular obligation within the provided number of steps (horizon). We recorded the cvc5 solver’s output, the time, and the lines of the generated SMT code. The experiments were conducted with 16GB of memory and six Intel Core i7 8th Gen 2.2GHz cores. In the policy with no hierarchical changes and changes only to the associations, $GPM{S}_{grant}$, we reached a horizon of 15, meaning that 15 obligations were triggered consecutively. The changes to association relations are the most anticipated ones in any workflow (e.g., it is easier to grant or remove an access right without complex changes to the attribute hierarchy). While changes to assignment relations should be avoided, they may occur in certain workflows. Therefore, we also present $GPM{S}_{assign+grant}$, where three obligations change assignments and eleven change the association relation. With this policy, we achieved a horizon of 12 within the time allotted. The hardest policy, $GPM{S}_{assign}$, had obligations that only changed the assignment relation. With this policy, we achieved a horizon of 5. However, several hierarchical changes within a workflow are highly unlikely in the production system. We also consider the number of facts inferred by cvc5 to measure the relative complexity of the task. Fact inference is a conclusion that the solver draws during its reasoning. For example, if the solver determines that a specific element must be a member of a particular set, that would be an inferred fact within set theory. We provide the lines of code (LOC) generated by our algorithm for reference. The complete results for each policy are presented in

Table 4. $GPM{S}_{assign}$.

Horizon	Time (seconds)	No. of LOC	No. of Total Facts Inferred
1	31	549	11,597
2	98	956	53,072
3	247	1405	140,319
4	531	1896	284,934
5	962	2429	597,475

,

Table 5. $GPM{S}_{grant}$.

Horizon	Time (Seconds)	No. of LOC	No. of Total Facts Inferred
1	1	1300	2
2	3	2533	12
3	5	3906	188
4	8	5419	350
5	13	7072	560
6	23	8865	906
7	33	10,798	1349
8	43	12,871	1899
9	64	15,084	2711
10	124	17,437	4043
11	130	19,930	4345
12	242	22,527	6312
13	411	25,336	11,532
14	976	28,249	15,028
15	1,027	31,302	23,710

and

Table 6. $GPM{S}_{assign+grant}$.

Horizon	Time (Seconds)	No. of LOC	No. of Total Facts Inferred
1	22	1023	15,472
2	73	1963	32,879
3	88	3009	64,759
4	104	4160	87,900
5	145	5416	132,315
6	287	6777	205,759
7	487	8243	431,797
8	641	9814	520,835
9	766	11,490	599,813
10	789	13,271	614,909
11	991	15,147	777,150
12	1484	17,248	1,131,463

.

9. Conclusions

We have presented an approach for analyzing the action interference of administrative obligations for an SMT-based verification. Unlike previous access control models, in NGAC, policies can be altered dynamically in response to access requests that match the obligation’s event. While obligations allow the policies to be more expressive and dynamic, they also introduce unique challenges. Our work presents a comprehensive analysis of the interdependencies among obligatory actions, where an action can both enable and disable other actions within an obligation. This requires careful encoding of the precondition and effect of each NGAC action, as well as analysis of their interactions within an obligation. Using the causal interference encoder algorithm and our proposed interference rules, we could encode and analyze these interdependencies as SMT formulas. The case studies demonstrate that the proposed approach can identify various errors in the event and response to obligations.

The presented approach is particularly relevant in systems where dynamic policy updates can introduce significant security risks, such as privilege escalation or denial-of-service. These risks arise in cloud environments, enterprise identity and access management platforms, and zero-trust architectures, where obligations or similar mechanisms are used to automate policy changes in response to specific events. Our approach enables precise analysis of such obligations to ensure that administrative actions do not inadvertently interfere with each other, helping to detect and prevent unsafe policy transitions before deployment.

Regarding future work, we aim to extend our methodology for encoding obligations to perform model checking of NGAC policies against intricate properties, such as those expressed in linear temporal logic. Additionally, we are interested in exploring the use of Large Language Models (LLMs) to generate NGAC policies and applying model checking techniques to identify potential hallucinations and errors within the generated policies. The increasing potential of smaller LLMs running on local servers makes it feasible to generate such policies without transferring access control requirements over the Internet. This approach aims to reduce the time administrators spend on policy design, allowing them to focus more on quality assurance.