v10.34.0

Unified radiator-client commands

Use one client binary for individual RADIUS requests, RADIUS performance tests, and TACACS+ sessions.

Replace existing commands as follows:

radperftest [OPTIONS]                       -> radiator-client performance [OPTIONS]
radiator-tacacs-client [OPTIONS]            -> radiator-client tacacs [OPTIONS]
radiator-client --server HOST --port PORT   -> radiator-client --server HOST:PORT

The configuration file formats remain unchanged. Command-line invocations now use long option names; domain-specific short options were removed. Supply network destinations as one --server HOST:PORT value. See radiator-client for examples.

SHA and Salted SHA password formats

Radiator can now verify {SHA} and {SSHA} password values. These formats are commonly used for the LDAP userPassword attribute. Use the Management API or the password_hash("sha") and password_hash("ssha") Radconf filters to generate these formats.

The SHA-1 and Salted SHA-1 formats perform a single fast SHA-1 operation. Consider Argon2id or PBKDF2 when you control the password storage format and need stronger resistance to offline password guessing.

RADIUS backend connection timeouts

RADIUS and RADIUS DNS-SD backends can now configure separate deadlines for DNS resolution, TCP connection establishment, and TLS negotiation. Use dns-timeout and connection-timeout in the connect block, and handshake-timeout in its tls block. Each defaults to five seconds.

Configuration Editor Error Markers

Full configuration checks now only show inline editor markers for the file currently open in the configuration editor. Errors from other files remain visible in the check results list with links to the affected file.

Consistent EAP-TEAP configuration values

eap-teap-identity-type now accepts both user and machine without quotes. Quoted values remain supported.

eap-teap-intermediate-result now accepts duration values such as 60s. Existing values without a suffix continue to represent milliseconds. Timeouts are no longer limited to 65,535 milliseconds.

Pending configuration review diff

The pending configuration review dialog now shows changed files with an inline diff viewer, including highlighted added and removed lines, while still allowing a side-by-side split diff for larger comparisons.

TLS Protocol Negotiation Constraints

TLS configurations can now contain a negotiation block. Use repeated parameters to define ordered allowlists for TLS 1.2 and TLS 1.3 cipher suites, key exchange groups, and handshake signature schemes. Radiator uses IANA names in configuration.

tls {
    negotiation {
        tls13_cipher_suite "TLS_AES_256_GCM_SHA384";
        tls13_cipher_suite "TLS_AES_128_GCM_SHA256";
        key_exchange_group "X25519MLKEM768";
        key_exchange_group "X25519";
        signature_scheme "rsa_pss_rsae_sha256";
        tls12_require_extended_master_secret true;
    }
}

Omitted categories keep their default values and ordering.

Management UI session refresh

Management UI sessions now refresh immediately when the UI is opened, when the tab returns to the foreground, and periodically while the user is active. Refreshing extends the current server session in place instead of replacing it, which avoids logging users out after one hour and reduces stale-auth issues caused by persisted browser state or multiple open tabs.

Configure the rolling lifetime with session-timeout in management.http. Its default remains 1h. Set the optional maximum-session-timeout to require a new login after a fixed total lifetime, even while the UI remains active.

See Management session timeouts for configuration examples and multi-tab behavior.

PEAP Session Resumption Shortcut

PEAP now uses cached authentication state after TLS session resumption to avoid repeating inner authentication when the client accepts the protected PEAP Result TLV. The resumed session restores the authenticated user, AAA identity, vars.* values, and replayable RADIUS reply attributes from the original full authentication.

If a client declines the successful Result TLV response, Radiator falls back to the normal PEAP inner authentication exchange.

See EAP TLS Session Resumption for configuration and behavior details.

Backend And Challenge Logging

Backend query failures are now logged at debug level by default and periodically promoted to error level, reducing repeated error noise during transient backend issues while still keeping failures visible.

Challenge continuation failures now keep timeout wording in the structured error detail and include clearer context when a challenge reply cannot wait for the next client request.

EAP-MSCHAPv2 Retry Challenge

