Appendix K: Rules Hierarchy
The order/hierarchy of the Exit Point Manager Version 6 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
In version R06M10, Exit Point Manager implemented an enhancement for Pre-filters.
Pre-filters allow you to establish a one-to-one relationship between a specific IP address (location) and a user. The order of the Pre-filters are based on server, function, location and user.
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.
