More on Access Control Rules - Insite web UI

The power of Exit Point Manager resides in its ability to control network access to IBM i network servers and server functions according to the rules you specify.

As discussed earlier (see Implementing Exit Point Manager, you can set rules for a User (user profile), Group profile, or Supplemental Group profile. For example, you can create a rule by user ID that directs the FTP server to reject any upload attempt from users who are members of a particular group profile. For more information on user rules, see User Rules.

Another method of defining an access rule is by location. A Location is Exit Point Manager's definition of the origin of an access request. A location can be a specific IP, group IP, generic IP, range of IP addresses, or SNA device. (For example, a group of IP addresses may correspond to a corporate office's physical location, e.g. *DENVER.) Location security rules allow you to grant access to, and define the authorities for, all approved dial-in and Internet origins, while restricting access to unapproved origins according to the rules you define. For example, you can create a location rule to direct the IBM i FTP server to reject any FTP request coming from outside your local network. See Location Rules.

Exit Point Manager also lets you set object rules that are configured at the object level, for a specific user or location, for a specific object, and for a specific type of access. Creating an object rule allows you to, for example, specify who can access your IBM i payroll database. See Object Rules.

Authorities

Access Control Rules establish the action to be taken when a particular server or server function is accessed. You can specify the following actions:

  • *OS400 - Allow the request using the user’s normal IBM i authorities as if Exit Point Manager were not installed.
  • *REJECT - Reject the request.
  • *SWITCH - Allow the request after switching the request to run under the authority of a different user profile—the switch profile. See Switch Profiles.
  • *MEMOS400/*MEMREJECT/*MEMSWITCH - Use the rules specified in a previously memorized transaction. See Memorizing Transactions.
  • *MEMOBJ - Check Object List. (Refer to rules defined for specific objects.) See Object Rules.
NOTE: Many of the examples shown throughout this section use *FTPSERVER. The process of setting up other servers is similar, although you will see different functions. In addition, some types of rules may not apply to all servers.

Flags

Access Control Rules also include flags. The three flags are Aud (Audit), Msg (Message), and Cap (Capture).

  • Audit
    • = Record this request to the Audit Journal
    • = Do not record the request (unless request fails)
  • Message
    • = Send a message when the request is received
    • = Do not send a message
  • Capture
    • = Capture transactions for this request
    • = Do not capture transactions
NOTE: If Authority is *USER, Audit, Message, Capture, and Switch Profile are deferred. If Authority is not *USER, Audit, Message, Capture, and Switch are enforced.

Active Rule and Rule Derivation

A hierarchy of settings dictate the Audit/Message/Capture Flag status for any given rule. The hierarchy, from most general to most specific, is composed of settings from the following screens:

Rule derivation on Insite

A setting of Yes or No on a more specific level of the hierarchy always overrides a Yes or No setting on a more general level. When a Flag is set to Inherit, its setting is derived from the next-highest level in the hierarchy. You can instantly see the status of all Flags, including the setting from which the status derives, by referring to the following indicators on the Rules screen. A check indicates a Yes setting. An "x" indicates a No setting. Gray indicates the status of the flag is inherited. Green/Red indicates the flag is set on the Rule itself.

For example, suppose there is a rule for user MARKJ and the audit and capture values are both set to Inherit. If that rule is invoked, those Inherit values each resolve to either Yes or No based on the hierarchy. If all properties are set as shown in the following table, then the Active Rule for user MARKJ is Audit = Yes, Message = No, and Capture = Yes.

IF Audit Message Capture

Edit System Values (Product Defaults)

yes

yes

No

Edit Server Defaults

Inherit

No

Inherit

Edit Server Function Rule

Inherit

No

Inherit

MARKJ (rule)

Inherit

Inherit

Yes

Then, the Active Rule is

Yes

No

Yes

NOTE: For Location Rules with authority set to *USER, the transaction is evaluated by the incoming user profile. See Authorities Selection window.

Switch Profiles

The switch profile action is the key to providing flexible security for your network users. This action lets you specify an alternate user profile, called a switch profile, that network access requests run under. This allows you to use standard IBM i security commands to establish the authorities to objects on your system for a user when they access the system through the network servers.

To define a Switch Profile as part of a rule:

  1. Set the Authority to *SWITCH. When you do, the Users selection window appears.
  2. Specify the target user.

A typical requirement for *SWITCH profile:

  • User belongs to a group profile that owns objects.
  • Network access gives the user *ALL authority to the entire application.
  • Use Exit Point Manager to allow selective access.
  • Dynamically change user authority “on the fly.”
    • Give more or less authority than normal.
  • *SWITCH profile does not affect green screen operations.
    • Can configure authority independently.

For details, see Switch Profiles.

Exit Point Manager always searches for location access rules first

User access rules are considered only if a location access rule is found with an action that indicates that user access rules should be used.