EAP-MSCHAPv2 now generates a new challenge when a client retries authentication after an incorrect password. This keeps password retry exchanges protocol-correct and avoids reusing the challenge from the failed attempt.

TLS Peer Certificate Log Fields

Supported TLS logs now include peer certificate details when a peer certificate is available. Transport and backend TLS logs use the cert_* fields, while EAP-TLS handshake logs use the existing tls.peer_cert.* field prefix.

PEAP Cryptobinding Support

PEAP version 0 now supports Cryptobinding TLVs in successful protected Result TLV exchanges. Radiator validates the peer response and uses the cryptobinding-derived session key when cryptobinding completes. Radiator accepts the peer-generated response nonce used by Microsoft Windows PEAP clients. During the PEAP version 0 TLS handshake, Radiator includes the optional TLS Message Length field for compatibility with Windows/NPS cryptobinding calculations.

Use the cryptobinding parameter in eap-peap to select optional, required, or disabled behavior. The default is optional for compatibility with existing PEAP deployments. Use required when peers must complete cryptobinding and the inner method must provide keying material. Radiator keeps the Cryptobinding TLV mandatory bit clear for MS-PEAP compatibility.

RADIUS backend connections

RADIUS/1.0 backend connection windows can exceed 256 requests. The local-ip and local-port connect parameters select the source address.

Socket buffer default

Radiator now requests one MiB receive and send buffers for its UDP and TCP sockets when buffer is not configured. The operating system can cap the effective size.

RADIUS backend connection balancing

RADIUS backend pools now use the new least-outstanding strategy by default. It selects the connection with the fewest requests in flight. This distributes traffic across warm connections and improves packet-processing parallelism.

RADIUS backend request-processing performance has also been improved. The number of requests in flight on each connection can now be limited with the connection window setting.

Retaining packed connection use

To retain the previous connection-packing behavior, configure first-available inside the backend server:

connections {
    max 10;
    min 1;
    idle-timeout 5m;
    selection first-available;
}

See RADIUS backend connection configuration for selection details and operational trade-offs.

UDP retransmission handling

RADIUS UDP request processing now performs better under load. Duplicate detection and cache behavior are configurable. See RADIUS duplicate detection and RADIUS duplicate cache.

HTTP To RADIUS Challenge Bridging

RADIUS backend queries started by an HTTP request now return control to the HTTP policy when the RADIUS peer responds with Access-Challenge. The policy can map the challenge, EAP message, and opaque RADIUS State into an HTTP response. A later HTTP request can return State with the next EAP response, allowing one HTTP POST per RADIUS authentication round.

The new base64_encode, base64_decode, and hex_decode filters convert binary values such as EAP-Message and State to and from JSON-safe text. base64_encode also concatenates multivalue input in order so fragmented RADIUS EAP messages can be returned as one Base64 value.

See RADIUS backend query results and value filters for configuration details.

RADIUS Message-Authenticator and RadSec ALPN Updates

Radiator now places Message-Authenticator first in RADIUS dynamic authorization requests. It replaces binding-supplied duplicates with one Message-Authenticator and preserves the order and values of other attributes.

RADIUS backend queries now support the send_message_authenticator parameter. It defaults to true, which preserves the existing secure behavior. Set it to false only when an upstream server cannot process Message-Authenticator.

When disabled, Radiator also removes Message-Authenticator attributes supplied through query bindings. Other request attributes keep their original order.

RadSec TLS blocks now support repeatable alpn_protocol parameters. RadSec uses radius/1.0 when no values are configured. RADIUS packet trace logs now include the negotiated protocol in the alpn field when it is available.

See the documentation for send_message_authenticator, RADIUS backends, server TLS, and packet trace logging.

RADIUS/1.1 Over TLS

