Welcome to JRI's Help page for the DSC In-House Security

Due to the very-changing access that our users demand from us, the existing DMSECURITY that comes with SB was found to be too restrictive and time consuing to maintain. Thus, we have an in-house security that launches before the native System Builder security logic. This is controled by a new file called DSC.RESTRICTED.PROCESSES.

The DSC.RESTRICTED.PROCESSES file contains all IIPROCESSes that are restricted from 1 or more people. It was initially populated from the security profiles in DMSECURITY along with Bruce's DSCTBL AVANTE.PROCESSES, plus an Excel.

Let's get started...

There are only 2 new files and 1 control record involved with the security. One that does all the in-house restritions and a 2nd that audits user security.

  • DSC.RESTRICTED.PROCESSES
    • Field Description
      Key Same as IIPROCESS
      F1 Multi-valued list of users that may run the process
      F2 Multi-valued list of users that may not run the process (future use)
      F3 Superuser who owns the processes
      F4 Subroutine to call for additional security for the process (future use)
  • DSC.RESTRICTED.PROCESSES.AUDITS
    • Field Description
      Key User*Date*Time
      F1 Multi-valued list of processes the user had before the change
      F2 User ID of the person who made the change
      F3 Program used to make the change
  • DSCTBL DSC.SB.PROCESS (contol record)
    • Field Description
      F1 Multi-valued description of each field
      F2 Is the new security on or not (1 = on)
      F3 a mv list of accounts that use the "LIVE" security list of users
      F4 A mv list of users with unlimited access in non-LIVE accounts
      F5 Can we run the migration program - should be zero since we are 100% up and running
      F6 A mv list of user IDs to ignore when exporting user access for annual audits
      F7 A string to add to EMAIL.BODY that instructs SYSS9002.1 to not re-direct Emails in non-LIVE accounts.
      At this time, the only 2 programs that user this are DSC.SB.PROCESS and APGRANTACCESS.

In a normal SB environment, all processes in System Builder go through SB.PROCESS. In order to intercept the call prior to actually running SB.PROCESS, the VOC for SB.PROCESS had to be changed to point to a new program, DSC.SB.PROCESSES.
VOC SB.PROCESS

The program DSC.SB.PROCESSES handles all the in-house logic that we want. If the user is granted access, it calls a VOC called ORIG.SB.PROCESS, passing the original arguments to it.

This new cataloged VOC-pointer, ORIG.SB.PROCESS actually points to the original SB program, SB.PROCESS and thus launches the native SB security.
VOC ORIG.SB.PROCESS

If the user passes the in-house security (DSC.SB.PROCESS), we then call ORIG.SB.PROCESS (along with the original arguments) and let the normal SB security to its thing.

Note that in both cases, the VOC is not pointing to what we would expect. This is usually a very bad idea due to the confusion this can cause. However, in this case, it is the only way to do this since we do not have access to the SB source code.

Below is a flow chart of how the logic works:
Flow Chart

DSC.RESTRICTED.PROCESSES is populated with SYSS9123.4 and using several different pieces of information.

  • The DMSECURITY file before any users have had their profile changed to SUPER-GRP-xxx
  • DSCTBL AVANTE.PROCESSES (identifies a restricted process & who owns it)
  • O:\Restricted_Processes.txt (maintained in O:\Restricted_Processes.xlsx)
Restricted_Processes.txt is a tab-delimited file that contains all several types of data.
  • 3-letter prefixes that should block an entire suite of processes
  • Processes that should have their DSC.RESTRICTED.PROCESSES record deleted (built by the 1st part, but should not have an ID)
  • The owner of processes not already identified by DSCTBL AVANTE.PROCESSES
  • Processes that should be blocked at the SUPER-GRP level (must be done manually)
  • DSC.RESTRICTED.PROCESSES that should be manually deleted

Once the new software is in place, and the DSC.RESTRICTED.PROCESSES has been built and the VOCs have been switched, nobody is likely to see much of a change (yet).

On an individual basis, the users need to be migrated from their current security profile to either:

  • SUPER-GRP-ACCT or
  • SUPER-GRP-OTHER
The only difference between these two new profiles is that SUPER-GRP-ACCT should have access to the month-end and year-end accounts. The account access is controled by native System Builder via DMSECURITY.

