Security & Privacy
This chapter shall provide a brief overview of the data that RADIUSaaS is processing and storing and how this data is protected against unauthorized access.
RADIUSaaS' core service can currently be deployed in the following regions:
- Australia
- Europe
- United Kingdom
- United States of America
In case RADIUS proxies are required, they can be deployed in the following countries/regions:
- Australia
- Canada
- Europe
- India
- Singapore
- United Kingdom
- United States of America
RADIUSaaS processes X.509 user or device certificates to validate the authenticity of the authentication request. As part of the certificate, every attribute can be processed, potentially containing information such as:
- Username
- Email
- UPN
RADIUSaaS relies on the RADIUS protocol, e.g. the following data is visible to RADIUSaaS:
- Client MAC address
- NAS (e.g. access point, switch, ...) MAC address
- WiFi SSID
- Vendor-specific data (e.g. VLAN, tunneling-group, ...)
- NAS IP address
- ISP-assigned public IP address
- RADIUS Shared Secret (only relevant if RadSec is not natively supported)
- Private key of the RADIUS server certificate
RADIUSaaS (optionally) provides functionality to generate username + password pairs for network access. Those credentials are stored and processed by the service as well.
- 1.PermissionsThe RADIUSaaS platform stores UPN/email information on the users that are allowed to access the platform. No passwords are stored or processed by RADIUSaaS.
- 2.LoggingFor troubleshooting and analysis purposes, the RADIUSaaS platform logs all relevant data it processes (see Question 2 except for the RADIUS Shared Secret and the private key of the server certificate).The logs are stored directly on the RADIUSaaS platform within an Elasticsearch database and segregated for every client via a dedicated space. Log retention time: 75 days.
- 3.CertificatesRADIUSaaS requires several server certificates as well as root certificates to facilitate proper operation. All those certificates are securely stored in an Azure KeyVault.
- 4.The optional username + password credentials mentioned in Question 2 are stored in an Azure KeyVault.
- 5.Other secrets and configuration dataOther secret data, e.g. the RADIUS Shared Secret as well as the service's configuration are securely stored in an Azure KeyVault.
There is no built-in log archiving mechanism. However, the Log Exporter feature can be used to ingest RADIUS logs into your own logging and archiving services.
- 1.
Basic User Profile
:With this permission RADIUSaaS retrieves the user's UPN that tries to log on to the RADIUSaaS Admin Portal. - 2.
Maintain access to data you have given it access to
With this permission RADIUSaaS receives the right to request a refresh token so that the user can stay logged-on.
- 1.
Basic User Profile
:For details on what data can be retrieved, please refer to this article: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile - 2.
Maintain access to data you have given it access to
No specific data is made available by granting consent to this permission.
- 1.RADIUS Server Backend API
- Provides configuration information to the RadSec proxy
- 2.RADIUS and RadSec Server Ports
- To facilitate network authentication from anywhere on the internet, these authentication interfaces have to be publicly exposed.
- 3.RADIUSaaS Admin Portal
- A web portal which facilitates the administration of the service
- 4.Kubernetes Cluster Management API
- Required to operate the service
- 1.RADIUS Server Backend API
- Secured via a static JWT token
- 2.RADIUS Proxy and RadSec Server Ports
- RadSec server ports (2083): TLS-secured (version 1.2)
- RADIUS proxy server ports (1812, 1813): Protected via the RADIUS Shared Secret
- 3.RADIUSaaS Admin Portal
- Secured via OAuth 2.0 authentication with Azure AD.
- 4.Kubernetes Cluster Management API
- TLS-secured (version 1.2)
- Administrative access is realized through OAuth 2.0 authentication with Azure AD for users that are registered on the platform.
- Yes. The RADIUSaaS Admin portal provides features to assign roles to every user (available roles: administrator, viewer, guest)
- In order to properly operate and maintain the service, there are super-admin accounts for a limited circle of glueckkanja-gab AG employees, that have full access to all client instances of the RADIUSaaS service.
- Login credentials: Depends on the configured AAD policies in the customer tenant.
- Username + password credentials as well as all certificates for network access can be recovered from Azure KeyVault with a retention policy of 90 days after they have been deleted.
- Configuration data is stored in Azure KeyVault and protected via access credentials that are in turn stored as Kubernetes Secrets.
- The Elasticsearch Database is hosted on the encrypted Kubernetes Service disks.
- The logs are stored in an Elasticsearch Database and segregated via dedicated spaces.
- Access to those spaces is given via username + password credentials that are in turn stored as Kubernetes Secrets.
- The Elasticsearch Database itself is not encrypted.
- The authentication flows of the device trying to access the network are wrapped into a TLS-tunnel (>= TLS 1.2)
- The association between NAS and the RADIUS server is obfuscated via the RADIUS Shared Secret (MD5 hash algorithm)
RADIUSaaS relies on well-established protocols to handle network authentication flows (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). Due to the strong focus on certificate-based authentication, capturing the traffic is meaningless as long as the eavesdropper does not have access to a trusted certificate.
We are recommending to use the modern RadSec protocol to authentication against RADIUSaaS. However, there are many network infrastructure components still out there, which do not support RadSec.
The following diagram shows the RADIUS authentication flow:

In the first part of the authentication sequence, the communication is secured by an MD5-based hashing algorithm (partially encrypted with the shared secret). No secrets are transported in this phase.
In the second part of the authentication sequence, a TLS-based EAP (e.g. EAP-TLS) encrypts the traffic. The EAP-TLS traffic is then transported via UDP to the RADIUS proxy. This is the phase when credentials such as the certificate or the password is exchanged with RADIUSaaS. If you use certificate-based authentication, no secrets are transported in this phase as only the public key is exchanged. The private key remains on the client device at all times.
Conclusion: UDP-based RADIUS authentication with RADIUSaaS is secure, since
- the relevant traffic is encrypted and
- additionally there are no secrets transported, if certificate-based authentication is used.
Kubernetes
EFK Stack (Elasticsearch, Filebeats, Kibana)
Python
Azure (KeyVault)
TerraForm
Git CI
- Core Services: Depends on configuration
- If the service is hosted in a European data center, then no data leaves the European Union.
- RadSec Proxy: Depends on configuration
- If you require a RadSec proxy due to limitations of the network gear in regards to native RadSec support, you may select a proxy from various regions, Europe amongst others. In that case, your data stays within the borders of the European Union.
- Microsoft Corporation (Azure)
- Provision of cloud services
- Digital Ocean, Inc.
- Provision of cloud services
- Provision of VMs and services for RADIUS to RadSec protocol conversion
No
- There are dedicated RADIUSaaS labs for development purposes
- The deployment and installation of the service is realized through TerraForm, ensuring consistency and idempotence of each instance deployment
- Kibana APM is used for service health measurement and alert management
- Digital Ocean monitoring supervising the RadSec proxies
- Each production release must go through the internal channel first, passing the relevant QA hurdles as part of our CI process
- Unit tests
- Peer review (six-eye-principle)
- Integration tests
- Stress tests
- Experience-based testing
Yes. Patches, hot-fixes, bugfixes and feature updates are introduced using our CI/CD process that leverages different testing pipelines to ensure that only code that satisfies our QA hurdles gets released. Newly released code is automatically made available to all our customers. Using Infrastructure as Code (Terraform) enables us to deliver consistent, reproducible and high-quality updates to our customers.
The Kubernetes-based architecture of our service ensures that code updates are seamless for our customers and do not lead to any service outages.
- Patches for CVEs / security vulnerabilities: Once the vulnerability becomes public knowledge or as soon as we identify a vulnerability within our own code, a hot-fix will be provided no longer than 24 hours after we have become aware of the vulnerability.
- Other patches: No SLA.
We leverage Azure KeyVault to securely store secrets (e.g. certificates) and all other configuration data of the service. Azure KeyVault is a highly-available geo-redundant service that replicates all of its content in a second datacenter, thus providing implicit back-up services.
Stateless. No back-up required.
Currently not backed-up.
Yes. The restoration from back-ups is tested with every update/release of the service. There are approximately 4 - 8 releases per year.
Last modified 1mo ago