RADIUS TLS listeners and backends now support the RFC 9765 RADIUS/1.1 packet profile. Radiator negotiates radius/1.1 and radius/1.0 with ALPN, uses the RADIUS/1.1 Token for request and reply correlation, and applies the RADIUS/1.1 rules for reserved fields, Message-Authenticator, and RADIUS/1.0-obfuscated attributes. It validates RADIUS/1.1 User-Password lengths, removes attributes that carry RADIUS/1.0 packet authentication data, creates CHAP-Challenge when a RADIUS/1.0 request without one is proxied to RADIUS/1.1, and rejects outgoing RADIUS/1.1 CHAP requests that omit CHAP-Challenge. It returns Protocol-Error with a home-server or proxy-specific Error-Cause when a request cannot be processed or forwarded.

When a RADIUS/1.1 proxy receives Protocol-Error with Error-Cause 502, 505, or 506, it retries the request through another available route. Other Protocol-Error replies are returned to the original RADIUS client without converting their packet Code or Error-Cause. Protocol-Error is accepted as a RADIUS/1.1 response to every request Code, including CoA and Disconnect.

Radiator validates complete RADIUS attribute boundaries before packet processing. A malformed packet is discarded, and a malformed or unauthenticated packet received over TCP or TLS closes its connection. Backend responses must also use a response Code permitted for the corresponding request Code for both RADIUS/1.0 and RADIUS/1.1.

This implementation supports RFC 9765 over TLS only. It does not support RADIUS/1.1 over DTLS.

Use radius_versions in a RADIUS listener or backend tls block to select none, 1.0, 1.1, or 1.0, 1.1. When omitted, the radius/1.0 profile remains the default as a backward compatibility exception to the RFC 9765 default. Configure 1.1 or 1.0, 1.1 to enable RADIUS/1.1 and its stricter packet rules. This explicit opt-in keeps existing RADIUS/TLS configurations on the RADIUS/1.0 packet profile. Forward backends configured with protocol tls; and exactly radius_versions 1.1; may omit secret, because RADIUS/1.1 relies on mutual TLS instead of RADIUS/1.0 packet authenticators and attribute transforms. The secret remains required for every configuration that can use RADIUS/1.0 and for reverse backends. The older generic alpn_protocol setting retains its custom-ALPN behavior. A RADIUS peer that omits ALPN is treated as RADIUS/1.0 with this setting; strict registered RADIUS profile negotiation applies only to radius_versions. Configurations that enable RADIUS/1.1 use TLS 1.3 as required by RFC 9765. They also require mutual TLS. Listeners must require and validate client certificates, and backends must configure a client certificate and private key. Mixed RADIUS version policies do not resume RADIUS/1.1 sessions, which prevents protocol changes during resumption. RADIUS/1.1-only backends retain TLS session tickets across reconnects when a custom certificate verification policy is configured.

The default radiator-client mode and the radiator-client performance subcommand can generate and validate RADIUS/1.1 traffic, including TLS 1.3 performance tests. radiator-client also supports pre-ALPN RADIUS/1.0 interoperability checks with --tls-no-alpn.

RADIUS packet trace logs identify the selected packet version, RADIUS/1.1 Token and reserved fields, negotiated ALPN, and the transport connection and endpoints that carried the packet. Invalid RADIUS/1.1 attributes that are discarded before processing are reported with their reason and length. RADIUS policies can read radius.connection.alpn to select processing based on the negotiated ALPN protocol. The value is none when a RADIUS/1.0 peer does not negotiate ALPN. Password and key attributes marked as encrypted in the RADIUS dictionary are masked in packet traces and debug sub-context output, including when RADIUS/1.1 carries their underlying plaintext representation.

See RADIUS backend configuration and server TLS configuration.

PEAP Inner EAP Proxying and Identity Layers

PEAP can now proxy a complete inner EAP conversation to a RADIUS backend. Radiator forwards EAP requests and responses, preserves RADIUS State across Access-Challenge exchanges, and imports the accepted MPPE keys for PEAP key derivation and cryptobinding.

An inner Access-Challenge must contain exactly one complete EAP-Request. Radiator preserves its EAP Identifier across PEAP header compression. Terminal Access-Accept and Access-Reject responses may omit EAP. When EAP is present, Radiator forwards it into the tunnel only when its Success or Failure result and Identifier match the completed inner exchange. A contradictory or invalid terminal EAP packet is ignored; as required by RFC 3579, the RADIUS response Code remains authoritative. An Access-Accept can install a complete MPPE key pair without also carrying EAP-Message.

