Skip to main content

Forbidden

The Forbidden validator rejects every request unconditionally. Its primary purpose is to serve as the default-validator, ensuring that any operation without an explicit authorization rule is denied.

Setting Forbidden as the default validator implements a deny-all, allow-by-exception pattern. This is the recommended security posture because it guarantees that no data is accidentally exposed when you add new resource types or forget to create a rule.

application.yaml
fire-arrow:
  authorization:
    default-validator: Forbidden
    validation-rules:
      # Only explicitly listed rules grant access
      - client-role: Patient
        resource: Observation
        operation: read
        validator: PatientCompartment

Using in explicit rules​

You can also use Forbidden in an explicit rule to deny a specific combination of role, resource, and operation. This is rarely necessary when Forbidden is already the default validator, but it can be useful for documentation purposes or when you want to make the denial explicit in a configuration that uses a permissive default.

application.yaml
fire-arrow:
  authorization:
    validation-rules:
      - client-role: Patient
        resource: AuditEvent
        operation: read
        validator: Forbidden

Supported client roles​

Forbidden works with any client role.

Performance​

The Forbidden validator adds negligible overhead to request processing. It immediately rejects the request without performing any database lookups or compartment resolution.