Appendix K: Rules Hierarchy
The order/hierarchy of the Exit Point Manager rules are:
- Pre-filters
- Location Rules
- User Rules
Below is an explanation of each category of rules with the order/sequence of the specific rules in each group.
1) Pre-filters
Pre-filters allow you to combine a user and a location on a single rule, in addition to the server and the function. The order of the Pre-filters are based on server, function, location and user. See also Work with Pre-filters.
To configure Pre-filters, select one of the following on the Work with Pre-filters panel:
1. Work with Server Pre-filters
Server Pre-filters allow you to specify settings by server, for example, all transactions over the FTP server. The default system Pre-filter record has a Server of *ALL. These records can be changed but not deleted. The system (*ALL) record must have either a 'Y' or an 'N' for each of the settings (allow, audit, message, and capture). The subsequent individual server Pre-filters can inherit from this system value.
2. Work with Loc+User Pre-filters
Loc+User Pre-filters allow you to specify settings using a combination of the following:
- location
- user / user group
- server
- server function
For example, you can specify whether or not to allow a transaction for a specific combination of IP address, user, server, and server function. Allowing a transaction causes it to be further evaluated by Exit Point Manager rules; not allowing it is equivalent to an Exit Point Manager reject. You can change existing pre-Loc + User pre-filters and add new ones.
Option 2. Loc+User Prefilter takes precedence. If no rule is found for these, then the rules in option 1, Server Pre-filters, are evaluated. The Server Pre-filters are only evaluated if all the rules for a particular server under Loc+User Prefilters are deleted. (Server Pre-filter is a catch-all for a transaction if no other rules exist.) Once a transactions passes Pre-filters, the Location-User rules checking continues.
1-1) Exact Server, Exact Function, Exact Location, and User
The user is searched in the following order:
1-1-1) Specific individual user
1-1-2) Group profile
1-1-3) Supplemental group
1-1-4) All users or *PUBLIC
1-2) Exact Server, Exact Function, Location Group, and User
The user is searched in the following order:
1-2-1) Specific individual user
1-2-2) Group profile
1-2-3) Supplemental group
1-2-4) All users or *PUBLIC
1-3) Exact Server, Exact Function, Location (*ALL), and User
The user is searched in the following order:
1-3-1) Specific individual user
1-3-2) Group profile
1-3-3) Supplemental group
1-3-4) All users or *PUBLIC
1-4) Exact Server, Function (*ALL), Exact Location, and User
The user is searched in the following order:
1-4-1) Specific individual user
1-4-2) Group profile
1-4-3) Supplemental group
1-4-4) All users or *PUBLIC
1-5) Exact Server, Function (*ALL), Location Group, and User
The user is searched in the following order:
1-5-1) Specific individual user
1-5-2) Group profile
1-5-3) Supplemental group
1-5-4) All users or *PUBLIC
1-6) Exact Server, Function (*ALL), Location (*ALL), and User
The user is searched in the following order:
1-6-1) Specific individual user
1-6-2) Group profile
1-6-3) Supplemental group
1-6-4) All users or *PUBLIC
1-7) Server (*ALL), Function (*ALL), Location (*ALL), and User
The user is searched in the following order:
1-7-1) Specific individual user
1-7-2) Group profile
1-7-3) Supplemental group
1-7-4) All users or *PUBLIC
2) Location Rules
Location rules, like the Pre-filters, are sequenced from the most specific to the least specific.
Once a rule is selected, further checking stops unless the rule is a *MEMOBJ rule and neither a memorized transaction or an object rules exists for this transaction. The *MEMOBJ rule is ignored and processing will continue down the sequential order to the next rule.
2-1) Specific location (name or IP address) and specific function
2-2) Specific location (name or IP address) and all functions (*ALL)
2-3) Generic location (name or IP address) and specific function
2-4) Generic location (name or IP address) and all functions (*ALL)
2-5) All locations (*ALL) and all functions (*ALL)
The evaluation for location rules are based on location, function, and authority.
If the Authority column is *USER, Exit Point Manager proceeds to check the User Rules.
If the authority for the location rule has *MEMxxx, Exit Point Manager checks for a memorized transaction or an Object Rule. If no match is found, it will continue down the sequence and perform the action from the Authority column of the next location rule.
*MEMOS400 – Checks for a matched memorized transaction; if none are found, the transaction is allowed.
*MEMREJECT – Checks for a matched memorized transaction; if none are found, the transaction is rejected.
*MEMSWITCH – Checks for a matched memorized transaction; if none are found, the authority of the switch profile defined on the rule is used.
*MEMUSR – Checks for a matched memorized transaction; if none found, the user rule for this transaction is searched.
*MEMOBJ – Checks for a matched memorized transaction; if none found, the Object Rule for this transaction is searched.
2-6) *MEMOBJ Location Rule
Object Rules (*MEMOBJ) are associated either as a location or a user rule.
Object rules, like the other rules, are sequenced from the most specific to the least specific depending on whether the transaction was a memorized user or location rule. The most specific is an exact match, followed by the length of the string and/or the wildcard characters. The order depends on whether the initiating *MEMOBJ rule was a user rule or a location rule.
2-6-1) Can be a memorized transaction for the location
2-6-2) Object rule for the specific location
2-6-3) Object rule for the location group of the location
2-6-4) Object rule for all locations (*ALL)
2-6-5) Object rule for the specific user profile
2-6-6) Object rule for the group profile
2-6-7) Object rule for each supplemental group profile
2-6-8) Object rule for all users (*PUBLIC)
3) User Rules
User Rules, like the other rules, are sequenced from the most specific to the least specific.
Once a rule is selected, further checking stops unless the rule is a *MEMOBJ rule and neither a memorized transaction or an object rules exists for this transaction. The *MEMOBJ rule is ignored and processing will continue down the sequential order to the next rule.
3-1) Specific User and specific function
3-2) Specific User and all functions
3-3) Group Profile and specific function
3-4) Group Profile and all functions
3-5) Supplemental Group and specific function
3-6) Supplemental Group and all functions
3-7) All users (*PUBLIC) and specific function
3-8) All users (*PUBLIC) and all functions
The evaluation for user rules are based on location, function, and authority.
If the authority for the user rule has *MEMxxx, Exit Point Manager will check for a memorized transaction or an Object Rule. If no match is found, it will proceed down the sequence and perform the action from the Authority column of the next user rule.
*MEMOS400 – Checks for a matched memorized transaction; if none are found, the transaction is allowed.
*MEMREJECT – Checks for a matched memorized transaction; if none are found, the transaction is rejected.
*MEMSWITCH – Checks for a matched memorized transaction; if none are found, the authority of the switch profile defined on the rule is used.
*MEMOBJ – Checks for a matched memorized transaction; if none found, the Object Rule for this transaction is searched.
3 -9) *MEMOBJ User Rule
Object Rules (*MEMOBJ) are associated either as a location or a user rule.
Object rules, like the other rules, are sequenced from the most specific to the least specific depending whether the transaction was a memorized user or location rule. The most specific is an exact match, followed by the length of the string and/or the wildcard characters. The order depends on whether the initiating *MEMOBJ rule was a user rule or a location rule.
3-9-1) Can be a memorized transaction for the user
3-9-2) Object rule for the specific user profile
3-9-3) Object rule for the group profile
3-9-4) Object rule for each supplemental group profile
3-9-5) Object rule for all user profiles (*PUBLIC)
3-9-6) Object rule for the specific location
3-9-7) Object rule for the location group for the location
3-9-8) Object rule for all locations
Removing Default Rules
This section describes the effects on, and functionality of, audit rules when removing default server rules for each of the rules tables. The path or hierarchical order of rule checking is presented at each rule table test. (No testing results are available for the individual profile and group profile ordering.)
The normal hierarchy of transaction rule processing takes the following path until an applicable rule is applied:
Pre-filter => Location (sub Mem&OBJTrans) => User (sub Mem&OBJTrans) => Global rule
The Global Rule, comprised of the settings in the Work with System Values panel, is the final collection of settings for a transaction if no prior rule can be applied to the request. Only in one situation does the path diverge from the above path. (See Location rules below.)
Global Rule
The global rule facility contains the final setting for any transaction if no other rules are applied to a transaction request. It’s not possible to remove the global rule. The authority must contain a valid setting (*OS400, *REJECT, or *SWITCH) and cannot be altered or saved without selecting one. The shipped default value is *OS400.
User Rules
Removing User rules, such as the default *ALL or *PUBLIC, and named user rules, defers the decision to the Global Rule. If a transaction request cannot find any rule that would apply to an incoming transaction, the Global Rule for the authority setting and audit flags will be applied. If location rules are completely removed, and no *USER rule is found, the user rules will be skipped completely. Without User rules, settings are inherited from the expected path:
Pre-filter=>Location=>Global Rule
Location Rules
Removing Location rules (Default and IP address) defers the audit trail to the Global Rule. If a transaction cannot find any rule that would apply to a transaction, the audit flags in the Global Rule will be applied. An interesting item noted here is the transaction event trail, if all location rules are removed, the trail is not steered to the User table. The test sequence does not pass from Location => User but skips directly to the Global rule. With Location Rules removed the expected path is:
Pre-filter => Global Rule
Pre-filter Rules
It is not possible to remove the Server Pre-filters rules. You may remove the Location+User Pre-filters. Transaction requests are checked normally against location rules in the normal path.
Memorized and Object Rules
MEM[trans] Location and User Rules (e.g. MemOS400 or MEMOBJ) will test the memorized transaction and Object Rule table respectively. If no rule match exists that can be applied, the transaction is directed to the rest of the applicable rules inside that Table (Location or User). If a match is not found, the transaction test will follow the path Location=>User=>Global Rules until a rule is found, or until it reaches the Global rule settings.
