OpenRADIUS Introduction
-----------------------


If you have anywhere between 10 and ten million users that may access
to 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. Three things make it special,
however:

1. its versatile interface to the outside world: this allows you to talk
   to other RADIUS servers (proxying), to existing Unix or NT user
   databases, SQL databases, LDAP trees, or whatever database you write
   a client module for, in whatever programming language;

2. its flexibility in controlling users' restrictions and profiles, 
   because you can use a built-in expression language to define exactly 
   how to handle a request: the server's business rules so to speak;

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 INTERFACES

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 number of access devices, and you have this list of NASes
available externally - in whatever database table or flat file, you can
easily add a rule that queries an interface that supports this database
or file type. That way you can check if the IP address of the NAS that
the user is trying to use, occurs in that particular table. 

You could do the same thing, but using the called phone number instead,
or the time of day, or both, or any other piece of information that the
server has available about an access request.

If you want to know more about the way these interfaces work, see the
file doc/module_interface.


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 information from your databases 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.

More information about the language that is used to control the server's
behaviour is available in doc/behaviour_language.


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 or to increase
availability: when you specify that a particular request is to be
proxied, you can specify multiple redundant target servers. 

The RADIUS client module will choose one at random, unless it knows
(because of a failed previous request) that a certain server is down. It
then skips that server, until test requests that are sent every once in
a while to dead servers show that the remote server is available again.

The proxying functionality is achieved by a RADIUS client module that
uses OpenRADIUS' standard external interface. For more information about
this module, see modules/radclient/README.


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. See doc/packet_handling for more details.

