Securing access to data is a crucial part of any JD Edwards security strategy. In this article, I’ll discuss the benefits of having a Role-based data access strategy and outline some guidelines to follow to implement it successfully.
What is Role-based Data Access Control and how can it help?
Many organizations need to define data access restrictions, for example where staff should only be able to access data that relates to a particular business unit or geographical location.
Some organizations do this by defining separate Roles for staff with similar Roles in different locations. For example, they may have Roles for ‘APClerk-US’ and ‘APClerk-Canada,’ where application access is the same, but different data access restrictions are included in the each Role.
If many Roles need data access restrictions, it is more efficient to use Data Roles – ie to create an E1 Role for each distinct data restriction. For example, if data access needs to be restricted by country, you might create Data Roles called ‘US Data’ and ‘Canada Data’ which define the permitted access. You can then assign the appropriate Data Role to individual users, along with their Job Roles.
In the example above, you only need a single Job Role for all AP Clerks, plus Data Roles for US and Canada. If application access for the Job Role needs to change, you only need to apply the changes to one Role.
So Data Roles can significantly reduce the amount of time that your security admin staff need to spend maintaining Roles and responding to routine security changes.
They will also improve performance and help you to sustain the integrity of your security model.
Guidelines for implementing Role-based Data Security in JD Edwards EnterpriseOne
The E1 security types most commonly used for data security are:
- Row Security (type 4) – controls access to ranges of data based on the data item (e.g. business unit); can be for all tables or specific tables
- Column Security (type 2) – field level security targeting a specific data item (e.g. credit limit)
- Data Browser (type B) – restricts database table browsing.
While these security types are important in defining access, how you assign that access is equally important. Here are some general guidelines to follow when establishing your Data Security Roles.
Categorize and Define Data Access Requirements
You’ll need to involve your business and functional leads in this exercise, and we recommend holding workshops with them to:
- broadly categorize your data into groups such as company/business unit, process (Financial, Distribution) etc.
- understand which applications have access to the data you want to restrict
- define what type of restrictions/access you need to assign (i.e Full access or view only).
This is easier for categories such as Company/Business Unit, because these types of data restrictions apply to most tables/applications. But for other areas, such as Manufacturing, you may have data restrictions that require your Item Master to be secured by certain item characteristics. These attributes may not yet be established in your application set up, so it’s essential to work with your business and functional leads to understand the requirement and agree the best way to achieve it.
Create Data Roles
These roles will only contain security records that define specific data access. For example, if you determine that one of your categories for data access is geographic (US, Europe, Canada, etc.) you may have a Data Role called ‘US Employees’ which defines data access/restrictions specific to US business units only. Keep in mind that restrictions that apply to all users can be applied at the *PUBLIC level, with access granted back by the Data Role as needed.
Avoid assigning data access at the user level (or any other security for that matter!)
User level security greatly increases the overall number of security records and degrades performance. It makes security management much more complicated and time-consuming, as changes that affect multiple users have to be applied to all those affected, and it also makes it very difficult to establish exactly who has access to what.
Use Data Roles to apply all data security
Avoid including any data security in Job Roles as that will also create duplication, increase the number of security records and make security implementation and management more complex and time-consuming.
Don’t assign different row security restrictions for the same data item to the same user
When you create Data Roles, make sure that row security is only defined once per data item. This is because the first instance of row security for the data item read will be the one that is enforced. So if, for example, you have row security defined for MCU in two different Role definitions, and a user is assigned both of those Roles, only the first instance of row security read will be applied.
Apply these JD Edwards EnterpriseOne Specific Settings:
Set Row Security to Inclusive
This is a setting in the F00950 that defines how row security is processed. We recommend Inclusive Row Security, which means you are defining what a Role can access. It results in better security, fewer security records and better overall performance. Exclusive Row security requires you to identify everything you don’t want a role to have access to. It creates a security, performance and manageability risk and has absolutely no benefits.
Set Role Selection to *ALL
This setting in the P95921 application is where you turn off a user’s ability to select the role they want to log in with. It’s important to do this if you’re using Data Roles as you need users to login with all roles assigned to them. If they are able to choose their Role, they’ll have no data security and will be able to browse any data associated with their login Role.
Menu Filtering
It’s important that your Data Roles have all menus filtered so that there are no Task Views/Tasks associated with the Data Role. If this is not done, users will have access to all unsecured task views.
Role Sequencing
We recommend that you only assign one Data Role to each user. This means that you shouldn’t experience any sequencing issues, as the security in these Roles will not overlap any security they have through other Roles. For organization purposes, our recommended sequencing configuration is:
100 – 200: Data Roles
200 – 300: Inquiry Only Roles
300 – 400: Clerk Roles
400 – 500: Supervisor, Lead or Manager Roles
500 – 600: IT/Support Roles
700 +: System Admin.
Data Roles are one key element in a well-designed Security Model. For more information about other important aspects, download our paper: Best Practices for Role Design in JD Edwards EnterpriseOne
And if you need some help getting started, we offer a range of consultancy services, including a Role Definition workshop to help you design your Security Model. Contact us for more information.
Find out more about our comprehensive suite of tools which help you manage JDE E1 security efficiently.