This chapter presents concepts that are essential to understanding the standard modules available with Oracle Communications Billing and Revenue Management (BRM) RADIUS Manager.
Eight general purpose modules types are included with RADIUS Manager. These utilities handle RADIUS requests. Each module type has a unique name, such as mod_pin, mod_null, and mod_text, along with code that implements its unique behavior. Each module type is implemented as a pair of C++ classes: a module master class, and a module worker class.
There are three important module concepts: module type, module master class, and module worker class.
Module types are defined in the RADIUS configuration file (BRM_home/apps/radius/config, where BRM_home is the directory in which BRM components are installed) by using the type element.You define global configuration settings module types in the $CONFIG section of the RADIUS configuration file (BRM_home/apps/radius/config). This ensures that the same configuration is used across all modules of that type.
This example specifies the configuration of all modules of type mod_pin:
$CONFIG {
...
mod_pin {
timezone=28800
network=my-network
charge-on-reboot=NC
domain-separator='@'
}
...
}
For each module type, there is a module master class implementation. A module master class is instantiated for each entry of a module type RADIUS configuration file (BRM_home/apps/radius/config). For example, if the RADIUS configuration file contains entries for two modules of type mod_logging, two module master classes of type mod_logging are created.
The module master is responsible for:
Reading and interpreting global module type configuration information
Reading and interpreting module specific configuration information
Instantiating (creating) module workers as required.
There is a module worker class implementation for each module type. A module worker object of the appropriate class is instantiated for each module entry in the RADIUS configuration file. (BRM_home/apps/radius/config) for each worker thread. For example, if the RADIUS configuration file contains entries for two modules of type mod_logging, and two worker threads are configured, four module worker objects of type mod_logging are created.
Module workers are responsible for processing requests as they arrive.
The eight general use modules provided with RADIUS Manager can divided into two general categories: external communication modules and support modules.
External communication, or terminating module types, check an incoming request and either accept the request or pass it on to the next module instance in the chain. If the request is accepted, it is processed. After the request is processed successfully, the required attributes are appended to the request, and the request is sent to the NAS. The external communication modules include:
mod_pin. Performs standard BRM authentication and accounting. Also provides support for VPDN and iPass integration.
mod_text. Authenticates requests using plain-text user, login, and password information.
mod_unixpwd. Authenticates requests using a UNIX password.
mod_proxy. Forwards requests to another RADIUS server.
mod_null. Selectively replies ACK, NAK, ignore, or discard requests. Handles incoming authentication and accounting requests before special processing of the packets is performed. Used as the last module in a module chain.
Support, or non terminating, modules check an incoming request, and either accept the request or pass it on to the next module worker class in the chain. If the request is accepted, it is processed. After the request is processed successfully, the request is passed on to the next module worker class in the chain. The module may or may not alter the contents or attributes of the request. Unlike terminating modules, non-terminating modules never reply to the NAS. The non-terminating modules include:
mod_logging. Logs RADIUS requests to text files.
mod_cdr. Logs RADIUS requests using a record oriented, field-separated format.
mod_transform. Transforms attribute-values using a basic transformation function.
mod_unit. Scales unsigned integer values to signed integer values.
Modules are strung together in a series to form module chains. The module chain performs a series of functions as defined by the specific worker modules configured into the chain.
When a request is received by the RADIUS server, it is placed in the queue. The next available thread picks up the request and processes it within the module chain. How the request is processed depends on:
which modules are configured into the chain
the order in which modules are configured
whether the module is an external communication module or a support module
In order for the module chain to work as intended each module in the chain must be configured to pass a request to the next module using specific instructions for accepting, failing, or ignoring the request.
Each module in the chain includes it own instructions for how to handle a RADIUS request. The primary components of these instructions are the check and send elements.These are defined in the $DEFINE section of the RADIUS configuration file.
All worker class modules use the check element. The check element attempts to match attribute-value pairs in the request with specific criteria:
If the request meets the criteria set in the check element, then the request is processed.
If the request does not meet the criteria set in the check element, then the check fails. A failed request is passed on to the next module worker class in the chain.
This example shows the syntax for a check element. In order for this request to be processed, the request must be from the IP address 10.1.2.3, and the user name must end with @domain.com.
check {
NAS-IP-Address = 10.1.2.3
User-Name = "*@domain.com"
}
The attributes set in the send element determine which attribute-value pairs are appended to the reply to the NAS. Only external communication module worker classes, which communicate with the NAS, use the send element.
This example shows the syntax for a send element. In this example, the reply packet will be appended to contain the Framed-MTU and Ascend-Idle-Limit attributes.
send {
Framed-MTU=892
Ascend-Idle-Limit = 600
}