Radius Proxy Authentication
You set up radius proxy authentication by routing login requests to a central directory. The local server forwards user credentials to a home server for identity checks. Network teams use this flow to manage switches, wireless networks, and remote tunnels. Still, teams often map broad group roles to these network logins. Once a user passes the check, they gain wide network reach. How radius proxy authentication routes login requests In a standard setup, a user tries to log in to a network dev
Database Proxy (ProxySQL, PgBouncer) + Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up radius proxy authentication by routing login requests to a central directory. The local server forwards user credentials to a home server for identity checks. Network teams use this flow to manage switches, wireless networks, and remote tunnels. Still, teams often map broad group roles to these network logins. Once a user passes the check, they gain wide network reach.
How radius proxy authentication routes login requests
In a standard setup, a user tries to log in to a network device. That device acts as a client and sends an encrypted packet to a local server. The local server reads the domain name or prefix attached to the username. This domain label is called a realm in standard network terms.
If the local server does not own that realm, it forwards the packet. It sends the login request to an upstream home server that holds user records. A shared secret encrypts the traffic between the local server and the home server. The home server checks the user password and any second factor challenge.
When the check passes, the home server sends an accept packet back downstream. The local server passes that approval back to the network device. The device then opens the network port or tunnel for the engineer. Accounting packets follow the same path to log when the session starts and stops.
Why network login checks leave a session gap
This forwarding model solves a specific problem for large or multi-domain networks. Teams do not need to copy user passwords across dozens of separate network zones. Partner groups and roaming staff can log in using their home directory credentials. Central admins can also revoke a user account in one single place.
Yet this protocol only decides who can enter the network at the start. It stops working the moment the network port opens for the user. The protocol cannot read database queries, shell commands, or API calls inside the session. It only logs the start time, stop time, and total bytes sent.
Database Proxy (ProxySQL, PgBouncer) + Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Engineers still need a second set of keys to use databases or cloud hosts. Teams often share static database passwords or long-lived SSH keys after the network check. If an engineer runs a bad query, the network log shows no query details. It also cannot mask sensitive fields like emails, phone numbers, or card numbers.
Managing permissions beyond the initial network check
Modern engineering teams need controls that work at the command and query level. Instead of opening a flat network tunnel, teams should check every single action. Each database query or shell command should tie back to an individual identity. Security teams need clear logs of every statement that runs in production.
Data privacy also requires active filtering when queries return sensitive rows to users. Masking rules can rewrite emails, national IDs, and card numbers in query results. This approach keeps raw data safe while engineers debug live systems or run scripts. Combining identity checks with command-level rules closes the gap left by network logins.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What does a realm do in a forwarding setup?
A realm is a domain label attached to the username during login. The server reads this label to pick the right home server for verification.
Does this protocol encrypt the whole user session?
No, it only hides the password inside the initial login packet using a shared secret. It does not encrypt or inspect the traffic that follows after login.
Can network accounting logs show which database tables an engineer read?
No, accounting packets only track session length, login time, and data volume. They have no visibility into SQL statements, table names, or returned rows.