 |
» |
|
|
|
The
HP-UX AAA Server Architecture consists of three primary
components: Configuration
files. By editing these flat text files, with either the Server
Manager user interface or with a text editor, you can provide the
information necessary for the server to perform authentication,
authorization, and accounting requests for configured users. AATV plug-ins perform
discrete actions; such as initiating an authentication request, replying
to an authentication request, or logging an accounting record. The software
engine, which includes the Finite State Machine (FSM) and some associated routines.
At server startup, the finite state machine reads instructions from
a state table—by default the /etc/opt/aaa/radius.fsm text file. The state table outlines what AATV
actions to call and what order to call them in.
When the server is initialized, it performs a few distinct
operations. It loads and initializes the AATV plug-ins,
so that actions can be executed when called by the finite state
machine. It also reads the configuration files to initialize the
data required for the actions to execute according to the application’s
requirements. Configuration
Files | |
The
HP-UX AAA Server reads data from the following configuration files
installed at /etc/opt/aaa/ by default: Table 1-1 HP-UX AAA Server Configuration Files | File | Description |
|---|
| clients | Information about all RADIUS clients—name, address,
shared secret, type, etc.—that allows the server to recognize
and communicate with the clients. | | authfile | Authentication type parameters for defined
realms. | | users | Information about user IDs, passwords, and check/deny/reply
items. | | <realm name>.users | The same information as the users file, but this user information is associated
with a particular realm. These files are only necessary to perform File
type authentication for a defined realm. Realms are recognized by
the realm component of the user’s Network Access Identifier,
for example: user@realm.com. | | | |  | NOTE: This is a user generated
file, it does not ship with the product. | | | | |
| | decision | Policy information for user authorization
and session control based on any logical group that can be defined
with A-V pairs. | | | | | NOTE: This is a user generated file, it does
not ship with the product. | | | | |
| | las.conf | Defines services for session control based
on realms. | | vendors | Optional entries for vendor-specific behavior. | | dictionary | Defines all attributes and values that may
be used to build attribute-value (A-V) pairs that will be recognizable
by the server. These A-V pairs contain information about requests
and responses. This file also contains definitions for all the authentication types
that the server recognizes. | | log.config | Specifies the predefined session log formats
to use. | aaa.config | Calls engine.config and contains properties for the following: | iaaaAgent.conf | Specifies how often the AAA server’s
SNMP subagent will check to see if a master agent is active. | EAP.authfile | Used to configure EAP authentication
for user profiles. | db_srv.opt | The configuration script for the db_srv environment variables. | engine.config | Called by aaa.config, this file stores most of the AAA server properties. |
You can find out more information about these files by referring
to the HP-UX AAA Server Administrator’s
Guide. Each configuration file also contains comments
with examples. AATV
Plug-Ins | |
Define
actions to perform functions, such as authenticating requests, authorizing,
and logging. Built-in actions support authentication of
users from information in different storage methods. The AATV plug-in
files are in /opt/aaa/aatv/. The
Software Engine: Finite State Machine | |
In
the Finite State Machine, a request will transition through a series
of states, starting with a state that includes possible starting
events. The first action specified to be called in response to an
initial authentication request would return a value, an event that
determines the next state to transition to. Within each state, the
next action is triggered by an event (based on previous state and
action and a value, typically ACK or NAK, returned by the previous action),
which in turn directs the flow of the request to another state,
until an End state is reached. |
Printable version
