When Company or Business Unit Row Security Isn’t Enough

I worked with a client recently that had removed their Company and Business Unit Row Security because they were having issues with one-sided journal entries.  The company is based in the US and had just acquired a company in China.  Now they wanted to secure their data so that employees in the China company would not be able to see US data.

Mary Kay Christophersen

Sr. Consultant – JD Edwards Integration, Compliance & Security

ALLOut Security

What is Row Security

Row Security is used to secure records in the database tables.  It can be used to hide records, prevent adding new records, and prevent the update or delete of existing records.  Row Security causes SQL statements to be modified by adding a WHERE clause.  So, for example, Select * from F4210 becomes Select * from F4210 where AAMCU = ‘xxxxx’.  This WHERE clause restricts the data that is returned from the database and the changes that are committed to the database.

To create these WHERE clauses you need to tell the system what data item to use in the statement.  So, the alias for the data item is included in each Row Security record.  There is a field in the data dictionary that is checked at runtime to enable the use of the data item for row security.  While JDE has pre-defined data items for row security there is sometimes a need to enable the field by checking the flag in the data dictionary and redeploying the data dictionary after this change.

Every Row Security (Type 4) record needs three pieces of information:

1. The table to secure, table the *ALL reference may be used to secure all tables containing the specified Data Item.
2. The data item, this uses the ALIAS as defined in the data dictionary.
3. The data range, this is the ‘from and to’ range of values that the data item can contain.

Additional considerations about data items:

• Blank values can cause confusion because blank is not the same to the machine as null and blanks may or may not be a valid entry for a given field.
• Companies have numeric values from 00000 thru 99999. Blank is also a valid company value.  And the company 00000 has special use in financials.  There are various data items that contain the company such as the aliases CO, HMCO, KCO (these data item names are Company, CompanyHome, CompanyKey).
• Cost Centers are 12-character alphanumeric and are right justified. This means that a range of “1 to 99” would include cost center AA because A is greater than blank and less than 9.  An A is also less than 1 but you need to read this the range 1 to 99 as “b1 to 99” where b is blank.  So be careful when mixing numbers and letters.  There are various data items that contain the Cost Center such as the aliases MCU, HMCU, MMCU (CostCenter, CostCenterHome, CostCenterAlt).

Inclusive vs. Exclusive Row Security

Exclusive Row Security

• Secures from accessing data outside the defined range – in other words, you set up ranges with view = N and what is not included cannot be seen.
• ACD values need to be applied with view=Y records (unless you want the default of YYY for add, change, delete to apply).
• However, the view = Y records don’t get used to determine viewing itself (this is done by SQL using the view = N records only).

Inclusive Row Security

• Allows the accessing of data within the defined range – in other words, you set up ranges with view = Y and what is included can be seen.
• With inclusive, by definition, ACD settings only apply to defined ranges (you cannot allow something to be updated without allowing it to be seen too)

We recommend ‘Inclusive’ security, which is not the default.  Performance is normally helped a bit because there are fewer SQL clauses generated.  And it is easier to use when viewing and maintaining records because it is easier to see what is available to the role.  Security in multiple roles can be merged more easily (whether by a program or manually) because where you want to merge 2 sets of access, merging 2 sets of what you are restricted from can result in no access to anything.

This table is a side-by-side look at Inclusive and Exclusive Security using data item CO:

A system flag in the F00950 table determines whether the row security is ‘inclusive’ or ‘exclusive.  To view the flag form exits are available from the program P00950.

Note:  Do not change this setting if you have existing Type 4 security records in the F00950 security table!  While we do recommend using Inclusive Row Security, a project to convert existing records is required to make this change if there are existing Type 4 security records in this table.

When to Use Row Security

Our advice is to approach row security from a business perspective and not from a technical perspective.  Row security may have a minor detrimental impact on performance.  And it does require maintenance.  So it doesn’t make sense to be securing things without a sound business reason – less is more!

There are two broad categories of row security:

1. Security designed to restrict Users to companies or cost centers. This is the most common type of application of row security and is part of recommended security strategies.
2. Security designed to prevent access to functions within the system, for example, security that restricts Users to certain address book types. However, it is often possible to effect security to different functional aspects of the system through Application and/or Action security rather than Row security – and where possible, we generally advise avoiding the use of Row security where Application and/or Action security can be used instead.

Data Privacy Security can be implemented (beginning with 9.1) on the Address Book to restrict the ability of users to view others’ sensitive data while maintaining the ability to view their own.  This security is NOT configured using JDE security but is instead defined through the P01138 application.

Roles for Row Security

We recommend roles for Row Security are separate and unique from the roles used for Application and Action Code Security.  The reason for this is to minimize duplication of Application security roles.  The applications for Voucher Entry, for example, would be the same regardless of which company is being accessed.  So two different accounts payable employees could get the same Application role for voucher entry but be given different Row Security roles to perform that voucher entry for different companies.  Using a unique naming convention for the Row Security roles also helps make it easy to distinguish them in inquiries and reports.  For example, I like to prefix Row Security roles with the letters RS (RSWEST, RSCHICAGO) so that they sort and display together.

A Row Security Restructuring Project

The first task for this project was to determine the Row Security already in place.  Fortunately, this client had already deleted the 25,000 rows of Type 4 Row Security that was previously implemented.  They had done this as part of a project to move to a closed application security model.  The benefit here was that we could change the Inclusive/Exclusive Row Security Flag to Inclusive.  All the following examples use Inclusive Row Security.

For this situation, much of the separation for the US and China companies was accomplished with Row Security on the data item CO.  Because the intent was to keep China users from seeing US data but to allow US users to have access to all companies this required simply the *ALL record for CO:

Data Item KCO (Document Company) and KCOO (Order Company) were also needed in Sales and Purchasing for tables F4201, F4211, F4301, and F4311.

Price adjustment and purchase pricing tables do not have the CO alias.  These were secured using data item CRCD (Currency Code).  There was also a custom pricing table that stored a value to a specific Cost Method in the F4105 table.  The data item is LEDG (CostMethod) and this data item is not enabled for row security in the data dictionary.  The data dictionary flag had to be checked and the data dictionary deployed.  The other costs in the F4105 were secured using MCU so that China users could only see costs for China business units.

Resolution

The biggest issue to overcome was the one-sided journal entries that had occurred in the earlier implementation of Row Security. One missing element was the inclusion of CO 00000 which is hardcoded to some transactions.  So, for the RSChina role, we added a security record to grant access to CO 00000 for these users even though they only ever see CO 00088 on their transaction screens.

Another issue to be aware of is securing Companies and/or Business Units when using Inter-Company or Inter-Branch transfer orders.  Users creating these Order Types need to have access to all companies and business units that will be used on the system generated orders created.  They also need access to all the currency codes used on the orders.  For this client that meant that we had to have a user with US access to both the US and China perform this task.  Whether that user is a trusted employee in the China location or one in the US that receives requests from China to enter these types of orders is a business decision.

Row Security in the final analysis is simply an additional security type that can be used to reduce business risk.  Understanding the business processes and the risks requires input from the business.  Understanding the users, roles, security types, and the set-up of security usually rests with a special security analyst or technical resource.  As this case illustrates, it takes a team effort to understand and implement security in a way that meets the needs of both.