This begins a <Handler> clause.
When using the <Handler> clause, all requests
with a specific set of attributes are handled in the same way. You can
configure one or more <Handler> clauses into
your server, possibly with a different AuthBy authentication methods for
each.
The difference between <Handler>
and <Realm> is that
<Handler> groups together requests based on the
value of any attributes in the request, not just the user's realm as
<Realm> does. That makes
<Handler> clauses more powerful but they are
not required as often. A common situation is that you need to distinguish
between authentication methods based on the user's realm. Use
<Handler> instead of
<Realm> if you need to choose authentication
methods based on other attribute than Realm, such as
Called-Station-Id, Request-Type,
or some other attribute in the incoming RADIUS request.
In
<Handler checklist> the checklist expression is
a list of request attributes that must all match before
<Handler> is used to handle the request. The
format is similar as a list of check items in a user file: a list of
attribute=value pairs, separated by commas. For more
information, see
Section 7.1.
If
you omit the expression name from the <Handler>
line, the clause matches all requests.
When Radiator looks for
<Handler> to match an incoming request, it
searches each <Handler> clause in the order in
which they appear in your configuration file. It continues searching until
<Handler> is found where every check item in
the expression matches the request. If any check item does not match, it
continues onto the next <Handler> until all the
Handlers are exhausted. If none of the
<Handler> clauses match, Access-Request is
rejected and Accounting-Request is accepted.
Radiator uses the
following algorithm to find the <Realm> or
<Handler> to handle each request:
- Look for a Realm with an exact match on the realm name.
- Look for a matching regular expression Realm.
- Look for a
<Realm DEFAULT>.
- Look at each Handler in the order they appear in the configuration
file until one where all the check items match the request.
- Ignore the request.
It is possible to use both <Handler>
and <Realm> clauses in the same configuration
file but it is not recommended. Using them together may lead to
complicated handler selections and behaviour.
The following example
configuration uses 3 authentication methods used in different
requests:
<AuthBy SQL>This used when
Called-Station-Id is 662543 and
Service-Type is
Framed-User.
<AuthBy DBM>This is used when
Called-Station-Id is 678771 and
Realm is open.com.au.
<AuthBy RADIUS>This is used
authenticating all the requests that do not match to the previous
criteria.
<Handler Called-Station-Id=662543,Service-Type=Framed-User>
<AuthBy SQL>
......
</AuthBy>
</Handler>
<Handler Called-Station-Id=678771,Realm=open.com.au>
<AuthBy DBM>
.....
</AuthBy>
</Handler>
# Handles anything that was not handled above:
<Handler>
<AuthBy RADIUS>
.......
</AuthBy>
</Handler>
All instances of the given attribute are
checked, so it is possible to define a check that requires a request to
contain multiple values. Here are 2 examples of multiple values, both of
them are allowed:
# Request has attributes in a following order:
# OSC-Group-Identifier=A
# OSC-Group-Identifier=B
# Does match
<Handler OSC-Group-Identifier=B>
....
</Handler>
# Request has attributes in a following order:
# OSC-Group-Identifier=A
# OSC-Group-Identifier=B
# Does not match
<Handler OSC-Group-Identifier=B,OSC-Group-Identifier=C>
....
</Handler>
# Does match
<Handler OSC-Group-Identifier=B,OSC-Group-Identifier=A>
....
</Handler>
