What does this function do?
SEQUEL Field Level Authorization uses an exclusion/inclusion dictionary function that lets administrators provide authorization to libraries, files, and fields. The dictionary, which can be defined as exclusion or inclusion, is an additional filter applied on top of system object security limits. It does not replace system object authority but supplements it.
Exclusion Dictionary – With this type of SEQUEL security, you enter a series of objects to indicate which users should be restricted from specific libraries, files, and fields in your database.
Inclusion Dictionary – You may prefer to use this type of SEQUEL security, which lists only the libraries, files, and fields the user is authorized to use.
Controlling object access with an exclusion/inclusion dictionary:
SEQUEL is preset so that standard object authority checking is performed by the system. This means that when prompting, users will be able to see the names of the libraries and files over which they have operational authority. They will also be able to retrieve information from any files over which they have read authority.
The SEQUEL security checking mechanism is enabled when *SEQUEL or *STRICT is set as a user's object authority checking value. Depending on which is applied to the user, it defines where the values set in the exclusion/inclusion dictionary are enforced. The value is changed through the display presented with the Set SEQUEL Default (SETDFT) command or through the Set Defaults option of ViewPoint Administrator.
SETDFT command:
ViewPoint SEQUEL Defaults
*STRICT provides the strongest level of authority when used with any SEQUEL-related feature or function. It allows you to easily specify exclusion/inclusion rules for individual user profiles, members in a group profile, or all users on the system through the Set Defaults option of ViewPoint Administrator or through the SEQUEL Default (SETDFT) command.
The security break-down of how the different values work:
| Restrictions for | Prompted Views | Non-prompted Views |
| *SYSTEM |
|
|
| *SEQUEL |
|
|
| *STRICT |
|
|
Each entry in the exclusion/inclusion dictionary has two parts:
USER: Identifies the group of users covered by the entry
OBJECT: Identifies the libraries, files, or fields in the database that will be excluded or included from use
The decision whether to use Exclusion or Inclusion centers on each alternative’s ease of maintenance and risk. Is it more efficient for you to exclude users from or grant them authority to a list of libraries, files, and fields based upon their profile or group profile name?
Example: 4 users limited to 3 files (one being CUSTMAST) with only 4 fields available to each.
With SEQUELEX library, the users will ONLY see the three files they have access to in the SEQUELEX library:
Within CUSTMAST file, the users will see only the four fields that were selected.
Did you know…
Additional security can be set up for both SEQUEL ViewPoint and SEQUEL Web Interface users?
Within each user's SEQUEL Defaults, you can define the user’s SEQUEL creation library, block them from changing it, and also revoke their design mode (capability)?
Within the defaults for SEQUEL Web Interface (SWI), you can define which libraries the users have access to browse for SEQUEL objects by using the SWISETDFT command setting 'Directory Listing Access'.
ON: Enable directory browsing. SWI will accept requests to build object lists for any library the user has authority to work with.
OFF: Disable directory listing. Users must know the names of the object they wish to run or access them through links provided on user-designed web pages.
SELECTIVE: (will not list, but users can access)
Directory browsing for each library is controlled by the data area WWWBRWS. If the data area does not exist in a particular library, the library is considered “restricted” and SWI will not list available objects for that library.
Note: With SELECTIVE, objects in a restricted library can still be accessed and executed using a URL in the browser, or through links provided on user-designed web pages.
STRICT: (will not list, and users cannot access)
Directory browsing for each library is controlled by the data area WWWBRWS. If the data area does not exist in a particular library, the library is considered “restricted” and SWI will not list available objects for that library. In addition, access and execution of objects is disabled in restricted libraries using a URL in a browser, as well as through links provided on user-designed web pages.