Bypassing EnterpriseOne Menu-Based Security in the Web Client

A certain philosophy exists within the JD Edwards ecosphere where some believe that instead of doing the hard work to properly secure an EnterpriseOne system they can instead configure the menu in such as way as to "hide" applications from users.  This is perhaps based on a couple of faulty premises - that menu configuration is easier than security configuration and that users will not be able to access applications that are not present on their menu.

This concept is commonly called Security by Obscurity and is in violation of Kerckhoffs' Principle, which holds that a system should be secure because of its design, not because the design is unknown to an adversary.

I can state without a doubt that a properly executed security design is not only easier to configure but actually makes future changes easier; the system is more ductile with a good security design.  A role-based menu structure without underlying security actually becomes more difficult to administer as business processes change and subsequent modifications are needed to the menus.  The end result is often either a menu redesign or a proper security implementation being done.  The arguments for Security by Obscurity fail while the shortcomings remain.

This article will demonstrate how to bypass what was once termed "Menu-Based Security" in the E1 web client using one method that is readily available to E1 end users.


This method of bypassing a menu obfuscation security model uses the Send Shortcut method built-in to the E1 web client.

In this scenario there are two users - one with Address Book Revisions (P01012) on their menu and one without Address Book Revisions on their menu.  This would supposedly keep the second user from executing P01012 by giving them nowhere to click to execute the application.  A key point in this scenario is that both users have underlying application security permission to execute P01012.

To begin the bypass, the supposed "privileged" user opens the application (P01012 in this case) and selects Tools/Send Shortcut.


















This will bring up the Send Shortcut E1 application and allow the "privileged" user to specify to whom they wish to send the shortcut, in this case a supposed (by virtue of the lack of a menu item) "non-privileged" user, CNCTEST.


















The "non-privileged" user, CNCTEST logs onto their web client and opens Work With Work Center, finds the E1 message in their Personal In Basket and chooses the message content in the dropdown on the right.

Doing this reveals a link to Work With Addresses attached to the message.

Clicking this links opens the Work With Addresses application in the web client, despite there being no menu item for Address Book on the "non-privileged" user's menu.

















While arguments can be made to support the design and implementation of an EnterpriseOne system that relies on Menu Filtering to "secure" the business, I doubt that the lack of security inherent in this method can compensate for the possible gains.  A well-planned combination of all types of security plus a menu design based on ease of use, having all the applications each user needs and only the applications a user needs in a clutter-free, intuitive layout will provide the security and usability that you desire.

Update (4/2/2010): A related post "Securing/filtering Menu Task Views" can be found over on Boris Goldenberg's site.