Authorization

RADIUS allows authorization attributes per user as defined in the authorization policy files, default.auth and default.policy.

Authorization attributes are valid RADIUS protocol attributes that are specified in the RFC and defined in the /etc/radius/dictionary file. Authorization is optional and depends on how the hardware NAS or access point is configured. You must configure authorization attributes if they are needed. Authorization only happens after a successful authentication occurs.

Policies are configurable user attribute-value pairs that can control how the user accesses the network. Policies can be defined as being global to the RADIUS server, or user-specific.

Two authorization configuration files are shipped: /etc/radius/authorization/default.auth and default.policy. The default.policy file is used to match the incoming access request packets. The file contains attribute-value pairs that are initially blank and must be configured to the desired settings. After authentication, the policy will determine if an access accept or access reject packet is returned to the client.

Each user can also have a user_id.policy file. If a user has a unique policy file created for their specific user ID, then that files' attributes are checked first. If the attribute-value pairs in the user_id.policy file do not exactly match, then the default.policy file is checked. If the attribute pairs from the access request packet do not match in either file, then an access reject packet is sent. If a match is found in one or the other file, an access accept packet is sent to the client. This effectively establishes two levels of policy.

The default.auth file is used as the list of attribute-value pairs to return to the client once the policy has been checked. The default.auth file also contains attribute-value pairs that are initially blank and must be configured to the desired settings. You must edit the default.auth file or use SMIT to configure the desired authorization attribute settings. Each attribute that contains a value will automatically be returned to the NAS in an access accept packet.

You can also define user-specific return authorization attributes by creating a file based on the unique user name with the .auth extension, such as user_id.auth. This custom file must reside in the /etc/radius/authorization directory. There is a SMIT panel that allows you create and edit each user file.

Each user's authorization attributes are sent back in an access-accept packet along with any default authorization attributes found in the default.auth file or the global.auth file..

If the values are common in the default.auth file and the user_id.auth file, then the user's values override the default values. This allows for some global authorization attributes (services or resources) to all users and then for more specific, per user, level of authorization.

Beginning with AIX® Version 6.1 with the 6100-02 Technology Level, RADIUS supports a global.auth authorization file. This file replaces and enhances the original intention of combining user-specific authorization attributes (as defined in user_id.auth files) with a set of global authorization attributes.

The user_id.auth file, unlike the default.auth file, is overridden by similar attributes found in the user-specific authorization files, but instead will combine with them allowing for more flexibility in maintaining authorizations for users.

If the attributes are common in the default.auth file and the user_id.auth file, then the user's values override the default values. This overriding of default values allows for some default authorization attributes (services or resources) to all users and then for more specific, per-user level of authorization.

The same is true for attributes in the global.auth file, except that they do not get overridden by the user_id.auth attributes. Instead, the attributes in the two files are combined. This is useful when you are specifying vender-specific attributes (VSA).

The authorization process is as follows:

1. At daemon startup time, the default policy and authorization lists from the /etc/radius/authorization/default.policy file, default.auth file, and default.auth file are read into memory.
2. Authenticate the user ID and password.
3. The incoming packet is checked for attribute-value pairs.
   1. Check the custom user_id.auth file.
   2. If no match is found, then check the default.policy file.
   3. If no match is found, then send an access reject packet.
4. Apply the user's authorization attributes if there are any.
   1. Read the /etc/radius/authorization/user_id.auth file and the default.auth file, and compare the two entries.
   2. Use the entry that is in the user's file above the default entry.
   3. Combine the resultant attributes with the attributes that are found in the global.auth file.
5. Return the authorization attributes in an access accept packet.