End-to-End Dynamic Authorization Workflow

Why This is Revolutionary

Traditional Spring Security often forces developers to hardcode authorization rules directly in Java configuration. Every new endpoint, every role change, every permission tweak can require a code change, a rebuild, and a redeployment. Contexa moves that operational burden toward runtime-managed policies, while still allowing static matchers where they are intentionally needed.

Traditional vs. Contexa Approach

http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/api/admin/**")
        .hasRole("ADMIN")
    .requestMatchers("/api/users/**")
        .hasAuthority("READ_USERS")
    .requestMatchers("/api/reports/**")
        .hasAnyRole("ADMIN", "ANALYST")
    .requestMatchers("/api/orders/**")
        .hasAuthority("MANAGE_ORDERS")
    .requestMatchers("/api/settings/**")
        .hasRole("SUPER_ADMIN")
    .requestMatchers("/api/audit/**")
        .hasAuthority("VIEW_AUDIT_LOG")
    // ... 20+ more lines
    .anyRequest().authenticated()
);

http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/css/**", "/js/**")
        .permitAll()
    .anyRequest()
        .access(customDynamicAuthorizationManager)
);

Key Advantages

Complete Workflow Overview

The dynamic authorization system operates as a five-stage pipeline. Each stage maps to a concrete runtime component, from scanner registration through policy persistence and request-time enforcement.

The following sections walk through four real-world scenarios demonstrating this pipeline in action.

Scenario 1 —Protecting a New API Endpoint

You have written a new REST controller and want it dynamically protected without touching your security configuration.

@RestController
@RequestMapping("/api/v1/invoices")
public class InvoiceController {

    @GetMapping
    public List<InvoiceDto> listInvoices() {
        return invoiceService.findAll();
    }

    @PostMapping
    public InvoiceDto createInvoice(@RequestBody CreateInvoiceRequest req) {
        return invoiceService.create(req);
    }

    @DeleteMapping("/{id}")
    public void deleteInvoice(@PathVariable Long id) {
        invoiceService.delete(id);
    }
}

Policy: "Invoice Deletion - Restricted"
  Target:   DELETE:/api/v1/invoices/{id}
  Effect:   ALLOW
  Roles:    ADMIN
  Conditions:
    - Time:  weekdays 09:00-18:00 only
    - IP:    internal network (10.0.0.0/8)
    - AI:    #ai.hasActionIn('ALLOW', 'CHALLENGE')

Scenario 2 —Protecting a Business Method

Beyond URL-level authorization, Contexa supports method-level protection using the @Protectable annotation. This enables fine-grained access control on individual service methods with ownership semantics.

@Service
public class DocumentService {

    @Protectable(ownerField = "createdBy")
    public Document getDocument(Long documentId) {
        return documentRepository.findById(documentId)
            .orElseThrow(() -> new NotFoundException("Document not found"));
    }

    @Protectable(ownerField = "createdBy")
    public void updateDocument(Long documentId, UpdateDocumentRequest req) {
        Document doc = documentRepository.findById(documentId)
            .orElseThrow(() -> new NotFoundException("Document not found"));
        doc.setTitle(req.getTitle());
        doc.setContent(req.getContent());
        documentRepository.save(doc);
    }
}

Policy: "Document Update - Owner or Admin"
  Target:   DocumentService.updateDocument
  Effect:   ALLOW
  Rules:
    Rule 1 (Owner Access):
      Condition: #ownership.isOwner(authentication, returnObject)
      Effect:    ALLOW
    Rule 2 (Admin Override):
      Condition: hasRole('ADMIN')
      Effect:    ALLOW
    Rule 3 (AI Risk Gate):
      Condition: #ai.isBlocked()
      Effect:    DENY (overrides all)

Scenario 3 —AI-Assisted Policy Creation

Contexa can assist policy authoring by combining existing roles, permissions, condition templates, and optional custom SpEL. In OSS code, this is best understood as assisted draft generation plus approval-state handling rather than a separate threat-scoring policy language.

AI-Powered Risk Assessment

When creating a policy for a sensitive resource, the AI engine analyzes:

• Available roles and permissions —Existing access entities exposed by Policy Center.
• Target resource metadata —URL or METHOD targets and their compatible condition types.
• Saved condition templates —Reusable SpEL conditions returned by the condition catalog.
• Custom condition input —Optional direct customConditionSpel authored by administrators.

Condition Auto-Recommendation

Based on the analysis, the AI recommends conditions for the policy:

Resource: DELETE:/api/v1/customers/{id}
Draft summary: sensitive destructive endpoint

Recommended Conditions:
  1. Role restriction:     ADMIN only
  2. Time restriction:     Business hours (M-F 09:00-18:00)
  3. IP restriction:       Internal network only
  4. MFA requirement:      Step-up authentication required
  5. AI action gate:       #ai.hasActionIn('ALLOW', 'CHALLENGE')
  6. Rate limit:           Max 10 deletions per hour per user

Selected flow: assisted policy draft
Rationale: combine role, time, IP, and AI action checks for a high-risk target.
           maximum protection with multiple condition layers.

Approval Workflow

Policies can move through approval states. The runtime loader skips PENDING and REJECTED policies; approved or not-required policies can be loaded.

CustomDynamicAuthorizationManager skips policies whose approval status is PENDING or REJECTED. Policies marked APPROVED or NOT_REQUIRED can participate in runtime evaluation.

AI Expressions in Policies

Once approved, AI-powered conditions are evaluated at runtime using SpEL expressions:

// Allow if AI determines the request is safe
#ai.isAllowed()

// Require step-up authentication if AI detects anomalies
#ai.needsChallenge()

// Action-based gating for threshold-like decisions
#ai.hasActionIn('ALLOW', 'CHALLENGE')

// Combined with traditional conditions
hasRole('ADMIN') and !#ai.isBlocked()

Scenario 4 —Migrating from Static to Dynamic

This scenario walks through converting an existing application with 20+ lines of hardcoded requestMatchers to Contexa's dynamic authorization.

Before: Static Security Configuration

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/css/**", "/js/**", "/images/**").permitAll()
        .requestMatchers("/api/public/**").permitAll()
        .requestMatchers("/api/admin/users/**").hasRole("ADMIN")
        .requestMatchers("/api/admin/settings/**").hasRole("SUPER_ADMIN")
        .requestMatchers("/api/admin/audit/**").hasAuthority("VIEW_AUDIT")
        .requestMatchers("/api/reports/financial/**").hasAnyRole("ADMIN", "FINANCE")
        .requestMatchers("/api/reports/analytics/**").hasAnyRole("ADMIN", "ANALYST")
        .requestMatchers("/api/orders/**").hasAuthority("MANAGE_ORDERS")
        .requestMatchers("/api/customers/**").hasAuthority("MANAGE_CUSTOMERS")
        .requestMatchers("/api/products/**").hasAuthority("MANAGE_PRODUCTS")
        .requestMatchers("/api/inventory/**").hasAnyRole("ADMIN", "WAREHOUSE")
        .requestMatchers(HttpMethod.DELETE, "/api/**").hasRole("ADMIN")
        .requestMatchers(HttpMethod.PUT, "/api/users/*/role").hasRole("SUPER_ADMIN")
        // ... more rules
        .anyRequest().authenticated()
    );
    return http.build();
}

