How The Software Handles An Access-Request

The server receives a request and authenticates the user. If authentication is successful, the authorization will begin.

Check Items After authentication each check item in the user profile is processed or matched against the request's A-V pairs. For example, a check item indicating that the request must be for PPP service must be matched by a corresponding Framed-Protocol=PPP A-V pair in the request in order for the request to be accepted.

Policy HP-UX AAA policy can be simple or complex decisions that control the authentication, authorization, and accounting process for a user's request. Simple policy has already been described as using lists of check and reply items. Complex policy refers to checking a logical A-V pair expression associated with a group of users for a true or false result. An A-V pair expression is represented by a Boolean logic statement that may include AND, OR, NOT Boolean operators and relative operators and may use parentheses to nest statements.

According to the result of this complex policy decision, which can be based on a wide range of criteria and comparisons, the AAA server can accept or reject the request, as well as control how services are delivered or logged. Some policies that can be implemented include:

By default, ProLDAP policy occurs after CHK_DNY, but you can define policy decisions in ProLDAP or text files (called decision files) and configure the server to evaluate the policy at any point in the authentication and authorization process—before authentication, for example— and as often as you would like. After the POLICY action evaluates a decision, it retrieves reply items that may be added to the Access-Accept message and returns a value that determines the subsequent sequence of actions followed by the FSM.

Local Authorization Server (LAS) The refers to the routines and code in the server that handle authorization. Both the LAS and POSTLAS actions are part of the LAS. Session control with the LAS is based on realms, refer to Figure 1-8 “Default Action Sequence”. A realm must be listed in the las.conf file, if not listed, LAS will not enforce any session control for users from that realm. When the LAS handles an Access-Request for a user in a local realm configured in the las.conf file, the LAS module performs the following steps:

The POSTLAS action performs simultaneous access token (SAT) control, which is used to implement realm-based simultaneous session control.

Reply Items One of the last actions that occur during authorization is the generation of an Access-Accept or Access-Reject message (refer to Figure 1-10 “Authorization Steps”) by the REPLY action (refer to Figure 1-8 “Default Action Sequence”). By adding reply items to a user's profile or through policy decisions, REPLY can provide a NAS with provisioning information in an Access-Accept data packet. Depending on the capabilities of the NAS, the reply items can be used to control a user's session. For example, the following user entry would limit the length of the session and what hosts could be accessed:

guest@library.org Password = "public" 
    Filter = "lib", 
    Session-Timeout = 3600

Users can authenticate as guest@library.org using password "public" to connect for one hour (3600 seconds) to the library hosts that the filter "lib" allows.
The REPLY action also checks for a Service-Type value, equates the value with one of three special user entries (pppuser, slipuser, dumbuser), and then appends reply items to the request accordingly. The attribute values for these items specify the default values to use when configuring the connection specified by Service-Type. The special user entries are not used for authentication; the reply items for one of these entries are appended to a request from any user requesting the corresponding service type.

When duplicate attribute-value pairs exist, in a user profile and policy decision for example, pruning is applied to determine which A-V pair should be included in the Access-Accept or Access-Reject message.