m-Power Applications and Security

 

For some users, the need to implement Sign-on security is relatively low. However, at some point in time, you will need to activate the mrc Built in Security. This allows you to:

· Validate a User Against their System User Profile or a Database Table

· Implement a menuing System that shows users only applications they have access to

· Row Level Security (Limiting which rows of data a user can see at runtime)

· Capture the username for auditing purposes

· Create a fully customizable Sign on page

Each time an application is run, it will check to see if security exists. If it does, the user will be brought to a sign-on page. If no security exists, it will take the user directly to their application. To implement your security, you will need to move two files into your Data Dictionary folder.

· Copy mrcSignon2.xml from m-power\mrcjava\mrcclasses to m-power\mrcjava\WEB-INF\classes\NAME OF YOUR DATA DICTIONARY

· Copy mrcSignon2.html from m-power\mrcjava\mrcclasses to m-power\mrcjava\WEB-INF\classes\NAME OF YOUR DATA DICTIONARY

That’s it! Your users will now have to sign-on when they wish to access applications within this Data Dictionary.

Of course, security is much more complicated than just a matter of moving a few files. mrc Security offers you many customizable options. First, let’s look at our Security Configuration file (mrcSignon2.xml). Click the Data Dictionary tab, click the “Edit Data Dictionary Files” link, then click the “Sign on Configuration” link.

A popup window similar to this will appear:

Valid Validation Types are:

· System Profile (Option 0 for users running Tomcat on their AS400, Option 1 for users running Tomcat from a PC/Linux server)

· Validation List (Option 3 for all AS400 users)

· Database User (Option 4 for all non-AS400 users)

· Flat File (Option 5)

· Active Directory (Option 6)

Flat file is the default option. To change this value, replace the ’5′ in <group validationType> accordingly to the correct value. Note: The id is not currently used and can be ignored.

On the <datasource> option, your value should match the value listed in your Servlets Properties file. Click here to learn more about the Servlets Properties file.

If you wish to secure by Flat File (Option 5), you must specify the table library and name (LIBRARY.TABLENAME format), the Field containing User (col_user) and the field containing Password (col_password) within the <validateby_table> tag.

Further options include:

<signoff>: Specifies where to direct user to when they click the Sign off link.

<signon_pass>: This value controls where to send users when they have successfully logged in and they have not specified an application in the URL. If they have already specified an application to go to, they will automatically be redirected to it after they sign-on.

<signon_fail>: This value controls where to redirect users to if they exceed their number of chances to log in correctly.

<tries>: This value controls the number of incorrect guesses a user has. If they exceed this amount, they will be redirected to the URL listed in the previous tag. Note: Incorrect guesses are also sent to the Database, so if your DB locks an account at three wrong guesses, your user’s account will be disabled.

<session timeout>: By default, once a user logs in, they will only have to sign on again when they A) Close their browser or B) Tomcat has to restart. However, specifying a timeout (in seconds) will force a user to sign-on again once they have exceeded this time limit.

<callrpg>: Directly after sign-on or immediately preceding sign off, you can name an RPG program to be called. This RPG program must take two values a 10 character username field and a 40 character Session ID field. This is often utilized for logging purposes.

The <changepassword> and <savepassword> functions have been deprecated and can be ignored.

<app name>: By default, once security is activated within a Data Dictionary all applications are affected by this. However, there may be times you wish to “Opt Out” security applications from security. Let’s say I desire for Report 10 to not require sign-on, all I would need to do is copy the entire <app name> line directly below the existing one. Next, I would simply change I99999 to R00010. The next time someone tries to run Report 10, the security logic will see it is on our “Opt Out” list and not require a sign on.

When completed, please click the “Save and Deploy” icon. Note: Changes will not take effect until the next time Tomcat has been restarted.

mrc Sign-on Screen

mrc Security also comes with a file, mrcSignon2.html, that serves as a Sign-on screen that is fully paintable. To edit it, click the Data Dictionary tab, click the “Edit Data Dictionary Files” link, then click the “Sign on Screen” link.

Note: You will notice that rather than calling the standard header and stylesheet, the Sign-on Screen uses embedded headers, footers, and styles. This allows you to modify your Sign-on screen to look and feel much different than your regular applications.

Note: The mrcSignon screen is not available in the WYSIWYG m-Painter mode. Rather, it is available in standard Text-Editing mode.

When completed, please click the “Save and Deploy” icon. Note: Changes will not take effect until the next time Tomcat has been restarted.

Active Directory Validation – Additional Configuration

mrc Security allows validation against Active Directory. There are a few additional configurations that must be made in order to validate against Active directory.

Customers who downloaded and installed m-Power on or after January 10th, 2011 can skip step 1 as the necessary code already exists in mrc-spring-context.xml.

    1. From the Admin Tab choose “Edit Data Dictionary Files” and then “Datasource Configuration”. This will open you mrc-spring-context.xml file which contains database connection information. You will need to copy and paste the following code in to the bottom of the page BUT BEFORE THE VERY LAST </beans> tag:

<!-- Active Directory (LDAP) Validation -->
<bean abstract="false" autowire="default" class="org.apache.commons.dbcp.BasicDataSource" dependency-check="default" id="active_directory" lazy-init="true" singleton="true">
<property name="driverClassName"><value>com.mysql.jdbc.Driver</value> </property>
<property name="url"> <value>ldap://XX.XX.XXX.XXX:389;domain=MYDOMAIN.com;search_base=DC=MYDOMAIN,DC=com;</value> </property>
</bean>

    1. Replace XX.XX.XXX.XXX with your Active Directory server address.
    2. Replace MYDOMAIN.com with you Active Directory domain.
    3. Add the necessary domain content values (DC=) to the search_base parameter. You may add as many domain content values as is necessary for your system (separated by commas).
    4. Save and close this file.
    5. From the “Edit Data Dictionary Files” screen select “Sign On Configuration”
    6. Set the group validationType to 6 for Active Directory.
    7. Set the datasource value to “active_directory”.

  1. Save the signon configuration file and restart Tomcat.

You are now configured to validate your users against Active Directory!

Other Important things to Remember

Once a user logs in, they will not have to sign in again until:

– They close their browser

– Tomcat is restarted

– They have exceeded their timeout value

– Tomcat is loaded (often because a developer compiles or saves changes in m-Painter)

Particularly because of the last point listed above, mrc strongly recommends moving development and production into two separate environments. Not only will this provide a much more stable environment for your end users, it will give your developers piece of mind knowing that they are not changing applications that are currently in use. More information regarding this topic can be found here.

· Any changes made to mrcSignon2.xml or mrcSignon2.html after they have been loaded to memory will require Tomcat to be restarted before any changes will go into effect.