PEAP inner authentication now records its tunneled EAP identity in the inner execution context. Use root.eap.identity to inspect the outer identity and eap.identity to inspect the tunneled identity. Modify aaa.identity when a backend requires a translated form, such as a username without its realm.

See EAP actions for the PEAP configuration and Execution Context for the identity accessors and a translation example.

Historic RADIUS Message-Authenticator Hardening

RADIUS clients can set limit_proxy_state true to require a valid Message-Authenticator on RADIUS/1.0 Access-Requests that contain Proxy-State. RADIUS and RADIUS DNS-SD backends can set require_message_authenticator true to require a valid Message-Authenticator on RADIUS/1.0 response types that support the attribute, except replies to Status-Server compatibility probes. Both settings default to false for compatibility with existing peers and do not apply to RADIUS/1.1, where TLS provides packet integrity.

See limit_proxy_state and backend require_message_authenticator for configuration examples.

RADIUS Backend Packet Size Limits

RADIUS and RADIUS DNS-SD backend servers can set separate max-incoming-packet-size and max-outgoing-packet-size limits. Both default to 4096 bytes. Packet sizes above 4096 require TCP or TLS.

Radiator discards oversized incoming packets without closing a TCP or TLS connection. It rejects outgoing packets that exceed the configured limit.

RADIUS Packet Validation and Profile Conversion

RADIUS packet parsing and signing now enforce the EAP-Message rules from RFC 3579. Radiator accepts EAP-Start in an Access-Request, reconstructs one complete EAP packet from valid fragments, and rejects incomplete or concatenated EAP packets. Access-Request and Access-Challenge EAP fragments must be consecutive. In RADIUS/1.0, EAP-Message requires Message-Authenticator and Accounting-Request rejects both attributes. RADIUS/1.1 validates the same EAP packet structure without Message-Authenticator. It removes a received or caller-supplied Message-Authenticator as an invalid RADIUS/1.1 attribute. RADIUS/1.0 signing recalculates a caller-supplied Message-Authenticator after packet changes.

RADIUS servers preserve Reply-Message in Access-Accept, Access-Reject, and Access-Challenge responses that also contain EAP-Message. This compatibility behavior lets downstream systems consume reject reasons and other response text. Set strict_reply_message true to remove Reply-Message from EAP responses as required by RFC 3579 section 2.6.5.

User-Password-style protected values without a fixed dictionary length now end at the first NUL octet, matching R4 handling for devices that append junk after password padding. Radiator also recognizes the assigned Access-Password-Request, Access-Password-Ack, Access-Password-Reject, and Status-Client packet Codes. Vendor-only Ascend and Breezecom packet Codes remain unsupported.

RFC 6929 Extended and Long-Extended attributes now use their defined headers, fragment flags, and Extended-Vendor-Specific framing. Proxy conversion preserves unprotected extended fragments byte-for-byte when the RADIUS packet profile changes. It also preserves uninterpreted raw attributes on a same-profile hop.

EAP-TTLS AVPs that map to protected dictionary attributes are encoded for a RADIUS/1.0 destination and retain their underlying value for RADIUS/1.1. Unknown AVPs remain byte-for-byte unchanged.

The RADIUS backend copy and filter actions now decode protected dictionary attributes according to the source packet profile. They re-protect the value for the destination profile and shared secret. Comparison rules inspect the decoded logical value, and tagged protected values retain their tag and full value. Conversion failures now fail the action instead of silently removing a selected attribute. See the copy, filter, and RADIUS backend documentation.

RADIUS proxy retries now add elapsed proxy time to a received Acct-Delay-Time and rebuild the Accounting-Request so its correlation and authenticator cover the updated value. Dictionary-unknown attributes are dropped by default. Set proxy_unknown_attributes true for a backend that requires private attributes which cannot be defined in the dictionary.

