 |
» |
|
|
 |
A decision file contains group entries that
define conditions based on combinations of A-V pairs and
associates each condition with a set of returned A-V pairs.
These files are only used when the radius.fsm file has been modified to call a specific decision
file. Decision files may be used for complex policy decisions, for
logging, and for other custom server configurations.(Refer to Chapter 14 “The Finite State
Machine (FSM) ” for more information
about radius.fsm modifications. If a decision file is being used,
the AAA server will evaluate each condition according to A-V
pairs in RADIUS messages, like the Access-Request, and
other values generated by the server. When a condition evaluates
to true, the server will return the associated attribute values
as reply items and can return an event value to the Finite State
Machine. There are sample decision files in the /etc/opt/aaa directory that provide a template for implementing
DNIS routing and DAC decisions. You can also create your own decision
files, but they must be stored in the same directory that contains
the server's other configuration files. There are no required naming
conventions for a decision file, but the file name must match its
reference in radius.fsm.  |  |  |  |  | IMPORTANT: Decision files are read from beginning to end.
When the first match occurs, the server will ignore the remaining
entries. |  |  |  |  |
Syntax of a decision file Group Name { Condition { expression } Reply { reply-items . . . } |
- Group
Begins the group entry by
specifying a Name for the group. - Condition
Block that contains an
expression of A-V pairs. They will evaluate to true or
false to determine if the user belongs to the group. If condition
is not defined in the group entry, the group will match all requests. - Reply
Block that contains a list
of one or more reply items that will be added to the request if
condition evaluates to true.
Expressions |  |
The simplest expression would be a comparison of two A-V
pairs with one relative operator. You can use relative and Boolean
operators to create an expression with various combinations of A-V
pairs and comparisons. The following operators may be used: Table 15-6 A-V Pair Expression Operators | Operator | Description |
|---|
| = | Equal to | | != | Not equal to | | > | Greater than | | < | Less than | | >= | Greater than or equal to | | <= | Less than or equal to | | && | Logical AND | | || | Logical OR | | ! | Logical NOT |
You can also use parentheses to nest expressions, and line
breaks are not significant. For example, suppose you wanted to control access according
to the dial-in phone number and time called. The following
table illustrates some possible expressions: Table 15-7 A-V Pair Expression Examples | Expression Example | Description |
|---|
Calling-Station-Id = 123456789 || Called-Station-Id
= 8005551212 | Allows access if either the calling number
or the called number match the specified values. | | Day-Of-Week => Monday && Day-Of-Week <=
Friday | Allows access if the day of the week is between Monday
and Friday. | ((Calling-Station-Id = 123456789 || Calling-Station-Id
= 987654321) && Called-Station-Id = 8005551212) || !(Day-Of-Week
=> Monday && Day-Of-Week <=
Friday) | Allows access when one of the following is
true: The calling number matches either specified value and
the called number matches the specified number. The day
of the week is not between Monday and Friday |
Your expressions may be as short or as long as you like. Since
only one group match can be made for each request, you may want
to use shorter expressions and manage each distinct decision (DNIS
routing, dynamic access control, membership in groups, etc.) in
a separate file; however, it would be possible to create a single
file with longer expressions that covered a wide range of decision
criteria. Specifying
Attributes in Group Entries |  |
You can create decision groups for provisioning
with the A-V pairs that may be used in a user profile for
session logging with accounting attributes, refer to Chapter 7 “Logging and Monitoring ”. In addition, you can use
the following attributes to define a group condition or reply.
Day-Of-Week A
string, representing the day of the week (spelled out or three letter abbreviation),
or a number from 0 to 6, where 0 represents Sunday and 6 represents
Saturday. This attribute is compared to the current system clock
of the machine hosting the AAA server that is making the comparison. Date-Time 24
hour clock in yyyy:mm:dd:hh:mm format. This attribute is compared
to the current system clock of the machine hosting the AAA server
that is making the comparison. Time-of-Day 24
hour clock in hh:mm format. This attribute is compared to the current system
clock of the machine hosting the AAA server that is making the comparison.
Hours must be two digits, for example, 08:00, not 8:00. Decision You assign
a value to this attribute that corresponds to a predefined or custom event that will
be returned to the finite state machine
when the group entry's condition has evaluated to true. Interlink-Packet-Code An
integer value that indicates what type of RADIUS message has been
received: either 1 (Access-Request) or 4 (Accounting-Request). Interlink-Proxy-Action A
string determined by information in an Access-Request or Accounting-Request.
This indicates the name of the starting event in the FSM when the
AAA server receives a RADIUS message. You can preempt this value
by beginning radius.fsm with an *.*.ACK event that invokes the POLICY
action, which could then determine the start event based on a policy
decision. User-Id After
the AAA server parses the NAI, it assigns the user name to this
attribute. User-Realm After
the AAA server parses the NAI, it assigns the realm to this attribute. Using
Indirection |  |
You may also use indirection to compare or assign attribute values to each
other. Follow a Test Operator $Value$Pos$Len syntax, where Test is the attribute to check or assign a value to,
and Value is the attribute with the value to check against
or assign to the Test attribute; Operator is the relative or Boolean operator to use. $Pos and $Len are optional parameters that allow you to test
or assign a substring
of the specified Value attribute. Pos indicates the index position in the attribute's
value to begin the substring and if specified Len determines the length. When used in the condition section of a group entry, indirection
checks values. When used in the reply section, it assigns a value.
For example, in an expression Port-Id <= $Port-Limit would only allow access to users who access the
server through ports that don't exceed the limit set in their profile.
As a reply item Decision = $Interlink-Proxy-Action would assign the current FSM event to the Decision attribute.  |  |  |  |  | NOTE: Test = $Value$Pos$Len will add a new A-V pair to the request.
It will not update an existing pair. For example, when the request
includes a Test = "String" A-V pair,
the expression Test = $Test$2$3 will append Test = "rin" to the
request, which results in both Test = "String" and
Test = "rin" in the request. Because the left-side attribute is handled
differently than the right-side attribute value, multiple
attributes in a request can cause some unexpected indirection results.
Each instance of the left-side attribute is AND'd, but
only the value of the right-side attribute's last instance
is used. For example, the expression Test < $Test would
evaluate to FALSE as (Test1 < 1) && (Test2 < 1) when
the request contains the A-V pairs Test1 = 1 and Test2
= 2. |  |  |  |  |
Example
Group Entries |  |
The HP-UX AAA server includes two sample decision
files: /opt/aaa/examples/config/DNIS.grp for DNIS routing /opt/aaa/examples/config/DAC.grp for dynamic access control
DNIS.grp
for DNIS RoutingThis example shows a simple DNIS routing scheme. Refer to Chapter 7 “Logging and Monitoring ” for an example of
a modified radius.fsm file that will work with this decision file. 1 Group Controlled-Access { 2 Condition { 3 (Calling-Station-Id = 1234567890) || 4 (Called-Station-Id = 8005551212) 5 } 6 Reply { 7 Authentication-Type = radius 8 Server-Name = flatland.com 9 Server-Port = 1812 10 Decision = Forward 11 } 12 } 13 Group Denied-Access { 14 Condition { 15 Called-Station-Id = 8001234567 16 } 17 Reply { 18 Authentication-Type = blackhole 19 Decision = Abandon 20 } 21 } 22 Group NORMAL { 23 Reply { 24 Decision = $Interlink-Proxy-Action 25 } 26 } |
 |
- Line 1
Names the first group entry
Controlled-Access. - Lines 2 to 5
If the user calls from 1234567890,
or calls into 8005551212, the user belongs to this group. - Lines 7 to 9
The Authentication-Type attribute
indicates that requests from members of this group should be proxied.
The Server-Name and
Server-Port attributes
specify flatland.com:1812 as the remote server that should receive
the proxied request. - Line 10
The Decision attribute
returns the Forward value to the FSM as an event. The radius.fsm file must be modified to recognize this event
and to call the RADIUS module when it occurs, refer to Chapter 7 “Logging and Monitoring ”. - Line 13
Names the second group entry
Denied-Access. - Lines 14 to 16
If the user calls into 8001234567,
the user belongs to this group. - Lines 18
The Authentication-Type
attribute indicates that the request should be ignored. - Line 19
The Decision attribute
returns the Abandon value to the FSM as an event. The radius.fsm file must be modified to recognize this event
to end the request when it occurs, refer to Chapter 7 “Logging and Monitoring ”. - Line 22
Names the third group Normal.
Since this group entry does not include a condition section, all
requests that have not been matched to the previous two groups will
be matched to this group. - Line 24
This line uses indirection
to pass the current event ($Interlink-Proxy-Action)
to the FSM, so the server will handle the request as if DNIS routing
did not occur.
DAC.grp
for Dynamic Access ControlThis example shows a simple DAC decision scheme based on the
value of an Access-Group attribute. Allow access
to users in the weekday group during a weekday Allow access to users in
the daytime group during the day Allow access to users in
the nighttime group during the night Otherwise, deny access to
users
Refer to Chapter 7 “Logging and Monitoring ” for
an example of a modified radius.fsm file that will work with this decision file. In
addition, this decision file would only work if the Access-Group attribute were
added to the dictionary and added to user profiles as a configuration
item, refer to “dictionary ”.  |
1 Group Weekday-Access { 2 Condition { 3 (Access-Group = weekday) && 4 ((Day-Of-Week >= Monday) && (Day-Of-Week <= Friday)) 5 } 6 Reply { 7 Decision = ACK 8 Reply-Message = "Weekday access allowed" 9 } 10 } 11 Group Daytime-Access { 12 Condition { 13 (Access-Group = daytime) && 14 ((Time-Of-Day >= 06:00) && (Time-Of-Day <= 20:00)) 15 } 16 Reply { 17 Decision = ACK 18 Reply-Message = "Daytime access allowed" 19 } 20 } 21 Group Nighttime-Access { 22 Condition { 23 (Access-Group = nighttime) && 24 ((Time-Of-Day < 06:00) || (Time-Of-Day > 20:00)) 25 } 26 Reply { 27 Decision = ACK 28 Reply-Message = "Nighttime access allowed" 29 } 30 } 31 Group Denied-by-timed-access { 32 Reply { 33 Decision = NAK 34 Reply-Message = "Time-Based access denied" 35 } 36 } |
 |
- Line 1
Names the first group entry
Weekday-Access. - Lines 2 to 5
If the user belongs to the
weekday access group and calls on a weekday they belong to this
group. - Line 7
The Decision attribute returns
the ACK value to the FSM as an event, which will accept the request. - Line 8
Specifies a message that
will be sent back to the user. - Lines 11 to 30
Define the second and third
groups with a structure similar to the first group entry. - Line 31
Names the fourth group Denied-by-time-access.
Since this group entry does not include a condition section, all
requests that have not been matched to the previous two groups will
be matched to this group. - Line 33
The Decision attribute
returns the NAK value to the FSM as an event, which will reject
the request. - Line 34
Specifies a message that
will be sent back to the user.
|