AR's Architecture AR is built on a multithreaded architecture so that it can take advantage of multiprocessor systems and provide high AAA performance. This architecture is seen in Figure 14-1. Figure 14-1. AR's Architecture 
The following sections discuss specific components of AR's architecture further. Policy Engine The core of AR is its Policy Engine. This is indicated in Figure 14-2 with the number 1. Figure 14-2. Policy Engine 
The Policy Engine provides the decision and policy enforcement for AR based on the contents of a RADIUS request packet. Within AR, multiple extension points provide customization using custom code. Although these extensions can be used for a number of purposes, one of them is the capability to influence how a request is processed and the capability to modify the incoming and outgoing packets to meet the special request. The processing methods that are available in AR include local, LDAP, ODBC, proxy, and prepaid (specifically AR Prepaid version). AR also allows custom service code to be inserted into its architecture to allow a service provider to accommodate special request processing and integration. The AR Policy Engine can make the following decisions: Whether authentication against an LDAP directory or Oracle database is required Whether a request should be forwarded to an external RADIUS server What type of accounting is required Whether session limits apply Whether an IP address pool has been assigned
Extension Points The extension points, indicated by the number 2 in Figure 14-3, are where the customization and integration can occur. Figure 14-3. Extension Points 
These custom calls and service use custom logic and are written by programming languages such as C, C+, Tcl, and Java. At certain times during a request-response program flow, a script written by the provider can be used to customize the process. The extension points include the following: Server incoming/outgoing These scripts run for every request packet coming into or leaving AR. Vendor incoming/outgoing These scripts run only for requests from the specified client vendor. Client incoming/outgoing These scripts run only for requests from the specified client (router, network access server [NAS], and so on). Service incoming/outgoing These scripts run before/after a service. Remote server incoming/outgoing These scripts run for requests using a Cisco CNS AR remote server. Group authentication/authorization These scripts run for access requests for a user belonging to a group. User authentication/authorization These scripts run for access requests for a particular user.
AR can use Extension Point Scripting (EPS) to request targeting. This means that a script that is applied to the server incoming extension point is used for all requests that arrive at AR. Requests can be either access requests or accounting requests. If you look at the different types of extension points, it is easy to understand when they will be invoked. Beginning with the first bulleted EPS, server incoming/outgoing scripts would indicate that all requests that arrive or leave AR would invoke this script. If you were to use the second bulleted EPS, vendor incoming/outgoing scripts, these would apply only to incoming or outgoing requests from a specific vendor. The same flow works for the rest. When a RADIUS packet comes into AR, it goes through five general steps. These steps are done in the following order: Step 1. | Validate the AAA client.
| Step 2. | Invoke the Policy Engine if it is configured.
| Step 3. | Perform the required AAA service.
| Step 4. | Perform session management if it is needed.
| Step 5. | Create the response and send it to the AAA client.
|
When you use EPS, it allows you to manipulate the request and response attributes using AR's application programming interface (API) functions. This does not really change the steps that occur when a RADIUS packet comes in; it just adds a bit more to the process. Figure 14-4 shows the process. Figure 14-4. EPS Processing Order 
Manipulating environment variables also allows EPS to communicate with AR as well as with other scripts. These values are grouped into request attributes (which deal with requests), response attributes (which deal with responses), and environment variables. [1]Cisco AR supports many variables that scripts use to communicate withor change the behavior ofthe Cisco AR server, or to communicate with other scripts. For example, if the "Accounting-Service" environment variable is set, the server directs the request to the specified accounting service for processing. Likewise, you can set the "Authentication-Service" and "Authorization-Service" environment variables to direct requests to the appropriate authentication/authorization service. Extension Point Scripting Examples The EPS examples shown here are written in Toolkit Command Language (TCL) for the purpose of clarity.[2] All examples can be written in C or C++, and they all use the same APIs. Basic Examples The four examples shown in this section illustrate basic API commands as put, get, and remove. The following request attribute example adds the attribute Service-Type to a request with its value set to Outbound: $request put Service-Type Outbound
This response attribute example removes the State attribute from the Cisco AR response (some noncompliant RADIUS clients behave unpredictably when they receive this attribute): $response remove State
The following environment variable example illustrates communicating with Cisco AR to set AAA services: $environ put Authentication-Service auth-service $environ put Authorization-Service auth-service $environ put Accounting-Service acc-service
The following environment variable example returns the type of request received by Cisco AR, for example, Access-Request: $environ get Request-Type
Selecting the Service The following example illustrates how an extension point script looks at the DNS domain in the username and sets the AAA services. It also overrides the username in the request by setting the User-Name environment variable. The script can be run from the server incoming extension point so that it runs for every request that Cisco Access Registrar processes. proc RealmServiceSelection {request response environ} { set userName [ $request get User-Name ] if { [ regexp {([^@]+)@([^@]+)} $userName dummy newUserName realm ] } { $environ put User-Name $newUserName $environ put Authentication-Service $realm $environ put Authorization-Service $realm $environ put Accounting-Service $realm } }
Handling Accounting Requests The following example shows how an extension point script diverts accounting requests to a file. To find all the accounting requests, the script must process every request. Hence, the script runs from the server incoming extension point. The script identifies accounting requests by examining the Request-Type environment variable. All accounting requests with the attribute Acct-Status-Type set to Accounting-On or Accounting-Off are then written to the local file accounting service named SysAcc-file: proc divert-AccOnOff { request response environ } { set request-type [$environ get Request-Type] if { [string equal ${request-type} "Accounting-Request" ] } { set AST [ $request get Acct-Status-Type ] if { ( [string equal $AST "Accounting-On"] | | [string equal $AST "Accounting-Off"]) } { $environ put Accounting-Service SysAcc-file } } }
Ignoring Accounting Signatures This example script checks the Request-Type environment variable. If the packet is an accounting request packet, the script sets the Ignore-Accounting-Signature environment variable to TRUE. This script is useful in situations where a service provider has NASs that do not sign the accounting requests properly. This script allows the service provider to tell Cisco Access Registrar to ignore the accounting signature. Because these NASs can be grouped under a vendor, this script can be run from the vendor incoming extension point: proc ig-acc-sig { request response environ } { set request-type [ $environ get Request-Type ] if { [string equal ${request-type} "Accounting-Request"] } { $environ put Ignore-Accounting-Signature TRUE } }
Controlling Debugging In service provider environments with large volumes of production traffic, it is not feasible to turn on debugging (tracing) for long periods of time because debugging is resource intensive. Specifically, in attempting to analyze data, debugging overhead slows request processing and uses large amounts of disk space. EPS offers an easy and elegant way to turn debugging on and off selectively. In the following example, EPS turns debugging on only for requests with username bob@cisco.com. The environment variable Trace-Level sets the trace level, and Retrace-Packet makes Cisco Access Registrar display the full contents of the request received. This script could be set at the server incoming extension point: proc debug { request response environ } { set user [ $request get User-Name ] if { [ string equal $user "bob@cisco.com" ] } { $environ put Trace-Level 5 $environ put Retrace-Packet TRUE } }
Filtering Attributes The following example illustrates how to use EPS to validate a response from a RADIUS server. In this example, the remote RADIUS server is not in your administrative control, so you need to validate its responses. Here, the script looks in the response for the Framed-IP-Address attribute value of 255.255.255.255. If the script finds this value, it removes the attribute. To target a specific RADIUS server, use the remote server incoming extension point to target the response from that server: proc remove-bad-IP {request response environ} { if { [ $request containsKey Framed-IP-Address ] && [ string equal [ $request get Framed-IP-Address ] "255.255.255.255" ] } { $request remove Framed-IP-Address } }
To configure this example, create a file containing the TCL code. Name the file remove-bad-IP.tcl. Then, in aregcmd enter: cd /Radius/Scripts add remove-bad-IP cd remove-bad-IP set Language tcl set Filename <yourscripts dir>/remove-bad-IP.tcl cd /Radius/RemoteServers cd myRemoteServer set IncomingScript remove-bad-IP save reload
For more information on EPS scripting examples, refer to the samples that are part of your Cisco Access Registrar installation as follows: For EPS examples in C: <CAR DIR>/examples/rexscript/rexscript.c
For EPS examples in TCL: <CAR DIR>/scripts/radius/tcl/tclscript.tcl
Proxy AAA Proxy AAA is indicated in Figure 14-5 by the number 3. Proxy AAA enables the AR to proxy authentication requests to someone else's AAA server. This is done based on attributes it finds in the request. Providers can use filters that instruct AR to look at the dialed number (DNIS) or realm contained in the request packet. Figure 14-5. Proxy AAA 
An example of a realm might be the cisco.com in userbob@cisco.com. The filters include User-name suffix and prefix, DNIS, and NAS-IP-Address. The extension points that were discussed in the previous section can also be used to define other information in the request that you want to match. AAA AAA is indicated in Figure 14-6 by the number 4. This is simply the module that manages the AAA process locally in the AR. Figure 14-6. AAA in AR 
| 