The radius.request.identifier and radius.reply.identifier policy accessors now expose only the RADIUS/1.0 Identifier. They return none for RADIUS/1.1 instead of exposing Reserved-1. See Execution Context.

RADIUS TCP and TLS connections close after fatal framing, packet authentication, or required Message-Authenticator failures. A reverse-query response with a mismatched Code is ignored while the connection and pending query remain available for a valid response. Unmatched responses are discarded before request processing. When a local reverse handler is unavailable, overloaded, or times out, an eligible RADIUS/1.1 Access-Request or Accounting-Request receives Protocol-Error with Error-Cause 506 while the healthy connection remains open.

RADIUS Status-Server responses

RADIUS servers support off, reply, and detailed Status-Server modes. Detailed responses include process identity, uptime, and server request and reply totals.

TACACS+ Connection Modes

Radiator supports both TACACS+ connection modes from RFC 8907 over TCP and TLS. Clients can open one connection for each TACACS+ session or negotiate Single Connection Mode and interleave multiple sessions on a persistent connection.

Single Connection Mode is now tracked for the lifetime of the connection from the first packet. Later packet flags do not change the negotiated mode. The per-client connection-mode setting can prefer Single Connection Mode or disable it for devices with broken connection reuse or multiplexing. The per-client validation-mode setting selects legacy-compatible or strict RFC 8907 request validation.

The default compatible validation mode accepts legacy ENABLE requests that use minor version 1 and logs a compatibility warning. Use strict mode to reject requests that do not follow the RFC 8907 version rules.

Radiator now enables TACACS+ protocol error replies by default, validates exact packet body lengths and authentication flow versions, and accepts legacy authorization arguments with trailing NUL bytes. The TACACS+ connection idle timeout now defaults to 20 seconds.

See client-selected TACACS+ connection mode for behavior and deployment guidance.

Documentation navigation fixes

Documentation categories on the documentation index now have clear spacing, top-aligned card content, and consistently sized document icons. Links to sections within a documentation page now keep readers on the current page and open the selected section. Filter signatures now render as documentation text without exposing HTML markup.

Bound EAP-TLS Resumption by Client Certificate Expiry

EAP-TLS session state and tickets now carry an authenticated full-authentication deadline. Radiator uses whichever is sooner: the client certificate expiry or the effective TLS session resumption lifetime. Resumed handshakes preserve the original deadline, and Radiator rejects resumption at that deadline so normal client certificate validation runs again.

The new tls.full_authentication_at timestamp is available to policies and is included in EAP-TLS handshake logs. See the execution context TLS namespace and EAP-TLS handshake logging.

Fixed none pipeline results

The none pipeline directive now returns accept when every action returns reject or ignore. It returns reject immediately when any action returns accept. An empty none block returns accept. The directive is deprecated because result propagation makes its behavior difficult to reason about. Use until instead.

Add RadConf UUID getters

RadConf pipelines can generate canonical UUID strings with util.uuid, util.uuid4, and util.uuid7. util.uuid is an alias for util.uuid4.

See Execution context for details and examples.

Numeric RADIUS attribute access

Use two dots followed by an attribute type number to inspect a RADIUS request or reply attribute:

log "AUTH" {
    json {
        "service-type" radius.request.attr..6;
    }
}

Numeric access performs best-effort decoding. Radiator uses a matching dictionary definition when possible. When the dictionary does not define the attribute type, Radiator returns its raw bytes. String and JSON output format raw bytes as hexadecimal text.

Numeric access is read-only. See the RADIUS dictionary documentation for details.

Runtime configuration API removal

Deprecated Management API endpoints for creating, updating, and deleting AAA policies, EAP policies, handlers, pipelines, caches, captures, certificates, client lists, dictionaries, licenses, management configuration, scripts, servers, and statistics have been removed. The installation password setup endpoint has also been removed.

Update configuration through the configuration file APIs or directly on disk, then deploy or reload the server configuration. Operational APIs remain available, including backend and server inspection, reload operations, cache data access, capture downloads, license status, logging, and statistics queries.

