 |
» |
|
|
|
When the HP-UX AAA server receives a RADIUS message, it calls
the FSM and defines a starting event according to the type of message.
This event is stored in the Interlink-Proxy-Action attribute. In the default FSM, the first action for all requests
is request-ingress POLICY. If this POLICY is executed successfully,
the next action is determined by the event stored in Interlink-Proxy-Action. By default, for an Access-Request
this action is iaaaUsers. Figure 1-4 shows how the 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. The rounded rectangles represent configuration
files that the HP-UX AAA Server uses and the ovals represent one or
more authentication types. Authentication StepsFollowing lists the authentication steps followed by the HP-UX
AAA Server: After the HP-UX
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. The iaaaUsers action 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 /etc/opt/aaa/users file. If User-Name matches an entry, the server retrieves
that profile and then authentication moves to step 5. If User-Name does not match an entry, authentication
moves to step 3.
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: If no realm is specified in the NAI, the server assigns the
value NULL for the realm. You can configure NULL realm behavior in
the same manner as named realms. | | | | |
The iaaaRealmaction calls another action that attempts to retrieve a matching
user profile from the data store for the realm, as indicated by authfile: A realm-specific AAA users file; An external data store, such as LDAP or a database; A Unix user profile service via the getpwent() system call.
If the realm is defined as a proxy, the RADIUS request is forwarded
to the target RADIUS server defined for this realm. The user is authenticated according
to the protocol established by the Access-Request. If a password-based
protocol (PAP,CHAP, MSCHAP) is specified, the user's password is verified.
If an EAP method is used, mutual authentication is carried out according
to the EAP type (PEAP, TLS, TTLS, or 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 using
one of the following methods: Provisioning on a user-by-user basis
with check items and by adding reply items to an Access-Accept message
(simple policy) Through Local Authorization Server (LAS) functions
based on realms Through stored policy decisions based
on other logical groups that can add check and reply items to the
request
Like authentication, the authorization of an access
request has a number of distinctive steps, as shown in Figure 1-6. The rounded rectangles
represent configuration files and the ovals represent one or more
actions called by the FSM. The server receives the Access-Request. The server evaluates the request-ingress
policy. This is the first step in the FSM, before the request is despatched
for processing. The request ingress policy can be used to alter the
request in one of the following ways: A-V pairs may be added, changed, or removed. The request classification may be altered. The request may be rejected immediately. The request may be dropped entirely, and no reply
is sent.
If the request-ingress policy is evaluated successfully,
the HP-UX AAA Server continues with the authorization process. If a request is being proxied, then the HP-UX AAA Server
evaluates the proxy-egress and proxy-ingress policies.
The HP-UX AAA Server applies the proxy-egress policy before the RADIUS
proxy request message is created and sent. The proxy-ingress policy
is applied after the proxy response is received. Table 1-2 discusses how these policies
are used to alter requests. Table 1-2 How Requests are Altered Using the proxy-egress and proxy-ingress
Policies | Use of the proxy-egress Policy | Use of the proxy-ingress Policy |
|---|
| A-V pairs can be added, modified,
or removed. | A-V pairs can be added,
modified, or removed. | | The request may be rejected immediately. | The reply type may be altered. | | The request may be dropped entirely
and no reply is sent. | The request
may be dropped entirely and no reply is sent. | | The proxy target host may be changed. | The request may be rejected immediately. |
Check Items. After authentication
each check item in the user profile is processed or matched against
the request's corresponding Attribute-Value (A-V) pairs. If all the check and deny items associated with User-Name
are satisfied, 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 FSM. The request fails, and an
Access-Reject message is returned to the client.
User Policy. All requests are subjected to user policy
after authentication. The user policy is applied only after successful
authentication. A user policy can be specified in a Policy-Pointer
attribute on the request as either a check item or a reply item. If
the Policy-Pointer attribute is found in the check items, then the
HP-UX AAA Server does not look for one in the reply items. The value
of the Policy-Pointer attribute should specify the URL for the decision
file to be evaluated. If a request contains a Policy-Pointer attribute,
as either a check item or a reply item, the specified policy is applied.
If the request does not contain a Policy-Pointer, then no user policy
is applied. In this case the POLICY action returns an ACK event to
the FSM. 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 by logical groupings defined by the contents of specified
A-V pairs; Control access according to any time-based criteria.
Local Authorization Server (LAS). The LAS refers to the
routines and code in the server that handles authorization. LAS and
POSTLAS actions are part of the LAS. Session control with LAS is based
on realms. Local Session tracking must be explicitly enabled for a
realm via the Server Manager or the /etc/opt/aaa/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 actions: 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 based on Service-Class.
The POSTLAS action performs Simultaneous Access Token (SAT)
control, which is used to implement realm-based simultaneous session
control. | | | | | NOTE: HP recommends not to enable local session tracking for any realms
utilizing session management via SQL Access. | | | | |
Reply items refer to the generation of an Access-Accept
or Access-Reject message by the ReplyPrep action. By adding reply items to a user's profile or through policy
decisions, ReplyPrep 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 = "library",
Session-Timeout = 3600 |
Users can authenticate as guest@example.org using password public to connect
for one hour (3600 seconds) to the library hosts that the filter library allows. The ReplyPrep 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. If duplicate A-V pairs exist, pruning is applied to
determine the A-V pair that must be included in the Access-Accept
or Access-Reject message. The HP-UX AAA Server evaluates the reply-egress policy
just before the RADIUS reply message is created and sent. The reply-egress
policy can be used to alter the request in one of the following ways: A-V pairs may be added, modified, or removed The reply type may be modified The request may be dropped entirely and no reply is
sent.
|
Printable version
