JDE Security – Closed vs. Open (part 2)
Tags: EnterpriseOne, JD Edwards, JDE, JDE Security
While providing an overview of Open Model security in part 1 of this blog, I gave some examples of why an Open Model configuration is often selected, and ways it is implemented. In part 2, I will go into deeper details and provide some examples of how Open Model security configuration is used with JDE.
In an Open Model implementation, all applications, reports, actions, and data are available for every user that logs into JDE, which is the default model that JDE uses out-of-the-box. Applications, reports, actions, and data are the four most relevant areas for an end user to perform their daily tasks, so it is crucial to restrict access to these areas to certain users and roles. At bare minimum, company and personal information should be protected.
Let’s review the main security features and how they are used in an Open Model security implementation.
Application security is one of the most used forms of security in JDE. This security allows the CNC administrator to deny or grant access to applications and reports. Below is an example of an application and a report that the role ECSECURITY has been denied access to.
In the screenshot above, the Address Book application (P01012) and the Full Address Report with Codes (R01403) have been denied to the ECSECURITY role. Using an Open Model configuration, all applications and reports that end users need to be secured from will have to be setup this way. Although this setup is typically done at the role level, it can be time consuming for the CNC Administrator in charge of security if there are a lot of roles, applications, or reports to setup.
Action Security enables or disables the ability for the user to ADD, CHANGE, DELETE, OK/SELECT, COPY and GO TO END while inside an interactive application. This security can be configured for each application that a user would access. For instance, a situation may call for a user to be able to perform all actions while inside the P01012 except the ability to DELETE records. There are times a user needs to be able to access information in an application, but not modify or delete that information. Denying access to all of the actions takes away the ability to even select a record to drill down into. There are many different combinations of ACTION security that can be used, and each application can have a different setup. The following screenshot is an example of 3 different applications with different combinations of ACTION security:
Solution Explorer Security
Solution Explorer Security plays a critical role in an Open Model security implementation by restricting user/role access to the Fastpath. Without restricting access to the Fastpath, the CNC / Security Administrator would have to setup application and report security to a very large number of items. With Fastpath restricted however, the Administrator only needs to create security entries for the items that the user/role can get to, using their current menu/task structure. The implementation of an Open Model configuration without restricting Fastpath is extremely time consuming and not recommended.
In addition to restricting the Fastpath with an open model security implementation, roles/users are blocked from viewing menu/task items using an application called Menu Filtering (or Fine Cut). Fine Cut is used to hide tasks from a task view and assign and save them to a user or role. After the desired items are hidden for a particular role, logged in users will still see the Task View, but will only see the specific tasks that were not hidden from the Task View. A false sense of security is often given with the thinking that if the user cannot see a task, they cannot run the application. The problem with this approach is that applications can be called from inside other applications via row/form exits.
Data Security is the last form of security I will cover today and, as you can imagine, is used to secure data from users or roles. Data Security is an all-encompassing term to describe two different security types, row and column security.
Here is a typical scenario I have encountered: a user cannot be locked out of an application because there are functions within that application they require to do their job, but there is also sensitive data within that application that is confidential or must be segregated based on duties. A good example is the Tax ID field in the Address Book application, which is used to store Social Security numbers. The Tax Id field reside in the F0101 table and the table is accessed from many applications. You can use column security to deny access to users and roles to just that particular column. Below is an example of locking out the TaxID number on the table for a specific role:
Below are screenshots of what happens before and after the security is set. Note that the Tax ID column is not present on the second screenshot:
Column security could also be setup on individual applications instead of setting it up on the table. Setting it up on the table means that anytime any application accesses the particular table, the column will not be available.
In addition to column security, row security can be used to lockdown rows of data in an application or table in a similar manner. In this case, a ‘from value’ and ‘thru value’ is configured to determine what data will be allowed, and which data will be denied. An example of row security usage would be using the Address Book application to restrict specific Search Types from a user or role. Below is the setup in security workbench to lock down the vendors search type, along with the before and after screenshots.
All of the security examples that I have provided have been based on an Open Model security implementation.
In summary, in an Open Model security implementation, users have access to everything unless explicitly denied by the CNC or Security administrator. Open Model configuration is typically used by small companies that do not require a high degree of control over data and/or for companies that do not use JDE for sensitive or critical processes.
On the next post I will review the Closed Model Security Implementation, so stay tuned!