Sema Policy Engine ↔ Spring Security 6: Compatibility and Nested Policy Evaluation Order

Direct Answer

1. Module visibility: If sema-1.2.jar contains no module-info.class, it becomes an automatic module and is visible to a modular Spring Boot app as long as automatic modules are not excluded by the module‑path. If a module-info is present, you must add a requires sema.engine; directive or export the relevant packages.

2. Deterministic evaluation: Sema’s core API offers no ordering guarantee for nested policies. The only way to enforce a deterministic sequence is to wrap the PolicyResolver in a custom Spring Security AuthorizationManager that sorts policy identifiers (e.g., alphabetically or by explicit priority metadata) before delegating to resolve().

3. Spring Security 6 workarounds: There is no built‑in flag to influence Sema’s traversal order. The recommended approach is the wrapper described above, or to add explicit priority annotations to policy definitions and implement a comparator that orders them before evaluation.

Assumptions & Uncertainty

• The Sema jar is packaged without a module descriptor (most releases are automatic modules).
• Application uses the Java 17 module system; if it is classpath‑only, module‑system concerns disappear.
• Policy definitions can be annotated with a numeric or string priority; if not, you must add this metadata.

Verification Steps

1. Check for a module descriptor

   jar tf sema-1.2.jar | grep module-info.class
   

   • If the output is empty, the jar is an automatic module.
   • Otherwise, note the module name and add a requires statement in your module-info.java.

2. Test module visibility

   java --module-path target/modules -m com.example.app/com.example.Main
   

   • Observe whether ClassNotFoundException occurs for Sema classes. If so, add the appropriate requires or export directive.

3. Confirm nondeterminism

   // Pseudo-test harness
   Policy p1 = new Policy("A", List.of("B"));
   Policy p2 = new Policy("B", List.of("A"));
   SemaResolver resolver = new SemaResolver();
   resolver.evaluate(p1); // log call order
   resolver.evaluate(p1); // log call order
   

   • Compare the logged order of calls; if it differs, nondeterminism is present.

4. Implement deterministic wrapper

   public class OrderedAuthorizationManager implements AuthorizationManager<Authentication> {
       private final PolicyResolver resolver;
   
       public OrderedAuthorizationManager(PolicyResolver resolver) {
           this.resolver = resolver;
       }
   
       @Override
       public AuthorizationDecision check(Authentication authentication, Object object) {
           List<String> policyIds = extractPolicyIds(object);
           policyIds.sort(Comparator.naturalOrder()); // or custom priority comparator
           for (String id : policyIds) {
               resolver.resolve(id, authentication, object);
           }
           return AuthorizationDecision.PERMIT;
       }
   }
   

Missing Diagnostic Detail

To fine‑tune the recommendation, could you confirm whether your Spring Boot project is built against the Java module system (module‑path) or remains classpath‑based? This affects whether the automatic module visibility step is required.