JDE Security – Closed vs. Open (part 3)

This is the last part of my JDE security blog series. On part 1, I presented an overview of the most popular security implementation approaches, on part 2, I talked about Open Security Model and on this third and final part, I will cover the Closed Security Model, in particular the Application and Action security types setup. The focus of this part will be on the setup of the closed model from the initial installation of JDE before go-live.

In a closed model implementation, all access to applications, reports, and data is restricted for all users and the ability to perform their daily tasks is removed. To allow users to perform their work, access has to be granted to individual applications, actions on those applications, reports, and data based on users and roles. Application and Action security are the main areas that are used to control access and functionality in JDE and this is where I will concentrate this blog on.

Let’s go through the 2 areas and look at what needs to happen to close the security and open it back up for specific user/roles.

Application Security

The application security in a closed model setup will deny the ability for all users to run any applications or reports once signed into JDE. *PUBLIC is used as the USER/ROLE so that security is global for all users logging in. The screenshot below shows the proper setup with *ALL being used to encompass all applications and reports. Although *PUBLIC and *ALL are used to indicate the security is for all users and objects, the setting that actually closes the access off is the RUN and INSTALL settings. The RUN = N setting secures users from running an application and the INSTALL = N setting prevents the just-in-time installation of anything necessary to run the application.

Once the application security is configured using the method described, you will have to use application security to grant back access to the applications that the users require to perform their job functions. This can be done by granting back the access per USER or per ROLE. In most cases, per ROLE is the cleanest and most efficient way to grant back security. There are also certain applications that all users need access to in order to complete daily tasks. Some of those tasks include the (P98OWSEC) User Profile Revisions Change Password which gives users the ability to change their password, (P98305W) Batch Versions for Web Client which allows a user to choose which version of a report to run from a web client and (P986110B) Job Control Master which allows access to the Work with Submitted Job application. A few common ones that may or may not be needed based on the users responsibilities to the business are (P98826) Package Detail. This allows the user to accept mandatory packages on a fat client. The (P98616) Printer selection – Search and Select. Granting this application allows users to change the printer when submitting a report. There are others that need to be reviewed and configured based on the end-user’s needs and a list of the most common applications can be found using Oracle Doc ID 626551.1 – E1: SEC: *ALL Application Security and Common Objects to Grant Back.

As you can see in the screenshot below, several applications have been granted access to *PUBLIC. In this example, these applications were deemed necessary by the business to allow all users to perform basic/crucial tasks in JDE.

I’ve shown closed model security based on the *PUBLIC role and I would also like to give an example of how to open back up reports and applications for specific ROLES. Without granting back the access, the user will get the following message when trying to access an application that has been denied:

My opinion is to always apply security through ROLES and not directly to users. It is cleaner and easier to make changes to a single ROLE than to make changes to the users that are in the ROLE. Here is a screenshot of applications and reports opened up to the ROLE ECSECURITY (this is obviously just a sample to demonstrate the feature/capability).

ECSECURITY has been granted access to the 3 applications and the 3 reports listed in the screen shot. The nice thing about seeing this from a CNC admin’s perspective and a security audit perspective is that those are the only 6 objects that are available to any user with the ECSECURITY role except the *PUBLIC objects. There are no hidden applications that the user can get to from within an application because security will not allow it. If the application calls another application from within, the user will get a message that tells them they are not authorized to run the application. This eliminates the possibility of not locking down applications that should have been denied to the end-user or role.

Action Security

Action security is used to grant or deny the end-user certain action buttons once inside an application. If the user/role does not have access to the application, setting up action security for it won’t make any difference. The following actions can be secured:

  • OK/Select
  • Add
  • Change
  • Delete
  • Copy
  • Scroll To End

These actions can be set using the *PUBLIC setting and this will have the global effect of how every user sees their options once they log in and access any application throughout EnterpriseOne. In the example below, *PUBLIC has been used along with*ALL for objects to encompass all users and applications. All 6 six functions have been set to N which will limit the user abilities inside any application he/she has access to.

As we discussed in part 2, in a closed model setup, access has to be granted back for the users to perform their daily duties. The same applies for action security (and any other security type). If we go back and look at the screenshot where it shows the applications and reports that the users in the role, ECSECURITY, were granted access to, we see there are 3 applications a user can get to. If we leave the current security as we have shown it, the users will be able to access the applications, but will not be able to use the functions. Below is a screenshot of the P01012 showing what it would look like before granting any actions back to the user.

As you can see, the SELECT, ADD, COPY and DELETE buttons are greyed out and the end-user would not be able to use them. In the screenshot below, the actions have all been set to Y (YES) for the role ECSECURITY which will now give the user access to the actions.

Here is what the P01012 screen looks like when accessing it with the actions set to Yes:

The great thing about Action Security is that there are many ways to put it into use. In the example above, I used the P01012 – Work with Addresses application to demonstrate the way to close/open all actions to the user. In many cases, an end-user would have the need to use all of the actions within this application, but there are times when a user would only need to be able ADD an address book entry or SELECT and not be able to copy or delete. The result of the setup in security workbench to attain this is below:

Action security provides very granular control of what actions the user can/cannot do when inside an application. This granularity allows the business to maintain a high degree of security without compromising the ability of the end-user to perform their daily tasks.

I hope that this has given you a good overview and some examples of how application and action security work in a closed model security setup. As we previously mentioned, the closed model approach can take longer to implement, compare to the open model, but the results are typically much better and will make your auditors happier.