Understanding Row Security in E1Kristina O’Leary

Brian Connor

JD Edwards Versions 8 through to 9.1

Product Awareness Sessions

ALL Out Webinar Programwww.alloutsecurity.com

Product Awareness Sessions (English, Spanish and French)ALL Out for EnterpriseOneALL Out for WorldALL Out for IBMi

Education SessionsReporting, Segregation of Duties and ComplianceMultiple Roles“Open to Closed without Pain” (E1 only)ALL Out Product AwarenessTask View Best Practice

Technical Webinars – E1 Cost justifying an upgradeChoosing the right platform

ALL Out for E1 – Xe to Version 9Agenda

Introduction

Security BasicsProgram SecurityData Security

Exclusive vs. Inclusive Row Security

Row SecuritySetting Up Row SecurityExample: The ChallengeExample: The WorkaroundExample: The SolutionRole SequencerUser reporting – what can a user do?Row Security Reporting – who can access a Business Unit?

DemonstrationRow Security and Functional RolesRoles within RolesIdentifying Role Sequencer Conflicts

NEW

Program Security

Application and Action Security

Program Security – To Control Access to Programs

Application SecurityDefines if an application can be accessed or run

Action Code SecurityDefines the actions that can be takenAdd, Change, Delete, OK/Select, Copy, Scroll

For inquiry only: The security below allows inquiry access but will not allow the user to add a new business unit, or change or delete an existing business unit.

Security Best Practice

• You need Application and Action Code security• Operate in a ‘Closed’ or ‘Deny All’ security environment• Avoid using ‘N’ Settings, except at *PUBLIC

• Security is easier to understand when the only ‘N’ records in the F00950 table are at *PUBLIC and *ALL level. You should not need many additional ‘N’ settings at the user or role level.

• Use security sparingly at version level and form level• Use it, it works well, but only use this only where specifically required.

• Avoid user level security, put all security in roles• Exception: Resolve role sequencer conflicts at user level• Use small, processed based security so that your work is reusable and clean

• Avoid putting ‘data’ security and ‘program’ security in the same roles• You will need little Solution Explorer Security

• When you have a ‘closed’ system, you do not need Hyper Exit Security! This type of security creates maintenance issues in exponential proportion to the number of records you create.

Data Security

Row Security – control recordsColumn Security – control fields

What is Row Security?What is Column Security?

Row Security – Secures users from accessing a particular range or list of records in any table.

For example, if you want to allow a role to enter journal entries only for Company 1, you can create role based row security for the journal entry table (F0911) and the field ‘CO’ for Company

For example, if you want a user to run financial statements only for a specific business unit, you can create role based row security for the account balances table (F0902) and the field ‘MCU’ for business unit.

Role Table Data Item From Value Thru Value ADD CHG DEL VIEW

RS-CENTRAL F0911 CO 1 1 Y Y Y Y

Role Table Data Item From Value Thru Value ADD CHG DEL VIEW

RS-WEST F0902 MCU 3 3 Y Y N Y

What is Row Security?What is Column Security?

Column Security – Secures users from viewing a particular field or changing a value for a particular field.

For example, You can secure the Social Security Number field on the Employee Master, or you can secure (hide) the Salary field on the Employee Master application (it is optional to specify a specific version).

Role App/Form Table Data Item Version Add Change ViewRS-EEMAST F060116 SSN Y Y YRS-EEMAST P0801   SAL ZJDE0001 Y Y Y

Inclusive vs. Exclusive Row Security

You use row security to either restrict or allow users from viewing, updating, deleting, or adding certain records (rows) to a table. Prior to setting up any kind of row security (whether at the user level, role level, or *PUBLIC level), security administration determines whether your system will use inclusive or exclusive row security. Exclusive row security blocks users from accessing the database for a secured range of values that you define.

When you create exclusive row security, you are creating a row security record to exclude or block a user/role from adding, changing, deleting or viewing certain records

Inclusive row security allows users to access the database for a valid range of values that you define.

When you create inclusive row security, you are creating a row security to allow or a user/role to add, change, delete or view certain records.

Inclusive row security is best practice as it provides better system performance and is much easier to use and maintain than exclusive row security.

.

Exclusive vs Inclusive Setting is an exit from P00950

Set once and typically do not change.

Data Security: Open or Closed?

Data Security is by default *Open*If no row security records exist at *PUBLIC, role level or user level, then a user can access all recordsOnce a row security record is in place for *PUBLIC, at the role level or user level, for a specific table, and a specific Data Item then the user can only see records for the Table/Data Item that they have been given access toFor example: Role RS-WEST

A user assigned Role RS-WESTWill be able to add, delete and view records in F0006 for ONLY business unit 5Will be able to add, delete and view records in F0911 for ONLY business units 1 and 5Will have FULL ACCESS to all other tables (by DEFAULT)

Mixing letters and numbers

When defining Ranges, be careful when mixing letters and numbersRange 1 to 9 – is just that – 9 valuesRange 10 to 19 is just that – 10 values

Range 9 to 10 has all the letters and numbers as wellASCII Sort sequence starts withBlank ! “ # and then all sorts of characters – and then 0 1 2 3 4 5 6 7 8 9 : ; < and then all sorts of characters – and then A B C D E etc until Y Z { | } ~ at the end

Don’t forget – if your server is EBCDIC (iSeries) the sequence is different.

