Subscriber Management Overview
The Subscriber Management platform offers Authentication, Authorization, and Accounting (AAA) functionality for RADIUS clients. NebularStack was built with the Internet Service Provider industry in mind. We continuously add support and ease of management for different use cases that become standard deployments.
Virtual Servers
AAA Servers are virtualised and run on multiple physical hosts for redundancy and scalability, ensuring a secure and uninterrupted service.
Subscribers are associated with Virtual Servers.
Proxy servers connect RADIUS clients (NAS/BNG) to Virtual Servers.
Proxy Server
A proxy server, whether on a physical host, virtual machine, remote, on-premises, or within the NebularStack distributed cloud, is a crucial component of your authentication, authorisation, and accounting service. One proxy can run multiple instances of proxies to different Virtual AAA instances.
The proxy serves as a bridge between NebularStack backend systems and your radius client (NAS/BNG) nodes.
By default, we assign 3 proxy instances per virtual server.
Client Profiles
The RADIUS client, often a NAS (BNG/UGW, etc.), plays a crucial role in the subscribers session. It passes user information to designated RADIUS servers and acts on the returned response, giving you, as a network administrator or engineer, the power to manage and control user access. RADIUS servers are the backbone of the system. They receive user connection requests, authenticate the user, and then return the configuration information necessary for the client to deliver service to the user.
The request messages to the radius server and the response messages from the radius server contain information defined using attributes. These attributes would differ based on the authentication method used by the customer device connecting to the RADIUS client (NAS/BNG). The RADIUS server response would need to be crafted explicitly based on the subscriber's limitations, quotas, capabilities, and supported attributes by the radius client. These attributes differ from BNG/NAS vendor to vendor and in terms of use cases.
Client profiles are used to identify RADIUS client types; examples are Cisco, Juniper, H3C, Huawei, Mikrotik, etc. Attributes per service are assigned to client profiles, and RADIUS clients are assigned to these profiles. Based on the specific service assigned to the subscriber, we can then identify which attributes are for which RADIUS client.
More information can be found at the Virtual Server documentation.
Service Profiles
Service Profiles defines low-level parameters for a subscriber account configuration. Acting as a bridge for the parameters configured in the Subscriber Profile and the RADIUS Attributes that are required by the RADIUS Client (based on its Client Profile).
More information can be found at the Service Profile documentation.
Subscriber Profile
Subscriber Profiles defines high-level parameters for a subscriber account configuration. The parameters is consumed by the Service Profile assigned to a Subscriber Account.
These parameters relate, for example, to bandwidth restrictions or whether an account is capped or uncapped.
More information can be found at the Subscriber Profile documentation.
Subscriber Account
Subscriber Accounts are used to authenticate and authorise sessions. Authentication concerns proving identity, while authorisation grants access. For example, the subscriber may get identified; however, the account could be suspended due to expiration.
A session is, for example, an active internet connection. It is determined by the continuing accounting messages received from the RADIUS client.
More information can be found at the Subscriber Account documentation.
Credits and Credit Profiles
Credits play a pivotal role in managing capped subscriber accounts, as they define the data quotas that can be applied to them. Multiple credits can be used with a single subscriber account. These credits can automatically renew and expire.
More information can be found at the Credit Profiles and Credits documentation.
Telemetry
We collect various telemetry from authentication, authorisation and accounting. Some of the things we store are subscriber data usage, session IP usage logs that are linked to Caller Data Records (CDR) and Event logs that describe the most recent subscriber activities.
More information can be found at the Subscriber Telemetry.