Skip to main content

Allowed

The Allowed validator grants access unconditionally. Every request that matches a rule using this validator is permitted, regardless of the relationship between the client and the target resource.

When to use​

Use Allowed for resources that any authenticated client with the matching role should be able to access. Typical examples include reference data and terminology resources such as CodeSystem, ValueSet, StructureDefinition, or NamingSystem that carry no patient-identifiable information.

application.yaml
fire-arrow:
  authorization:
    validation-rules:
      - client-role: Practitioner
        resource: CodeSystem
        operation: read
        validator: Allowed

      - client-role: Patient
        resource: ValueSet
        operation: search
        validator: Allowed
caution

Never use Allowed as the default-validator. Doing so makes every resource type that does not have an explicit rule publicly accessible to any authenticated client. The only reasonable scenario for this setting is when intentionally operating a completely open FHIR server.

Supported client roles​

Allowed works with any client role (Patient, Practitioner, RelatedPerson, Device).

Multi-tenancy consideration​

Allowed bypasses all compartment and organizational checks. In a multi-tenant deployment this means that a rule with Allowed exposes the matching resources of all tenants, not just the client's own organization. If you need to expose reference data scoped to an organization, consider using LegitimateInterest or CareTeam instead.

Performance​

The Allowed validator adds negligible overhead to request processing. It performs no database lookups and no compartment resolution — it simply permits the request to proceed.