// With the starter on the classpath, MVC and method resource scanners
// are auto-configured and populate managed resources at startup.

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http,
        CustomDynamicAuthorizationManager customDynamicAuthorizationManager)
        throws Exception {
    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/css/**", "/js/**", "/images/**").permitAll()
        .requestMatchers("/api/public/**").permitAll()
        .anyRequest().access(customDynamicAuthorizationManager)
    );
    return http.build();
}

Default Policy Management

When a request matches no configured URL policy, CustomDynamicAuthorizationManager.check(...) returns new AuthorizationDecision(true). That is the effective OSS fallback behavior.

Current Default Behavior

if (matchedDecisions.isEmpty()) {
    return new AuthorizationDecision(true);
}

Moving Toward Default Deny

The OSS codebase does not expose a dedicated YAML property for unmatched URL requests. To move toward deny-by-default, create explicit catch-all DENY policies for protected URL spaces or customize the authorization manager in code.

Architecture Deep Dive

This section traces the complete lifecycle of an HTTP request through the dynamic authorization system.

Key Components

CustomDynamicAuthorizationManager

Implements AuthorizationManager<RequestAuthorizationContext>. On initialization, it loads all active policies from the database via PolicyRetrievalPoint and builds a list of RequestMatcherEntry objects. Each entry maps a URL pattern (with HTTP method) to an ExpressionAuthorizationManager that evaluates the policy's conditions.

PolicyRetrievalPoint (PRP)

The data access layer for policies. It loads policies from the database, caches them for performance, and supports hot-reload when Policy Center or related admin services call authorizationManager.reload() together with PRP cache clearing. The current OSS runtime does not expose this as a standalone PRP event-subscriber abstraction in the documentation layer.

PolicyExpressionConverter

Converts stored policy conditions into the normalized SpEL string consumed by Spring Security. This bridges the gap between the policy definitions managed through Policy Center/admin policy flows and the runtime expression evaluation engine.

CentralAuditFacade

CentralAuditFacade is used across IAM policy services and denied authorization handling. In the URL authorization path, denied results are recorded with the request path and matched policy context so operators can review enforcement outcomes.

Advantages Summary

A comprehensive comparison across all dimensions of authorization management.

Related Documentation

• Resource Scanner —Detailed reference for MvcResourceScanner and MethodResourceScanner
• Dynamic URL Authorization —CustomDynamicAuthorizationManager API reference
• Policy Management —Policy lifecycle, CRUD operations, and AI enrichment
• @Protectable —Method-level resource protection annotation
• XACML Integration —Policy model and evaluation engine
• Permission Evaluators —Custom expression evaluation
• Admin Console —Web-based administration console