Keystone Security

From KeystoneIntranet
Jump to navigation Jump to search

Security Control in KEYSTONE

Last Rev: Build 3.6.5.4 2/7/2020 3:57 PM

ALERT: Always use 2 digit security levels. Security levels are ALPHANUMERIC, therefore the sorting will not be as expected if single digit numbers are used. The value 2 is considered higher than 19 and less than 20.

Key Security Changes for 3.2

  • Security Roles
  • Program specific security for embedded programs will apply the same as when program in called from the menu. For example Order Maintenance restrictions will apply when whether called from the menu or from the dispatch schedule.
  • Data fields on grids are restricted in a similar manner to other fields. For example you now control the Unit price field on the job detail grid with the standard visible, edit etc. settings.
  • Special field security cases are handled for controls not directly bound to database fields (i.e. scale weights.)

Access Control

KEYSTONE has the ability to control access to the following:

  • Menu Options
  • Database Fields
  • File Maintenance options (add, change, delete, copy)
  • Program-specific Functions
  • Non-data bound visual controls (3.4.4.1+)

Access may be granted based on the user’s security class or by the user’s login name.

NOTE: Currently, there is no maintenance program—-security access is granted by editing the CCTSECTL in the company database via IBConsole.

Sample Security Access Table

Here is a sample CCTSECTL table with explanations:

Rec# SECURITY_CLASS USER_ID SECTION_NAME GROUP_NAME OPTION_NAME
1 99 CCMENU OPTION ARFMCUS
1a ~AR1 CCMENU OPTION ARFMCUS
2 50 ARFMCUS EDIT COD_FLAG
3 30 ARFMCUS VISIBLE CREDIT_LIMIT
4 ~ ARFMCUS REQUIRED SALESPERSON
5 60 ARFMPRD ITEM ADD
6 ZZ QTFMQTE FUNCTION BOOKJOB
7 BOB QTFMQTE FUNCTION BOOKJOB
8 ~SLSMGR QTFMQTE FUNCTION BOOKJOB
9 30 ARFMJOB VISIBLE DTSDETAIL
10 50 ARFMJOB EDIT DTSDETAIL
11 ~DIMGR ARFMJOB VISIBLE UNIT_PRICE
12 ~AR1 ARFMJPR VISIBLE DTSDETAIL
13 ~AR2 ARFMJPR EDIT DTSDETAIL
14 60 ARFMPLT EDIT *
15 60 ARFMPRD VISIBLE $TSHHISTORY
In Rec #1, only users with a security class of 99 will see the Customer Maintenance option on the menu.
In Rec #1a, users with role ~AR1 will see the Customer Maintenance option on the menu.
In Rec #2, only users with a security class of 50 or higher will be allowed to change the Credit Status field in Customer Maintenance. Users with a lower security class will only be able to view the field.
In Rec #3, only users with a security class of 30 or higher will be allowed to see the Credit Limit field in Customer Maintenance. Users with a lower security class will not see the field.
In Rec #4, the SALESPERSON field is required in Customer Maintenance. Note the use of the tilde (~) for SECURITY_CLASS, which indicates that this rule applies to all security classes.
In Rec #5, only users with a security class of 60 or higher will be allowed to add products in Product Maintenance. Users with a lower security class will only be able to change, delete and view products.
In Rec #6, no users will be allowed to book jobs in Quote Maintenance. Use "ZZ" in conjunction with User Specific or Security Roles.
In Rec #7, user BOB will be allowed to book jobs in Quote Maintenance, regardless of his security class.
In Rec #8, users assigned to the role ~SLSMGR will be allowed to book jobs in Quote Maintenance, regardless of security class.
In Rec #9 and #10, users below security class 30 can not see the detail grid. Users from 30 to 49 can see but can not edit the detail grid. Users 50 and above have full edit access.
In Rec #11, users assigned the role ~DIMGR can see items Unit Price which is on a grid. (The use of Roles and the ability to control data fields on grids start in version 3.2)
In Rec #12, users assigned the role ~AR1 can see items on the detail grid.
In Rec #13, users assigned the role ~AR2 can edit items on the detail grid.
In Rec #14, only users with a security class of 60 or higher will be able to edit any fields in AR Plant maintenance.
In Rec #15, only users with a security class of 60 or higher will see the History tab in AR Product Maintenance.

