JDE Security – Closed vs. Open (part 1)16th July 2013
Security is a vital component of your JD Edwards environment and needs to be implemented properly to make full use of its benefits. Security is an area that can be confusing and tough to implement, regardless of whether you implement it before or after go-live.
In this three part blog, I will discuss security as it pertains to JD Edwards. In part 1, I will give an overview of the two most popular security implementation approaches, the closed model and the open model. In Parts 2 and 3, I will dig under the covers of each of the models to give you some real world scenarios of how they can be used.
Part 1 – Security Overview
Oracle’s JD Edwards EnterpriseOne provides the ability to control security for individual users and roles by granting them access to only perform tasks that are essential to their job function. To achieve that objective, security in JDE is typically setup using either a closed or an open model. I have seen both models implemented at client sites, and the decision of which one to pick really comes down to your business requirements and what you want out of your security once it is live. Let’s take a look at each model.
The open model security approach is the default out of the box setup. Access to all objects is granted under the open model approach. Users have the ability to run all applications and reports, and have access to all of the data. In this model, an administrator must then restrict users and groups from accessing objects and data that are not required as part of their daily jobs. This approach is typically accompanied by menu filtering to “secure” undesired items from the users view, which gives a false sense of security. I have seen this method used multiple times when a client does not have the knowledge to adequately setup security. Leveraging this method is a common mistake that is realized after application setup and end user testing.
The open method is typically chosen because it is perceived to be faster to implement, and although JDE will function with an open model, it is not the most secure option as it relies heavily on menu security. All implementation projects face a great deal of pressure to hit their go-live dates, and choosing the open model creates a shortcut that can make hitting those dates more feasible. It is important to note that by taking this shortcut, you are making a decision that could allow unwanted exposure to sensitive data such as Social Security numbers and payroll information. The open model also creates long term issues if the client ever wants to convert security to the closed model, not to say it is very difficult to audit and report on.
The most effective and secure way to setup security is via the closed model. To configure the closed model, an administrator denies all groups the ability to run applications and reports, while also locking out visibility of data. Once this has been implemented, the administrator grants back access to only the applications, reports, and data that is necessary to run daily job assignments. This assures that there are no missed objects to lock down and eliminates the worry of users getting into something they should not have access to view or change. This approach also has the benefit of not relying on any menu filtering capabilities.
A closed model takes longer to implement because there can be challenges during the setup. One common challenge that we see is when testers are locked out to opening required objects to perform their tests. In addition to JDE X-Ref, trial and error is sometimes required to determine the full list of objects and dependents which are required for that particular function you want to open up. It can take several iterations, in some cases, to get the required end result. If the effort is not properly managed, it can cause project delays, and ultimately push back your go-live date.
EmeraldCube Solutions typically proposes the closed model as it is the industry gold standard. Auditors prefer the closed model because they do not have to worry about things they cannot see slipping thru the cracks. Over the years, I have taught many security workshops and one of the first topics of discussion is always the security model the client is going to implement. Once I discuss the two approaches, a long discussion typically ensues concerning the merits and issues of both. It is often a shock to some clients when they realize how much effort is involved in setting up security properly. Unfortunately, customers often pick what is expedient rather than taking the time to implement best practices in JDE security.
Be on the lookout for my next blog where I will dive into details and provide real world examples of the EnterpriseOne security models.