Jargon Building BlocksTM
Implementing Security

Contents Related Documents



Overview

The system's security architecture allows a wide range of possible implementations, because organizations and applications can have very different security philosophies and requirements.

This security system is designed to handle many possible security scenarios, while at the same time doing its best to achieve multiple goals:

  1. Allowing the maximum possible control over user access privileges.
  2. Minimizing security setup and maintenance requirements.
  3. Enabling the use of different security models for different applications.
  4. Providing different granularity of controls for different applications and users.
As you might guess, these goals can sometimes be in conflict with each other. Organizations can choose whatever balance on the spectrum of control vs. ease of use that they find appropriate.

Security features that can be implemented in this system include:

Security testing uses a "hierarchical default" approach, which checks for an appropriate security control record until one is found, based on the User ID and Procedure that is being run during each host interaction by a client. Each Procedure belongs to exactly one Application, while each User ID can belong to one or multiple Groups.

Security tests are done in the following sequence. At each step, if testing for any of the values (User ID, Group ID, Application ID, Procedure ID) has not been "turned on" in the System Control table, then that step is skipped. When checking by Group, a User is granted the maximum privileges of any of the Groups to which that User belongs, using a "mix and match" approach to the add/delete/update/view permissions, subject to Day and Time restrictions.

  1. Check for the most specific security control (User ID and Procedure)
  2. Check for the next most specific control (by User ID and Application ID)
  3. Check by Group ID and Procedure for each of the groups the user belongs to
  4. Check by Group ID and Application for each of the groups the user belongs to
  5. Check the Procedure's default security method
  6. Use the Application's default security method if no other controls are found


Security Strategy

Before setting up security records in the database, the security administrator should ideally plan the overall security strategy for the entire system. Issues to be decided include:

  1. Defining which Applications will be created.
  2. Deciding how Procedures will be grouped into Applications.
  3. Will all Procedures within an Application have similar security controls?
  4. Defining which user Groups will be created.
  5. Defining which Groups each User ID will be assigned to.
  6. Will all Users in a Group have similar privileges for a given Application or Procedure?
  7. Picking a basic security model for each Application:
These decisions will have a major impact on the number of security matrix records that must be set up and maintained.

Consider an example with:


Depending on the strategy chosen, the number of security matrix records that would have to be set up and maintained could range from:

So, you can see the importance of thinking through the strategy up front, to avoid needless work and to achieve a workable security system. Any model that results in thousand of security records might benefit from rethinking how Applications and Groups are defined.

Security Setup

To initially configure your security system, follow these steps:

  1. Decide on your overall strategy as outlined above.
  2. Create a list of the Applications, Groups and Security Periods to be set up.
  3. Run System Codes Setup. Add  Security Period definitions, as required.
  4. Run Group Setup and add the Groups you have decided to use. The base system already has an "Admin" group.
  5. Run User Setup and add users for each Group, including their default printer and startup menu. The base system already has an "sa" User ID for initial use during installation and setup.
  6. Run Application Setup and add the Applications you have decided to use. The base system already has "SA" and "Util" Applications for its Procedures.
  7. Run Procedure Setup and add a record for each procedure in your applications.
  8. Run Security Matrix Setup and create any desired security control records.
  9. Run System Control Setup and turn on the desired security features. Be sure you have already given yourself sufficient security permissions in the Security Matrix, so you don't get locked out!


Defining Secured Periods

Secured Periods are defined in the System Codes table to restrict the Day of Week and Time of Day that a Procedure or Application can be run. Fill in Codes records as follows:

Example 1: Example 2: Special Security by Procedure

The following procedures have special or particular security controls associated with add, delete, update and view values:

Scheduling and Output Options (x99sched):

Update Level
9 - all scheduling options allowed
7 - all scheduling options except Recurring Schedules
5 - only "online now" or "background now" scheduling allowed
3 - no scheduling allowed (only "online now")
Manage Archived Reports (xr99arch):
Delete Allowed
yes - allowed to delete report files in System Reports Directory
no - can only delete report files in Personal Reports Directory
Update Level
9 - allowed to rename report files in System Reports Directory
8 or lower - can only rename report files in Personal Reports Directory
View Level
9 - allowed to view report files in System Reports Directory
8 or lower - can only view report files in Personal Reports Directory
Job Processor Control Panel (x95jpctrl):
Add Allowed
yes - allowed to start a new Job Processor
no - cannot do so
Update Level
1 or higher - can change JobList Statuses, issue JP Commands
                      (Pause, Resume, Kill, End), and reset Job Processor system
0 - cannot do any of these actions; view only
View Level
1 or higher - can view JP log, JP jobs, current status, queue
0 - cannot do any of these views
Return to Top       Help Topics          Help Index