Here is the syntax of OPTION_NAME for all possible values of GROUP_NAME:

SECTION_NAME GROUP_NAME OPTION_NAME syntax NOTES
CCMENU OPTION (*1)(*6)
<program_basename> EDIT <DB_fieldname> or <DataSet Name> (for whole grids) (*2)(*4)(*5)(*8)(*9)
<program_basename> VISIBLE <DB_fieldname> or <DataSet Name> (for whole grids) or <Control Name> (*2)(*5)(*8)(*9)(*10)
<program_basename> REQUIRED <DB_fieldname> (*2)(*5)(*7)
<program_basename> ITEM ADD/CHANGE/DELETE/COPY/ACDC (*3)(*11)
QTFMQTE FUNCTION BOOKJOB


where <program_basename> is the filename of the program without the extension (*)Notes:

  1. OPTION is only supported for the KEYSTONE menu (CCMENU.)
  2. There is currently no way to specify a tablename in the case where the same field exists in two different tables.
  3. ITEM is only supported for file maintenance programs.
  4. An asterisk (*) may be used in place of DB_fieldname to indicate all fields.
  5. The form name followed by a period (.) may be prepended to DB_fieldname to indicate a specific field on a specific form within the program.
  6. As of Keystone 3.1.99.10, there are four pre-defined OPTION_NAME values to control access to the Query Export/DataScope Custom Reports/Exports menus:
    1. CUSTOM_REPORTS
    2. CUSTOM_EXPORTS
    3. DATASCOPE_REPORTS
    4. DATASCOPE_EXPORTS
  7. Supported as of Keystone 3.1.99.25.
  8. As of Keystone 3.1.99.45 these options will affect grid columns as well.
  9. As of Keystone 3.1.99.53 there are some special cases that are handled (see below.)
  10. As of Keystone 3.4.4.1 you can specify $ followed by the name of a non-data bound visual control.
  11. As of Keystone 3.5.99.30 you can specify ACDC which combines ADD, CHANGE, DELETE & COPY.

Field Security Special Cases

As of Keystone 3.1.99.53 there are some special cases regarding field security.

Sometimes it is desirable to restrict a field that is not directly bound to a database field. An example would be scale weights (gross, tare, net.) A customer might want the scale operator to be able to edit the tare weight, but not the gross weight for example. To accomplish this, setup the security options as follows:

Rec# SECURITY_CLASS USER_ID SECTION_NAME GROUP_NAME OPTION_NAME
1 ZZ TISCTRW EDIT GROSS_WEIGHT
2 ZZ TIFMTPR EDIT GROSS_WEIGHT
3 ZZ DIFMTPR EDIT GROSS_WEIGHT

GROUP_NAME Definitions

  • OPTION: Controls visibility of menu options
    • SECTION_NAME: must be CCMENU
    • OPTION_NAME: is the filename of the menu option without the extension
  • EDIT Controls ability to edit a specific database field in a specific program
    • SECTION_NAME: is the filename of the program without the extension
    • OPTION_NAME: is the database field name -or- datasource name for a grid
  • VISIBLE: Controls visibility of a specific database field in a specific program
    • SECTION_NAME: is the filename of the program without the extension
    • OPTION_NAME: is the database field name -or- datasource name for a grid -or- control name
  • ITEM: Controls file maintenance functions within a specific file maintenance program
    • SECTION_NAME: is the filename of the program without the extension
    • OPTION_NAME can be one of ADD, CHANGE, DELETE, COPY
  • FUNCTION: Controls program-specific functions
    • SECTION_NAME is the filename of the program without the extension
    • OPTION_NAME is the program-specific function

Standard security functions

KEYSTONE has the ability to control certain functions through the security control table. These functions are listed below.

