Customize Your Multi-Tier Security
The following instructions will enable you to provide greater security for your database:
- List all Domain aliases (aka "
ServerTypes") used in your client-side DSNs. For example:
Oracle 8.0.x
- Use a text editor to open the oplrqb.ini file which resides in the /bin sub-directory of your
OpenLink server components installation.
- Locate [Domain Aliases] and determine how those listed above are resolved.
For example:
[Domain Aliases] Oracle 8.0.x = ora80
- Locate the resolved names of the Domain Aliases under [Mapping Rules].
For instance:
[Mapping Rules] ora80:*:*:*:*:*:* = accept generic_ora80.
- Determine whether any of these fields need added security.
Here is a breakdown:
domain_name:database:user:client_os:machine_id:app_name:operation_mode
(Note: "operation_mode" refers to read-only (ro) or read-and-write (rw) access.)
- Build rules to govern whether connection requests will be accepted or rejected by the Broker.
For instance:
ora80:*:scott:*:*:*:* = reject User "scott" is not allowed to connect to this service.
This rule rejects all connection attempts made by user scott, and tells them so. You can substitute any plain-text rejection message here, and it will be delivered to users who are blocked by this rule.
- Order each rule properly.
For example:
ora80:*:*:*:*:*:* = accept generic_ora80 ora80:*:*:*:*:msaccess:* = reject Microsoft Access is not allowed to connect to this service.
The first rule permits access to generic_ora80 in all scenarios. The second rule is never visited, since the preceding rule permits all ora80 requests.
ora80:*:*:*:*:msaccess:* = reject Microsoft Access is not allowed to connect to this service. ora80:*:*:*:*:*:* = accept generic_ora80
The first rule screens for and rejects connections requested by Microsoft Access. Connections not originating with Microsoft Access are passed on to the second rule, which permits all requests.
- Save your changes and exit the file.
- Restart your Broker.
Referenced by...