Clearer Counters overview

The Management UI Counters view now groups counters into collapsible top-level namespaces and presents each group with a concise path, aligned current values, explicit value semantics, and recent trends. Operators can search namespaces, metric names, and descriptions, select a shared 1-hour, 24-hour, or 7-day trend window, use expand-all and collapse-all controls, and see clearer loading, error, and empty states. Counter tiles link directly to details filtered to that metric, while group rows and their details actions open separate charts for direct counters. The details view adds back navigation, counter visibility controls, and an opt-in switch for matching counters in child namespaces. Latency tiles show the P95 peak from the same values rendered by their sparkline, and details inherit the selected window while initially showing raw histogram samples so the peak remains visible.

Default statistics history now retains 7 days

Deployments without a statistics block now retain 2016 counter, gauge, and histogram history samples at 5-minute intervals. This provides 7 days of local history for the Management UI and API instead of the previous 1000 one-minute samples, which retained 16 hours and 40 minutes.

To keep the previous retention and granularity, configure it explicitly:

statistics {
    defaults {
        samples 1000;
        interval 1m;
    }
}

See the statistics configuration for more information about local history and per-metric overrides.

OpenMetrics 1.0 metrics export

Radiator Server now exposes runtime metrics in OpenMetrics 1.0 text format at /api/v1/metrics/openmetrics. The endpoint requires the existing monitor privilege and complements the unchanged Prometheus 0.0.4 endpoint. OpenMetrics duration metrics use fractional seconds as required by its base-unit recommendation, while the Prometheus endpoint retains its existing units.

See Prometheus and OpenMetrics scraping for endpoint selection, authentication, and Prometheus configuration examples.

Per-connection RADIUS backend Status-Server monitoring

RADIUS backend server blocks and DNS-SD server-template blocks support a new connection-status { ... } block. It configures the probe interval, response timeout, and number of consecutive timeouts after which Radiator closes the connection. Each probe controls only the connection over which it is sent and does not directly affect the server-level service-level objective. Closing connections can reduce service availability. If the connection count falls below the configured minimum, Radiator attempts to open replacements.

The existing status true; syntax remains supported with its compatibility defaults.

Stable Management UI chart refreshes

Dashboard and statistics charts now update their data in place during automatic refreshes instead of briefly recreating the chart canvas.

Reliable configuration file deletion navigation

After deleting a configuration file from its details view, the Management UI now returns to the containing file listing instead of briefly reloading the deleted file and showing a not-found error.

Hash-balanced backend server selection

Multi-server backends can now select a preferred server by hashing one or more explicit AAA context fields.

backends {
    radius "EAP_PROXIES" {
        server-selection hash-balance {
            field radius.request.attr.Calling-Station-Id;
            field radius.request.attr.User-Name;
        }

        server "PROXY1" {
            # ...
        }

        server "PROXY2" {
            # ...
        }
    }
}

For multi-round RADIUS authentication, hash-balanced selection applies to the first request. Subsequent requests resume the selected server through State. Radiator now retains the latest State returned by the selected backend after each Access-Challenge. This supports backend RADIUS servers that change State between EAP rounds.

When a selected server fails before a multi-round exchange starts, Radiator distributes that server's requests across the remaining servers. Requests that already select an available server remain on that server. After an Access-Challenge starts a multi-round exchange, Radiator does not move the exchange to another backend server.

See Backend Load Balancing for configuration details.

Refined Management UI dashboard

The dashboard now presents operational information in a clearer, customizable layout.

Multiple management listeners

The management HTTP service now accepts multiple addr statements in a listen block. Each statement combines an IP address and port, such as addr "0.0.0.0:8443"; or addr "[::]:8443";. This allows the Management API and UI to serve IPv4 and IPv6 clients on the same or different ports. All addresses in a block use its TCP or TLS configuration.

See Management listener configuration for a dual-stack HTTP and HTTPS example.

Configurable Log Promotion

Use the logging promotion block to change the default interval or disable promoted application log rows. Promotion remains enabled with a 1m interval by default.