There are actually very few processes/programs involved with all of this.

  • SYS9123 - Maintain DSC.RESTRICTED.PROCESSES
    • This process is used to add/remove user access to a single process as well as to assign the owning super-user. This is a onesy-twosy sort of change.
      SYS9123
      Super-users who own the process may also make these changes, but only for the processes that they own.
      "Extra" is for future use and is a place to plug in a subroutine to do additional checks beyond what DSC.SB.PROCESS does. It is not currently used.
      Note that the "Cost" field is a reference field only. It does not restrict anything.
  • SYS9124 - Build a New User, Grant Additional Access to an Existing User or Delete an Existing User
    • This process is used to copy access or remove access en mass for a single user. Most often used for adding a new user or removing a terminated user.
      SYS9124
      There are several ways to use this process:
      • 1) Build a New User
        • SYS9124_2
          Enter the "Replicate-From" user ID in the first box and the new user's ID in the 2nd box.
          Hit the F2 to begin the load process.
          You will see the following prompt:
          SYS9124_2_2
          For a new user, the add and replace would work the same (but would be different for an existing user).
      • 2) Grant Additional Access to an Existing User
        • SYS9124_3
          Enter the user ID who already has the access in the 1st box.
          Enter the user ID who needs the access in the 2nd box.
          Hit the F2 to begin the load process.
          You will see the following prompt:
          SYS9124_3_2
          This is the same prompt as shown above, but in this case, there is a big difference between Add and Replace.
          If we add the security, we will append all of the 1st user's access to whatever access the 2nd user already has. Thus, the 1st user will have more access than the 2nd user.
          If we replace the security, we will:
          1) Remove whatever access the 2nd user currently has and then
          2) Add the 1st user's access to the 2nd user (thus making them the same).
          An audit will be built of the 2nd user's access prior to the change.
      • 3) Grant Additional Access to User based on an Audit from a Prior Change
        • This flavor is used to grant access to a user based on an audit from a prior change. This can be used to grant access to a user that is no longer with the company, to restore a user to a prior setting, etc. SYS9124_4
          Enter the user ID who should get the access in the 1st box.
          Put nothing in the 2nd box (you can not load from an audit if both boxes are populated).
          Hit the F2 to begin the load process.
          You will see the following prompt:
          SYS9124_3_3
          Use the standard F3 lookup to find the audit you wish to use to grant access to the user. After choosing an audit, hit the F2 to load the changes. You will see a prompt like this:
          SYS9124_3_4
          Just as above, we can add or replace the security access.
          If we add the security, we will append all of the access in the audit to the user. Thus, the user will have more access than the user (whoever they were) at the time of the audit.
          If we replace the security, we will:
          1) Remove whatever access the user currently has and then
          2) Add the access from the audit to the user.
          An audit will be built of the user's access prior to the change.
      • 4) Delete an Existing User's Access
        • SYS9124_4
          Enter the user ID you wish to remove in the 1st box.
          Put nothing in the 2nd box (you can not delete a user if both boxes are populated).
          Hit the F4 to remove all access.
          You will see the following prompt:
          SYS9124_4_2
          If you press the Continue button, the user's ID will be removed from all DSC.RESTRICTED.PROCESSES.
          Note that this will not remove the USRSECMST or DMSECURITY, so they technically still have minimal (display) access.

          An audit will be built of the user's access prior to the change.
  • SYS9125 - New User Request to Super-Users
    • This process is used to get super-user approval for a new user. It replaces SYS9038.
      SYS9125
      Enter the HelpStar parent ticket number or hit F3 for a lookup. So long as it is a valid, open ticket, it will populate the rest of the fields based on the data from the HelpStar ticket. You may replace the values that are pre-loaded as you see fit. Hit the F2 key to generate an E-mail with an Excel file of all the access that the "replicate-from" user has. Just as with the older SYS9038, review this as needed and forward on to the identified super-users.

There will be times when a super-user is unavailable (vacation, sick, etc.) When that happens, there is logic built into the security to test if the super-user in question has a proxy. This proxy logic is used when:

  • A user requests access to a restricted process
  • A "new user" request is run

All of this is controlled by DSCTBL AVANTE.PROCESSES.SUPERUSERS. it is maintained with the editor (i.e. there is not process). This record has the following format (for illistration purposes, only 8 superusers are displayed):

Field Desc Example of Data
F1 Self-documenting description of the control F1 = Description of this control^F2 = List of superusers^etc...
F2 mv associated list of superuser IDs1 ENGLICE^DREWRWB^HODGEDA^HURLEBA^MAJORLJ^MILLEPL^FRAZZBP^POASTSD
F3 mv associated list of proxies (usually null)2 ^^ROEHRTW^^^^^
F4 mv associated list of export type to send to the superusers for annual audits3 ^^^^1^1^1^1
F5 mv associated list of type of email approval4 1^1^1^1^1^1^1^1

1 This is a list of all superusers.
2 In the above example, HODGEDA's proxy is ROEHRTW - there are no other proxies.
3 Defines the type of Excel export to provide the superuser for audit purposes:
null builds 1 worksheet/process (looked cool when I 1st wrote it, but has been found to be cumbersome)
"1" builds a workbook with 2 worksheets (preferred):
1 w/ all processes that others can access
1 w/ all processes that only the owner may run
4 Type of email approval request:
null is w/o a hyperlink (old)
1 is w/ a hyperlink (preferred)