[feature] Support multi-tenant NAS authentication with REST-backed dynamic clients

⚠️ Warning: This issue is not suited to new contributors.

Is your feature request related to a problem? Please describe.

The Radius User Token authentication flow derives the organization from the end user. An Accounting-On packet normally has no end-user identity, so that mechanism cannot determine a tenant. The current organization-agnostic handling relies on an allowlisted FreeRADIUS source and cannot safely scope NAS events to an organization.

FreeRADIUS's standard SQL nas client lookup is also not tenant-aware. It identifies a NAS by its source identity and shared secret, and new SQL-backed NAS records normally require a FreeRADIUS reload or restart.

Describe the solution you'd like

Provide a supported multi-tenant NAS authentication design in which an authenticated NAS unambiguously determines its OpenWISP organization before authorization, accounting, or REST processing.

The preferred direction is to support FreeRADIUS dynamic-client lookup through a protected OpenWISP REST endpoint. FreeRADIUS would resolve an unknown NAS source identity at runtime, receive its client definition and shared secret, and cache it. OpenWISP would resolve the NAS to one active organization. Subsequent OpenWISP RADIUS API operations must use the organization derived from that authenticated NAS, never an end-user token or request-provided tenant value.

The design should define NAS identity uniqueness, secret rotation and revocation, cache invalidation, REST transport authentication, configuration generation, and behavior for NAS events without a user identity. It should avoid requiring a FreeRADIUS restart when a NAS is added or changed.

Describe alternatives you've considered

Using a fixed organization UUID and API token in each FreeRADIUS site works for organization-specific requests but requires separate site configuration. The Radius User Token flow is convenient for shared deployments but cannot identify the organization of Accounting-On packets. Custom SQL dynamic-client queries can implement parts of this design but leave OpenWISP unable to own and enforce the tenancy invariant. Per-organization virtual servers depend on FreeRADIUS 3 behavior and are not a portable long-term design.

Additional context

FreeRADIUS 3.2.10 is the latest stable release. FreeRADIUS 4.0 remains development. The design should not depend on FreeRADIUS 3's SQL nas.server virtual-server selection because FreeRADIUS 4 dynamic clients are listener-local.

Relevant upstream mechanisms are FreeRADIUS dynamic clients and rlm_rest. The REST response must supply the dynamic client identity and shared secret before normal RADIUS packet processing. The REST endpoint therefore needs strong transport protection and must return credentials only to trusted FreeRADIUS instances.

Start by reviewing the existing Radius User Token and organization-agnostic handling, then study FreeRADIUS dynamic clients and rlm_rest. Done means a reviewed design that defines tenant resolution, identity uniqueness, credential protection and rotation, cache invalidation, configuration generation, and behavior for userless NAS events without requiring restarts.