States

Each state defined in a finite state table starts with a line containing just the name of the state, followed by a colon character. Each subsequent line is an event handler with three required and two optional fields, delimited by spaces or tabs:

State-name:
    Event-1   Action-1   Next-state-1   Xvalue=integer Xstring=string
    ...       ...        ...
    Event-n   Action-n   Next-state-n   Xvalue=integer Xstring=string

State-name

An arbitrary string to represent a state in the FSM. It may be any printable ASCII character except space, new line, carriage return, tab, and colon (:) characters.

Every state except the Start state must be referenced by at least one event handler in any state as its next state.
Every state except the End must have at least one associated event handler.
Every state referenced in an event handler must be defined and is only defined once in the finite state machine.

Event-n

Three-tuple with each part separated by a period character in the form Last-state.Last-action.Event-name

Last-state The name of the state that generated the event or an asterisk character (*)—that will match any state—if there is no last state for the event or if the last state does not matter.
Last-action The name of the action that generated the event or an arbitrary string (found in the code or arrived in a packet), prefixed with a plus character. This action also may be an asterisk character (*)—that will match any action—if there is no last action or if the last action does not matter. When preceded by a plus sign, this string does not refer to the last action, but a value that is assigned to an internal attribute, Interlink-Proxy-Action, according to what type of message was received and from where it was received.
Event-name The string returned from Last-action:

Action-n

Name of the action to call. The called action will return a value that will be used to determine the next action. Refer to “Actions ” for a list of commonly called modules.

Typically, the AAA server invokes AUTHENTICATE upon receipt of an authentication request. AUTHENTICATE in turn invokes the proper authentication module (PROLDAP, ORACLE, etc.), depending on the configuration of the request in question. This process is specific to the server's default state table.

Next-state-n

Name of next state in the AAA transaction. The current State-name, Action-n, and the value returned from the called AATV ( Event-name) will be used to determine which event listed under Next-state-n should be processed.

Xvalue=integer

An A-V pair (integer value) that may be passed to an Action as an argument. Only one integer argument may be specified for each event.

Xstring=string

An A-V pair (string value) that may be passed to an Action as an argument. Only one string argument may be specified for each event.

Using Xstring to call Policy

With the POLICY module, you can use the Xstring parameter to specify an URL where policy definitions are stored. These policies group requests based on A-V pairs in an Access-Request and allow the request to be resolved differently according to those values. For example, with some additional modifications to the finite state machine you may control access based on dial-in date and time or perform DNIS routing based on the number dialed or other criteria.

    Xstring=decisionfile:Filename 
    Xstring=proldap:Realm#Policy-pointer

This syntax allows you to point to policy stored in a flat file (called a decision file, refer to “Decision Files ”), where Filename is the name of the file, or in a directory server, where Realm is the name of the realm that contains the ProLDAP policy and Policy-pointer is the distinguished name of the policy. When stored in a decision file, policy is grouped and defined by an expression of A-V pairs and reply items that are added to the request if the expression evaluates to true.




	IMPORTANT: If the POLICY action that reads the stored policy occurs before the AUTHENTICATE action in the FSM, reply items added to the request will be superceded by any duplicate attributes in a user profile, including the DEFAULT and special user entries. Conversely, if POLICY occurs after AUTHENTICATE the user's reply items will be superceded by the group entry's items. For session logging, POLICY must occur before the LOG action in the FSM.




	NOTE: You can configure the FSM to call the POLICY action more than once. The FSM must call POLICY in multiple instances for each different decision file or ProLDAP location you wish to use.

Using Xstring to Call an Alternate authfile

With the REALM action you can use the Xstring parameter to point to an alternate authfile. Simply follow the syntax Xstring=Filename, where Filename is the name of the alternate file. The default finite state table does not directly call the REALM action, which is ordinarily called by the AUTHENTICATE action when a user profile specifies the Realm authentication type. If you wish to use Xstring to call an authfile, you will need to modify the finite state table.

States

Technical documentation

» Table of Contents

» Glossary

» Index

Using Xstring to call Policy

Using Xstring to Call an Alternate authfile