HP-UX AAA Server A.08.02 Administrator's Guide

In the following process flow, step 1 to step 5 (highlighted in blue in the figure) are related to
creating RADIUS sessions and step 6 to step 10 (highlighted in green in the figure) are related to
the Dynamic Authorization operation:
1. A client requests for access to a protected resource by sending user credentials to the
authenticator.
2. The authenticator forwards the request to the HP-UX AAA Server.
3. The HP-UX AAA Server verifies the credentials. Based on the success, the HP-UX AAA Server
adds a new session entry in the session table of the database.
4. After a successful authentication, the HP-UX AAA Server provides access.
5. The authenticator grants access to the user and a session is created.
6. The HP-UX AAA Server periodically checks the session table in the database.
7. Based on the configured conditions, the HP-UX AAA Server sends either a Disconnect or
a CoA request to the Authenticator.
8. The authenticator processes the Disconnect or the CoA request and makes the corresponding
changes to the user sessions.
9. Based on the result of the processing, the authenticator sends an ACK or NAK response.
10. Based on the response received, the HP-UX AAA Server makes the corresponding changes in
the session table of the database.
Processing of Dynamic Authorization Requests
The dynamic authorization functionality is implemented using the HP-UX AAA Server client
functionality. For more information on the HP-UX AAA Server client functionality, see Chapter 19
(page 210).
A client action is configured for each dynamic authorization request type. For each configured
client action, based on the configured time interval, the timer function of the CLIENT AATV generates
an empty request and places it in the initial state of the FSM. The sequence of steps involved in
the processing of this empty request through the FSM is as follows:
1. The client-request-init policy is invoked. In this step, the policies configured in /etc/
opt/aaa/client-request-init.grp are executed. The following things must be set
through this policy.
a. The SQL action to be executed for creating the dynamic authorization request should be
set in the attribute Client-Request-Create-ActionId.
b. The SQL action to be executed for updating the database to indicate that the row has
just been processed should be set in the attribute Client-Request-Update-ActionId.
c. The SQL action to be executed for updating the database if the dynamic authorization
request times out should be set in the attribute Client-Request-Timeout-ActionId.
d. The RADIUS message type of the dynamic authorization request should be set in the
attribute Interlink-Packet-Code.
2. The SQL Access AATV is invoked. The SQL Access AATV executes the SQL action set in
the attribute Client-Request-Create-ActionId. This SQL action will enter values in
the required fields of the empty request generated by the CLIENT AATV, based on the
information stored in a database table, to create the dynamic authorization request.
3. The SQL Access AATV is invoked. The SQL Access AATV executes the SQL action set in
the attribute Client-Request-Update-ActionId. This SQL action will update the database
table to indicate that this database row has already been processed.
4. The CLIENT AATV is invoked. The action function of the CLIENT AATV is executed. The
action function of the CLIENT AATV performs two major functions. One, it places the current
dynamic authorization request in the message queue for client messages. Two, it generates
another empty request and places it in the initial state of the FSM. Similarly, new dynamic
authorization requests are generated and placed in the message queue successively, thereby
resulting in a loop.
Processing of Dynamic Authorization Requests 215