Stargazer

Previously we supported FreeRADIUS using a pair of plugins: an rlm_stg module on the FreeRADIUS side and a mod_radius plugin on the stg side. rlm_stg was hard to maintain because of bad support of C++ on the FreeRADIUS side, so the feature was abandoned.

Now we have async-radius library and it is possible to implement RADIUS protocol support directly on the stg side.

The new plugin should respond to RADIUS requests and perform authentication and authorization of users. It should also provide some information back to the client. The behavior must be configured by usual means, as it is done for other plugins.

Authentication process is configured in the 'auth' subsection, authorization process is configured in the 'autz' subsection. The subsections must contain 'match' and 'send' values. Both values are comma-separated lists of key-value pairs. E.g.

<auth>
    match="Login-Service='Login-User',User-Name=login,User-Password=password" 
    send="" 
</auth>
<autz>
    match="Calling-Station-Id=userdata0" 
    send="Cleartext-Password=password" 
</autz>

Values specified in quotes (e.g., 'Login-Service') are treated as direct values. Values specified without quotes (e.g. userdata0) treated as stg user parameter values.

When AccessRequest comes, its handling is preformed as follows:

1. take all request attributes and values;
2. cycle through all users;
3. for each 'auth' and 'autz' subsections:
   1. for each user check if the attribute value from the 'match' parameter, specified to the left of the '=', matches the value specified to the right;
   2. if the attribute value does not match a direct value, exit the user cycle, proceed to the next section;
   3. if the attribute value does not match a user parameter value, proceed to the next user;
4. if we found a matching user, prepare and send AccessAccept packet with attributes specified in the 'send' parameter filled with values from the parameter (direct or user parameter values);
5. if we found a matching user in while processing 'autz' section, in addition to sending AccessAccept packet, perform user authorization in the stg system;
6. if we did not find a matching user, send AccessReject packet without any attributes.

Consider the following example. Imagine we have an stg instance with the following data:

 login | password | userdata0
-------+----------+-------------------
 test1 |   123456 | foo
 test2 |   645321 | 84:ba:59:00:dd:23

AccessRequest:
Login-Service=Login-User
User-Name=test1
User-Password=123456

This request matches the first user, sending
AccessAccept

(the packet is empty because the 'send' parameter in the 'auth' section is empty)

AccessRequest:
Calling-Station-Id=84:ba:59:00:dd:23

The request matches the second user, sending
AccessAccept:
Cleartext-Password=654321

(the attribute 'Cleartext-Password' is taken from the 'autz' section)

AccessRequest:
Login-Service=Framed-User
User-Name=test1
User-Password=123456

The request does not match any user (wrong Login-Service attribute value), sending
AccessReject

AccessRequest:
Calling-Station-Id=fc:b0:de:57:65:39

The request does not match any user (no users with userdata0=fc:b0:de:57:65:39), sending
AccessReject

AccessRequest:
Login-Service=Login-User
User-Name=test3
User-Password=1111

The request does not match any user (no user with login 'test3'), sending
AccessReject

AccessRequest:
Login-Service=Login-User
User-Name=test1
User-Password=1111

The request does not match any user (user 'test1' has different password), sending
AccessReject