When in doubt, use an E1 visual assist to see the sort sequence (i.e. use visual assist in business unit field to see proper sort sequence)

Setting Up Row Security

Example of How Row Security Works

Define Row Security Roles

Note Role Sequence Number

Assign Environment to New Roles

Define Row Security for Roles

Row Security: The ChallengeMultiple Row Security Roles:

The Role Sequencer

Note – Must force *ALL RolesIf a user can select a role they will by-pass

row security (unless it is at the user level)

Assign Roles to Users

Annette

Assign Roles to Users

Debbie

Testing Results

Annette

Business Unit Inquiry

Annette can only view business unit 9.

Role RS-CORP has the highest role sequence number.

Testing Results

Business Unit Inquiry

Debbie can only view business unit 6.

Role RS-NORTH has the highest role sequence number.

Debbie

ALL Out Security Conflicts Report:Application, Action and Row Security

Report Only – No Database Updates

Run for User: Rod

Review Rod’s Role Assingments

Review Row Security Conflicts

Row Security: The ALL Out Quick Fix

An Automated Process:Multiple Row Security Roles

Row Security Built at User Level

This automates a common practice at many E1 sites

Run Role Conflict Managementin Fix Mode

Submit ReportUser: Rod

Fix Conflicts

User Level Security Records Createdto Fix Row Security Conflicts

Review Records in F00950

Row Security: The JDE Workaround

Create New RolesManually Create New Row Security Records

Testing Results

Business Unit Inquiry

Debbie can only view business unit 6.

Role RS-NORTH has the highest role sequence number.

Debbie

Create a New Role: RS-NOSO Row Security North & South

Manually Create F00950 Records fornew role RS-NOSO

Assign new role RS-NOSO to DEBBIE

Testing Results

Business Unit Inquiry

With new role RS-NOSO, Debbie can view business units 4 and 6.

However, new security records need to be created for every new row security role combination!

Debbie

Row Security: The ALL Out Solution

An Automated Process:Multiple Row Security RolesSuper Roles and Sub Roles

Create Super Role

COMBI03

Run Fix/Merge Process to Build Super Roleand Create F00950 and F9006 Records

All Out Fix/Merge Program AutomaticallyCreates F00950 (Security) and F9006 (Fine Cut) Records

A Super Role looks and acts like any other role:P95921 Role Relationships

Assign Super Roles to Users

John

Testing Results

Business Unit Inquiry

John can see business unit 9, 20-30, and 61.

COMBI03 has role sequence number 490, and COMBI03 has access to 3 sets of business units.

John

Row SecurityReporting

Reporting Back to Front:We know what each user has access to,

but who has access to which tables?

NEW

Question: Who has access to table F0006?

Answer: These users have access to F0006?

Question: Who has access to MCU 23?

Answer: These users have access to business unit 23.

Demonstration

ALL Out Contacts

Sales Support

Hazel @ alloutsecurity.com

Consulting

Brian ConnorBrian.Connor@alloutsecurity.com

Kristina O’LearyKristina.Oleary@alloutsecurity.com

Exclusive to InclusiveConversion

Product Based Service from ALL Out

Exclusive

If exclusive row security is set

• Only the records in blue (View= ‘N’) would be used by JD Edwards• The records in red (View= ‘Y’) would simply be ignored – unless the ‘Add’, ‘Change’ or ’Delete’ flags are used.

User Table Data Item From Value Thru Value Add Chg Dlt View

JOHNDOE F0101 CostCenter 1 20 Y Y Y Y

JOHNDOE F0101 CostCenter 21 50 N N N N

JOHNDOE F0101 CostCenter 51 70 Y Y N Y

JOHNDOE F0101 CostCenter 71 ZZZZZZ N N N N

Selects performed against the F0101 table would look like: 

SELECT * FROM TESTDTA.F0101 WHERE (ABMCU NOT BETWEEN '21' AND '50' AND ABMCU NOT BETWEEN '71' AND 'ZZZZZZ')

Updates on the F0101 (in this example changing JOHNDOE’s cost center) would look like:

UPDATE TESTDTA.F0101 SET ABMCU = '60' WHERE (ABAN8 = 12345) AND ( ABMCU NOT BETWEEN '21' AND '50' AND ABMCU NOT BETWEEN '51' AND '70' AND ABMCU NOT BETWEEN '71' AND 'ZZZZZZ')

InclusiveIf inclusive row security is set• Only the records in blue (View = ‘Y’) would be used by JD Edwards• The records in red (View= ‘N’) would simply be ignored.

User Table Data Item From Value Thru Value Add Chg Dlt View

JOHNDOE F0101 CostCenter 1 20 Y Y Y Y

JOHNDOE F0101 CostCenter 21 50 N N N N

JOHNDOE F0101 CostCenter 51 70 N N N Y

JOHNDOE F0101 CostCenter 71 ZZZZZZ N N N N

Selects performed against the F0101 table would look like:

SELECT * FROM TESTDTA.F0101 WHERE (ABMCU BETWEEN '1' AND '20' OR ABMCU BETWEEN '51' AND '70')

Updates on the F0101 (in this example changing JOHNDOE’s cost center) would look like:

UPDATE TESTDTA.F0101 SET ABMCU = '60' WHERE (ABAN8 = 12345) AND (ABMCU BETWEEN '1' AND '20' ) 

Convert Exclusive to Inclusive

ALL Out Conversion Report