SECTION_NAME GROUP_NAME OPTION_NAME Controls Access To Keystone Version
APBMINV FUNCTION POSTDUPINV Ability to post duplicate invoice number 4.0
APSCINV FUNCTION SHOWACCTBAL Show cash account balance 2.5.4
ARFLCUS FUNCTION SHOWHISTORY Customer history information 1.6.34
ARFMCUS FUNCTION SHOWHISTORY Customer history information 1.6.34
ARFMPRD FUNCTION EDITMIXDESIGN Ability to edit mix designs 2.9.7
ARFMPRD FUNCTION SHOWCOST All cost and profit information 2.9.7
ARSCAPP FUNCTION EDITORDER Edit Order function 2.9.9
CCMENU FUNCTION LOGIN Ability to login to this company 3.1.99.52
CCMENU FUNCTION SUPERUSER All menu functions & Reassign serial # 2.4.1
CCUTPVT FUNCTION UPDATEQUERY INSERT, UPDATE and DELETE Queries 3.6.5.4
CCUTQXP FUNCTION UPDATEQUERY INSERT, UPDATE and DELETE Queries 2.4.1
DIFMORD FUNCTION EDITPRODDESC Ability to edit detail descriptions 2.9.9
DIFMTPR FUNCTION EDITPRODDESC Ability to edit detail descriptions 2.9.9
DISCSCH FUNCTION DISPATCH Dispatch Operations 2.7.31
QTFMQTE FUNCTION BOOKJOB Ability to book quotes as jobs
QTFMQTE FUNCTION SHOWCOST Use Cost Estimator & Show Unit Cost/Profit on costing grid 2.8
TIFMORD FUNCTION EDITPRODDESC Ability to edit detail descriptions 2.9.9
TIFMTPR FUNCTION EDITPRODDESC Ability to edit detail descriptions 2.9.9

Security Roles

Starting with Version 3.2 (3.1.99.51) Keystone support security Roles. A role is a set of security features that can be assigned to many users. For example you could make roles for a dispatcher without pricing ability and a role for dispatch admin with pricing.

Once a roles are created the customer’s on-site admin can assign roles to users AND a user can have many roles.

Roles must first be created in IBCONSOLE in the CCWSYS db CCTROLE table:

While it’s not enforced – using the ~ character IDs this as a ROLE ID. Follow this convention to prevent confusion.

Once Roles are created they can be assigned in user setup. Note that this allows company level control in one place.

Roles still rely on the CCTSECTL. They take advantage of the “USER_ID” field previously used to give one user a security feature. One important tradeoff to using the existing security model is that you will need to put a high security level (ZZ) on each feature in addition to assigning the role. NOTE: CCTSECTL must be setup in each company. We can review tips for replication and synchronization during our visit (or on request).

Sample of existing security with Book Job for 4 users and security for sales quoting and dispatch:

Using ROLES the setup would look more like this:

As you can see it will actually take more lines of CCTSECTL to put an item into a Role – one to create a level "ZZ" entry to prohibit all users and one to give access to the function to each role. In the case where the user ID feature is used all user lines can be set to a single Role (~QBJ – book job).

In most cases this extra it of setup up front will pay back quickly for several reasons:

  • The customer can pick roles for each user
  • Easier to understand for us
  • Way easier to understand for customer
  • Easier to isolate function (why should an AP clerk get dispatch like you get with current “level” logic.

Alternate System Password

KEYSTONE provides the ability to setup an alternate password for the SYSDBA and CCWIN database users.* To do this, follow these steps:

  1. Using IBConsole, change the InterBase server password for the SYSDBA and CCWIN users. (You MUST use the same password for both users.)
  2. Copy the AKEYGEN.EXE program to the customer’s computer that will be running the KEYSTONE Application Server.
  3. Run the AKEYGEN.EXE program.
  4. Enter the password that was setup using IBConsole in step 1. (Case is important and must match!)
  5. Click the “Generate Key” button.
  6. Edit the CCWIBSV.INI file located in the CUST\SETTINGS folder under the KEYSTONE root directory. (If one does not exist, copy the CCWIBSV.INI from the SETTINGS folder into CUST\SETTINGS.)
  7. At the end of the [IBServer] section, add this line: AccessKey=<Access Key value from AKEYGEN program>
  8. Save the CCWIBSV.INI file.
  9. Run KEYSTONE to verify that the system starts normally.
  • NOTE:

You can (and should) change the password for the other KEYSTONE users (CCWSYS, CCWUSER and CCWVIEW) as you see fit, but it is recommended that you choose a DIFFERENT password than the one you use for SYSDBA and CCWIN.


Archive Document (2010): :PDF:Security Control in KEYSTONE

Retrieved from "http://in.compucrete.com/index.php?title=Keystone_Security&oldid=398"