Locking Down your Applications


In May of 2017, the Application Security feature was enhanced. Developers now have an additional option when securing applications. Option 1, Locking down an entire dictionary, and allowing only certain applications to be accessible, is the traditional method and is explained here. Option 2, allows all applications in a dictionary to be accessible, except for the ones listed. Listed applications are only accessible to the assigned roles. More information can be found here.

As a visual example, see the screenshot below:

In option 1, traditional security, users of the role admin could run I20. Sales users could only run R10. Any user that belonged to another role would be locked out of every other application in the dictionary. Further, even admin or sales role users would be restricted from anything other than their listed app.

By contrast, Opt-in security works differently. In the screenshot above as reference, all applications in the dictionary could be run by all users except those listed here. In these cases, admin users could only run I20, and sales users could only run R10. However, all other applications are available to all users.

Option 1 — Traditional

Many times you will want to specify that only a certain group of users can access an application. Perhaps it is a confidential (HR, Payroll, Executive data) application that needs restriction or one that can alter data (such as maintenance applications). Our Menuing System helps (most users won't access options they don't know about), but if a user were to stumble upon a page or know the URL, they could still be able to access the application.

But not anymore. One of our security features, called Application Security, limits who can access what application. The best part of the feature is that it builds upon what you have already done for your Menuing System (If not, please review the Menuing System documentation here).

For this document, I will assume you already have a healthy list of Users, Applications, and Roles defined for your Data Dictionary. Next, all you have to do is click "Admin Menu" –>
"Application Menu and Security" –> "Manage Application Security."

Click the "Add" button. Specify a Role, Application Type, and Application Number.

Note: The Roles should match the Roles that are already defined in the Menuing System.

When completed, your screen may look something like this:

In the mean time, we have created some new objects in your Data Dictionary Folder, including MrcAppSecurity.java and MrcAppSecurity.class. Although these files have been built in, they are fully customizable. If you would like to customize your security to work in combination with your own JAVA or RPG code, you are able to fully modify the MrcAppSecurity.java object. If you decide to do this, make sure you compile this JAVA object.

Lastly, while everything has been put in place, you must implement the Application Security. Once you do this, the only applications that will be accessible are the ones listed in the table above. To implement, simply click the "Enable Application Security" from "Admin Menu" –> "Application Menu and Security" button.

At runtime, if an application is included in the list above, ONLY the users assigned to the specific role will be able to access the given application.

If a user is not assigned, the application can not, and will not, display output to the user.

Other important information to consider:

  1. For this feature to work, you must recompile any application you wish to use for this security feature once you have taken an update dated May 5th, 2008 or later. Overwriting the Presentation Layer and Application Properties File is not necessary.
  2. Just like the built-in sign on logic, the built-in Application-Level Security is session-based. That means that every time you log on, the browser can remember who you signed on as, just as it will remember what applications you are allowed to access.
  3. If you have Application-Level Security enabled, and generate an application and try to run it prior to loading it to the Application Security Menu, you will be told that you do not have access to that application.
  4. Once you add the application and attempt to reload it, you will still not be allowed to run the application, unless you open a new browser or if Tomcat is restarted.
  5. For this reason, mrc recommends that you utilize Application Level Security only in production environments, where it is truly needed.

Option 2 — Application Opt-In

If you have an existing Application Security in your Dictionary, navigate to /mrcjava/WEB-INF/classes/DATADICTIONARY/ and delete the mrcAppSecurity.java and mrcAppSecurity.class files, as these files need to be updated to include the latest features.

Next, head to Admin -> Edit Dictionary Files -> Servlet Properties. At the end of the list, look for a property named "Application Security Mode." Change this value to "Opt In Applications." Be sure to Save.

Head back to your Security screen, via Admin -> Application Menu & Security -> Manage Application Security. Notice the text that says "Secure only opted-in applications."

Now, all applications will be accessible except any that are listed. Any that are listed will only be accessible to the roles that are listed.

Created: May 5, 2008 | Modified: May 10, 2017