JD Edwards: Moving from an Open System to a Closed System Safely
Robbie Scott, Solution Consultant – Security and Fraud
*PUBLIC is one of the most important roles in the JDE system. It dictates the entire setup for your system, as *PUBLIC is a role everyone has “assigned”. The security assigned to *PUBLIC decides what users can and cannot see in the JDE system by default using *ALL access. There are typically two system setups commonly used.
An open system setup has either *ALL with all yes (Ys) for application and action security or no entries at all for *PUBLIC, *ALL. This means that, without any other security assigned, users in the system can see, run, and change information using any application in JDE. You can see how this can cause problems. Roles assigned to users will have to be used to restrict what users should not be able to see, run, or change. This system requires a lot more maintenance, as the person handling security will have to assign security for every program in the system except for what the role actually should have. For example, we have a voucher entry role, 04VCHENT. In an open system, we will have to assign no to application and action security for all programs in the system except for the applications required for entering vouchers. If we were to forget one program, that could be a huge security risk. If you have to do that for one hundred or even two hundred roles, it is very likely there could be a major flaw in your security that will be very difficult to detect.
The other system setup, best practice recommended, is a closed security system. It is the polar opposite of an open system, with *ALL assigned no (N’s) to application and action security. This restricts all users from seeing, running, or changing anything in the system without roles that explicitly grant access to certain objects. Roles assigned in closed systems are a lot easier to maintain, as you only need to give the roles the security they need to see. *PUBLIC will block users from being able to use anything outside of what the roles define. Using 04VCHENT again, with a closed system you only need to worry about assigning applications needed to enter vouchers. Meaning, 04VCHENT grants access to P0411. If this is the only role assigned, the user will ONLY have access to P0411. The user does not inherit any other access because of the closed security setup. This is significantly easier to work with, even if the system has hundreds of roles.
Clearly a closed system is the more secure system. So how do you switch from an open system to a closed system? The first thing to do would be to change the system’s *ALL setting in *PUBLIC to No (N) for Application and Action security. This will lock down the security for the system. From there, any roles would have to be reorganized, giving users the access that each role would need, whether it’s application security only (which would give the user inquiry access to the program) or application and action security (which would give the user full access to view, add, change, or delete data).
“Flipping the switch” from an Open to Closed Security model should involve preplanning, an executable project plan and testing to validate the security is in place properly. Please do not hesitate to reach out to the GSI Security Team if you have any questions or would like to discuss options for remediating your current security structure.
Meet the Author