OpenRADIUS is a RADIUS server that runs on many variations of unix, and has a number of interesting features:

• Ability to get shared secrets, authentication information, policies and user profiles from any available external data source;
   
  
• Support for Unix password databases, including NIS/NIS+, Livingston-style ASCII files, LDAP directories and SQL databases out of the box;
   
  
• Fully customizeable authentication schemes and security policies, using a built-in business rule language. This allows you to fully specify how the server makes its decisions, based on any combination of internally and externally available information;
   
  
• Simple, scaleable and fully documented module interface. Modules may supply data such as user information, and may also store data such as logging and accounting.
   
  Modules can be written in any language that supports ASCII or binary Unix pipe I/O. They are pre-spawned and reused instead of executed for each request, which preserves scaleability while still allowing the use of simple external scripts. All external subprocesses are fully supervised by the main server process and are automatically restarted if they crash.
   
  The interface allows multiple module subprocesses to be started for each data source, allowing modules to be single-threaded while retaining support for multiple concurrent requests to the same data source. This design also provides load balancing, transparent failover, scaleability across multiple processors and connection pooling to backend databases;
   
  
• Extremely flexible dictionary that can be made to support any type of non-standard vendor-specific attribute, including multiple attributes inside the same VSA, non-standard attribute IDs or length fields, subfields, and much more;
   
  
• Binds to a single or multiple IP addresses/network cards, and listen on multiple ports;
   
  
• Free to use, modify, and redistribute under the terms of the GNU General Public License.
   

If you have anywhere between 10 and ten million dialup users accessing your network, you probably already use a RADIUS server to save you from having to store and maintain their passwords and profiles on the network access devices themselves.

OpenRADIUS has this exact same purpose. There are three things that really distinguish it though:

1. its versatile interface to the outside world: this allows you to talk to other RADIUS servers, to your existing Unix or NT user databases, SQL databases, LDAP trees, or whatever type of database that you write a client module for, in whatever programming language, and use the retrieved information in any part of the decision-making process;

2. its flexibility in controlling that process and defining user profiles, because its built-in expression language allows you to define exactly how a request must be handled, from its reception to its answer;

3. its powerful dictionary: it can be made to support all types of vendor-specific attributes, whether they resemble standard RADIUS attributes or not.
    
   

Versatile backend interface

Many RADIUS servers support multiple types of backend databases. But most will put big constraints on the way your database is layed out, or are very limited in the types of information that may be retrieved from external sources; in most cases only passwords and static profiles, no RADIUS proxy targets, calling number restrictions, shared secrets, or anyting else.

OpenRADIUS allows you to use external information for anything you create a business rule for.

For example, if you only want to allow a type of users to use only a particular set of access devices, and this list of NASes is available in any supported database type or flat file format, you can easily write a business rule to check if the IP address of the NAS that the user is trying to use occurs in this table.

Of course you could do the same thing with the called phone number, port type, time of day, or any other piece of information the server has available when an access request comes in.

Better yet, it allows you to add new interface modules to talk to databases. Using its open and simple module interface, you can get the business rules to use any type of information that you can access using any programming language, whether that is C, C++, Perl, Java, Awk, a Unix shell or whatever, as long as it supports Unix pipe I/O.

Using external programs as interface modules does not come with the performance hit you may expect, because they are only started once instead of being invoked for every request, unlike other RADIUS servers do that support external scripts.
 

Flexible behaviour

You can use the business rules described above not only to define certain restrictions for certain users, but also to specify exactly what information the server should put in its answer to the network access device.

In fact, the rules that you write govern all aspects of how requests are handled, from their reception to their answering. And, because these rules have external interfaces to your databases at their disposal, you can use their information to define not only the server's answers, but almost every aspect of the server's behaviour.

This means that you are in full control of the interface between your databases and your network access devices. You define how OpenRADIUS uses your databases to define the NASes operation.

Information from an external source can be used to determine what external source is queried next. Or it can specify that the request should be left unanswered. Or that the request should be logged somewhere. Anywhere, because the external interfaces are bi-directional. Logging accounting information also happens though the standard module interface.

That means that you can get your proxying destination tables from any type of database. You can store your accounting information in any type of database. You can keep track of who is logged in using a session database. You can have your modules do on-line queries on your NASes to see if somebody is indeed already logged in, before rejecting access.
 

Reliable proxying

If you're an ISP, and you're reselling ports on your access servers to third parties whose users you can recognise by some prefix, suffix, or a particular dialed number, you're probably already using a RADIUS proxy of some kind.

Most proxies, have restrictions on how they decide upon their proxy target, or are very inflexible if you want to specify what information they forward to the remote server and what they accept in response.

With OpenRADIUS, you use your own business rules to decide when and where to proxy to, and the extent to which you allow the remote server's answer to define the response that's sent to the NAS.

The remote server may be chosen based on a part of the username, based on the dialed phone number, or any other piece of information that's available about a request. You can also get the IP addresses and shared secrets for your remote server from any external source you like, so that you can easily maintain these destinations.

Proxying can also be used for load balancing and to increase availability: when you specify that a particular request is to be proxied, you can specify multiple target servers.

This functionality is actually achieved by a RADIUS client module that uses the standard module interface.
 

Powerful dictionary

Many RADIUS users have come to know the annoying habits of vendors to invent new ways to represent their information in RADIUS packets, even when perfectly suitable encapsulation mechanisms already exist.

Sadly, RFC 2865 doesn't require the contents of the RADIUS vendor- specific attribute (attribute 26) to contain the same fields as normal attributes have to specify their attribute ID and length.

This has led to strange varieties like 2- and 4-octet attribute numbers, length specifications that don't include the attribute- and length fields, multiple vendor attributes inside one encapsulating attribute 26, etc.

Luckily, OpenRADIUS can receive and send all these types of attributes. It even allows you take any part of the RADIUS packet, including fixed fields such as the RADIUS Code and Authenticator, as standard attributes for use in the business rules.

Generated on Sat Jul 2 01:18:04 2011 by decorate.pl / menuize.pl