 |
» |
|
|
|
When the AAA server receives any RADIUS message, it calls
the FSM, and defines a starting event according to the type of message.
This first event determines the first action. In the default FSM,
the first action for an Access-Request is iaaaUsers. Figure 1-4 “Default Action Sequence” shows
how FSM actions interact to process the Access-Request for authentication
and authorization.
Authentication to
Verify the Client and User | |
The authentication of an access request has
a number of distinctive steps as shown in Figure 1-5 “Authentication Steps”. The rounded rectangles represent configuration files
that the HP-UX AAA server uses and the ovals represent
one or more authentication types. Authentication StepsAfter the AAA
server receives an Access-Request, it attempts to match the client
making the request to an entry in the clients file. The server attempts to authenticate a request
only if a match can be made. Next, iaaaUsers checks the local users file. In this step, the User-Name attribute value from
the Access-Request is used to find an entry for the user in the
text file. The server checks the file from beginning to end. When
the first match occurs, the remaining file entries are not checked. If User-Name
matches an entry, the server retrieves that profile, and then authentication
moved to step 5. If User-Name does not match
an entry, authentication moves to the next step.
With a realm file, the user’s name (e.g., “fred”)
is not required to be suffixed with the realm name (e.g., “abc.com”). However, the fact that the authfile entry (e.g., “abc.com
FILE abc.com”) has directed the server to the specified
realm file (“abc.com.users”) indirectly implies
the realm name, so the realm name needn’t be explicitly
specified in the realm file. The users file is not realm-specific; the users file configures users with null realms, as well as multiple
realms. So a realm name is required. That is, the users file may
contain the profile for multiple users named fred, for example, “fred”, “fred@abc.com”,
a “fred@xyz.com”. The realm name is used to retrieve
the correct profile. In a users file, each user must be individually configured. In
the above example, no steps were taken to configure any users in
realm “file.com”. If the iaaaUsers action does not find a matching user profile in
the users file, the FSM calls the iaaaRealm action. The iaaaRealm action parses the User-Name attribute value for
a realm name, and searches authfile to determine the data store
where the user profiles for the parsed realm are located. A default
entry can be used to handle any realms that are not explicitly configured
in authfile. | | | |  | NOTE: A User-Name value in the Network Access Identifier
(NAI) (described in RFC 2486) format must look like userid@realm.
If no realm is specified, the server assigns the value, NULL, to
the realm. Some NAIs appear as realm/username, but this syntax does
not comply with the RFC. | | | | |
The iaaaRealm action calls another action that then attempts
to retrieve a matching user profile from the data store for that
realm, as indicated by the authfile External
database may be an LDAP or Oracle server, or an authentication system,
such as SecurID. Proxies are forwarded to
another wireless security server for authentication Local operating system security
can look in or domain controller stored in the security system File refers to a realm-specific
users text file
Entries for the data stores require one or more parameters
that specify the location of external data sources and similar information.
If an authentication system is used, user authentication will occur
as the profile is retrieved and the FSM moves directly to authorizing
the users service. The user is authenticated according
to the protocol established by the Access-Request. If PAP is used
and the user’s password can be verified, authentication
succeeds. If an EAP method is used, mutual authentication is carried
out according to the EAP type (PEAP, TLS, TTLS, LEAP).
If User-Name matches no entry, either in a local text file
or an external data source, the authentication fails. Authorization
to Control Sessions and Access to Services | |
The HP-UX AAA server can authorize users
through a few different methods: Provisioning
on a user-by-user basis with check items and by
adding reply items to an Access-Accept message (simple
policy) Based on realms through its
Local Authorization Server (LAS) functions Based on other
logical groups through stored policy decisions (complex policy) that can
make check and add reply items to the request in a more sophisticated
manner
Like authentication, the authorization of
an access request has a number of distinctive steps as shown in Figure 1-6 “Authorization Steps”. The rounded rectangles represent
configuration files that the HP-UX AAA server uses, and
the ovals represent one or more actions called by the FSM. The dotted
lines and shapes indicate a step in the process that does not occur
with the server's default FSM configuration, but can occur with
a customized configuration. The server receives
a request and authenticates the user. If authentication is successful,
the authorization begins. Check Items. After authentication
each check item in the user profile is processed or matched against
the request’s Attribute-Value (A-V) pairs. For
example, a check item indicating that the request must be for
Point-to-Point
Protocol (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. If all
the check and deny items associated with User-Name are satisfied,
then the CHK_DNY action returns an ACK value to the FSM. If any check or deny item,
including the user’s password, is not matched correctly,
the authentication module returns a NAK value to the software engine.
The request fails, and an Access-Reject is issued.
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 uses 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.
A-V pair expressions can use parentheses to nest statements. According to the result of this complex policy decision,
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: Dialed Number
Identification Service (DNIS)—routing requests according
to the number called from or called. Grouping users by NAS addresses
or ports Control session duration,
concurrent usage, or delivered services—not based on user
or realm, but based on any other logical grouping that can be defined
by A-V pairs Control access according
to any time-based criteria
Local
Authorization Server (LAS). LAS refers to the routines and code
in the server that handle authorization. LAS and POSTLAS actions
are part of the LAS. Session control with the LAS is based on realms.
A realm must be listed in the las.conf file. If the realm is not listed, LAS does 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: Checks
the user profile for a Simultaneous-Session
attribute-value pair, which determines the maximum number
of active sessions the user can have. Default value is 1. Authorizes or denies service
to a user based on the user’s membership in a UNIX group. Authorizes or denies service
based on Service-Class.
The POSTLAS action performs Simultaneous Access Token (SAT) control,
which is used to implement realm-based simultaneous session control. Reply Items refers
to the generation of an Access-Accept or Access-Reject message
by the REPLY action. 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 limits the length of the session
and the hosts that can 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 user entries, 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 A-V pairs exist, pruning is applied to determine
the A-V pair that should be included in the Access-Accept
or Access-Reject message.
|
Printable version
