Local AAA Backends
Guide on when and how to create standalone Radiator instances without external dependencies
Local AAA Backends
Radiator can work completely standalone for AAA processing. This approach is high-performing, reliable, and simple to set up, though it does have some limitations.
A local Radiator deployment consists of clients (network devices, VPN servers, Wi-Fi controllers) connecting to a Radiator server, which authenticates users against local storage and stores audit logs locally:
Local HA and LB
The local solution allows for a fairly simple HA and LB setup by running multiple Radiator instances:
To avoid databases getting out of sync, hourly or daily full database synchronization is recommended.
Benefits
By relying only on networking and storage, the environment has minimal external dependencies, improving reliability.
This allows for centralized access control, but with local 'cache' of users. So the AAA processes will continue to work on last available data. This will keep your users authenticated even if outside connectivity has been disrupted.
Due to no centralized database for users this has no performance impact on the main database. Nor is it impacted by database maintenance activities.
Drawbacks
The user database needs to be synchronized externally into the system. This usually ends up being periodic (like once an hour).
The user database is read-only. Radiator has nowhere to store session state or user login history. With multiple Radiator servers this makes Change of Authorization (CoA) type of activities more difficult to implement.
So the feasibility of this solution depends on the use case.
Memory-Only Operations
For extreme use cases, Radiator can continue working without functioning storage. A typical example is a 'disk full' scenario.
- The user database is copied to memory from disk using the JSONFile backend. This works well for up to 100k users.
- Logging survives disk write failures. See the Logging article on how in-memory logs work (they are always on).
- Certificates for encryption are also read into memory and only updated when they change on disk.
This is the most performant AAA solution. User lookup times are measured in microseconds. Logging is asynchronous and does not impact single request speed. Encryption will consume CPU time regardless of whether storage is memory-based or disk-based. See Password Hashing and Radiator Sizing for more details on encryption performance.
Architecture Overview
Backend Load Balancing
Basic Installation
Comparison Operators
Configuration Editor
Configuration Import and Export
Data Types
Duration Units
Execution Context
Execution Pipelines
Filters
Health check /live and /ready
High Availability and Load Balancing
High availability identifiers
HTTP Basic Authentication
Introduction
Local AAA Backends
Log storage and formatting
Management API privilege levels
Namespaces
Password Hashing
Pipeline Directives
Probabilistic Sampling
Prometheus scraping
PROXY Protocol Support
Radiator server health and boot up logic
Radiator sizing
Radiator software releases
Rate Limiting
Rate Limiting Algorithms
Reverse Dynamic Authorization
Template Rendering CLI
Tools radiator-client
TOTP/HOTP Authentication
What is Radiator?