logging {
    promotion {
        interval 5m;
        enable true;
    }
}

Disabling promotion does not change message counters or normal lower-level rows. See log promotion and the promotion configuration reference.

Configuration Tests Skip Initialization Pipelines

Configuration tests now validate and publish configuration without executing @init pipelines. This prevents radiator --test checks from modifying external systems through initialization actions. Normal startup and configuration reloads continue to execute initialization pipelines.

See the @init configuration reference for execution details.

Radiator Server container images

Minimal Radiator Server container images for AMD64 and ARM64 are available from the Radiator Server repository on Docker Hub. Releases are published with a version tag and the rolling latest tag. The rolling nightly tag provides the latest successful nightly build for testing the next version.

Use a version tag for repeatable production deployments. See Containers for Compose and command-line examples.

Bundled evaluation license

Each image includes an evaluation license for up to 10,000 counted incoming requests per licensed protocol during each Radiator process boot. The license is tied to the Radiator version included in the image. Radiator uses the bundled license when no valid license is available from the configured license sources. A configured testing or production license takes precedence.

The bundled license remains inside the image and does not need to be copied to persistent storage. See Getting a Radiator License when you need a testing or production license.

Management logins

The container provides an admin management user. Set the MANAGEMENT_PASSWORD environment variable to a supported hash of your own password before using the container in production. See Containers for initial login details.

Set the MONITOR_PASSWORD environment variable to a supported password hash to enable the optional monitor user with monitor-only access. When the variable is unset or empty, the monitor user does not exist.

Optional static management users

Static users in a management credentials block can use omit-if-password-empty true. The user is omitted when its password expression resolves to an empty string while the configuration is loaded. See Optional static management users for syntax and details.

RadiatorDB Backend

RadiatorDB is a new document-oriented backend built into Radiator Server. It stores JSON documents in PostgreSQL and makes them available to AAA pipelines, Management UI, and Radiator Management API. Use it for subscriber profiles, credentials, sessions, accounting records, and other data that Radiator policies need to read or write.

RadiatorDB provides:

• Configured collections with multipart keys, typed field schemas, validation, indexes, automatically expiring documents, and normal or time-series storage.
• Pipeline query and put operations for authentication, authorization, accounting, and other AAA workflows.
• A Management UI and JSON REST API for browsing, creating, updating, renaming, and deleting documents. Collection roles control read, write, and custom action access.
• Revision history for document changes, including audit information and restoration of earlier revisions. Revisions are retained unless collection age or count limits are configured.
• Streaming, optionally compressed backup export and import through Management API. Restore strategies support full replacement, conflict override, missing-document import, and newest-write conflict resolution.
• Multimaster replication across PostgreSQL nodes for high availability and read scaling. Changes written to any node replicate to the other nodes, with last-writer-wins conflict handling.
• Automatic PostgreSQL schema and replication setup, scheduled tombstone and revision garbage collection, server failover and balancing, separate replication addresses, and per-backend PostgreSQL synchronous_commit tuning.

The following example defines a collection and exposes a query to AAA pipelines:

backends {
    radiatordb "CUSTOMERS" {
        server "primary" {
            host "db.example.com";
            database "radiator";
            username "radiator";
            password env.RADIATORDB_PASSWORD;
        }

        collection "users" {
            roles {
                read "support";
                write "ops";
            }

            key {
                field {
                    name "Username";
                    type text;
                }
            }

            field "password" {
                name "Password";
                type password;
                required true;
            }
        }

        query "FIND_USER" {
            collection "users";
            key aaa.identity;

            mapping {
                user.username = key[0];
                user.password = doc | jsonpath("$.password");
            }
        }
    }
}

Add a Management UI sidebar item for /radiatordb when users need direct access to the database interface. Set user.radiatordb_role in the management authentication policy to grant the roles configured by each collection.

Configuration tests use bounded waits for RadiatorDB nodes, so an unavailable database does not leave a test or management request waiting indefinitely.

See the RadiatorDB overview, installation guide, backend configuration reference, REST API, and backup guide.