Radiator Server Documentation — v10.33.2

Local AAA Backends

Guide on when and how to create standalone Radiator instances without external dependencies

Table of Contents
  • Local AAA Backends
  • Local HA and LB
  • Benefits
  • Drawbacks
  • Memory-Only Operations

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.

  1. The user database is copied to memory from disk using the JSONFile backend. This works well for up to 100k users.
  2. Logging survives disk write failures. See the Logging article on how in-memory logs work (they are always on).
  3. 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.

Navigation
  • About Radiator software development security

  • Architecture Overview

  • Backend Load Balancing

  • Basic Installation

  • Built-in Environment Variables

  • Comparison Operators

  • Configuration Editor

  • Configuration Import and Export

  • Data Types

  • Duration Units

  • Environment Variables

  • Execution Context

  • Execution Pipelines

  • Filters

  • Getting a Radiator License

  • Health check /live and /ready

  • High Availability and Load Balancing

  • High availability identifiers

  • HTTP Basic Authentication

  • Introduction

  • Linux systemd support

  • 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

  • Service Level Objective

  • TACACS+ Authentication, Authorization, and Accounting

  • Template Rendering CLI

  • Tools radiator-client

  • TOTP/HOTP Authentication

  • What is Radiator?

  • YubiKey Authentication

  • YubiKey Context Variables