m-Power Applications and Security
Jump to:
Toggling Security On/Off
Configuring Security
mrc Signon Page
Active Directory Validation
Single Sign On Validation
Other Information
For some users, the need to implement Sign-on security is relatively low. However, at some point in time, you may 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.
Toggling Security for a Data Dictionary
To implement your security, you will need to first navigate to "Admin Menu" -> "Application Menu and Security." On this screen, click the "Enable Dictionary Security" button.
You will need to provide log-in credentials. For more information regarding these credentials, please see here.
That’s it! Your users will now have to sign-on when they wish to access applications within this Data Dictionary.
Configuring your Security Options
Click "Admin Menu", then "Edit Dictionary Files", and finally click the "Sign on Configuration" button. A popup window will open like in the screenshot below:
Signon Properties
Dictionary Security status: Developers can quickly tell if dictionary security is currently enabled by looking at the top row of this window.
Validation Type: Use this drop-down to select how you would like your sign-on security to validate your end-user's credentials. You can choose from:
- Validate by database table – This option allows you to secure your apps against a flat file where username and password are stored.
- Data Source: This option is useful if you need to point your security credentials at a secondary database that is configured in the mrc Spring Context file.
- Validate by Table: This option allows you to specify the schema & table to validate against, the column names for the user and password, and also what encryption your password field uses.
Note: To allow m-Power to use an encrypted password field, add encryption_type="XXX" to your validateby_table tag in text mode, where XXX is the type of encryption used. Valid encryption types are:
- MD2
- MD5
- SHA-1
- SHA-256
- SHA-384
To use m-Power to encrypt your database values, see this here.
- Max Signon Attempts: Controls the number of times a user can guess wrong. Once this number has been reached, they will be redirected to the URL listed in the "Signon Fail Redirect" parameter.
- Signon Screen: If you wish to use your own customized signon screen, rather than the one provided to you with m-Power, please change this parameter.
- After Signoff/Signon Redirect: Once your user clicks the signoff button or signs on (from the DICTIONARY.Login) page, they will be automatically redirected to the URLs listed here.
- Signon Fail Redirect: Once your user has exceeded the tries to sign in as defined in the Max Signon Attempts value, they will be redirected to the URL listed here.
- Validate by database user – This option is for non-iSeries databases to secure against users set up on the database.
- Data Source: This option is useful if you need to point your security credentials at a secondary database that is configured in the mrc Spring Context file.
- Validate by Table: This option is not used.
- Max Signon Attempts: Controls the number of times a user can guess wrong. Once this number has been reached, they will be redirected to the URL listed in the "Signon Fail Redirect" parameter.
- Signon Screen: If you wish to use your own customized signon screen, rather than the one provided to you with m-Power, please change this parameter.
- After Signoff/Signon Redirect: Once your user clicks the signoff button or signs on (from the DICTIONARY.Login) page, they will be automatically redirected to the URLs listed here.
- Signon Fail Redirect: Once your user has exceeded the tries to sign in as defined in the Max Signon Attempts value, they will be redirected to the URL listed here.
- Validate by system profile on remote server – This option is for securing against iSeries user profiles.
- Data Source: This option is useful if you need to point your security credentials at a secondary database that is configured in the mrc Spring Context file.
- Validate by Table: This option is not used.
- Max Signon Attempts: Controls the number of times a user can guess wrong. Once this number has been reached, they will be redirected to the URL listed in the "Signon Fail Redirect" parameter.
- Signon Screen: If you wish to use your own customized signon screen, rather than the one provided to you with m-Power, please change this parameter.
- After Signoff/Signon Redirect: Once your user clicks the signoff button or signs on (from the DICTIONARY.Login) page, they will be automatically redirected to the URLs listed here.
- Signon Fail Redirect: Once your user has exceeded the tries to sign in as defined in the Max Signon Attempts value, they will be redirected to the URL listed here.
- Validate by Active Directory – This option is for securing your applications against an Active Directory account.
- Data Source: This must be active_directory in order to pull in the connection information from the bean (configured below).
- Validate by Table: This option is not used.
- Max Signon Attempts: Controls the number of times a user can guess wrong. Once this number has been reached, they will be redirected to the URL listed in the "Signon Fail Redirect" parameter.
- Signon Screen: If you wish to use your own customized signon screen, rather than the one provided to you with m-Power, please change this parameter.
- After Signoff/Signon Redirect: Once your user clicks the signoff button or signs on (from the DICTIONARY.Login) page, they will be automatically redirected to the URLs listed here.
- Signon Fail Redirect: Once your user has exceeded the tries to sign in as defined in the Max Signon Attempts value, they will be redirected to the URL listed here.
Note: Additional Configuration Required:
- From "Admin Menu", choose "Edit Dictionary Files" and then "Datasource Configuration". This will open the mrc-spring-context file which contains database connection information.
- Find the active directory connection.
Note:
If this bean does not exist, please copy it in (directly before </beans>) using the following syntax:
<bean abstract="false" autowire="default" class="com.mrc.dbo.EncryptionDataSource" dependency-check="default" id="active_directory" lazy-init="true" singleton="true">
<property name="url"> <value>ldap://XX.XX.XXX.XXX:389;domain=MYDOMAIN.com;search_base=DC=,DC=</value> </property>
<property name="driverClassName"> <value>com.mysql.jdbc.Driver</value> </property>
</bean>
- Replace XX.XX.XXX.XXX with your Active Directory server address.
- Replace MYDOMAIN.com with you Active Directory domain.
- 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).
- Press Accept and restart Tomcat to load in your changes.
- Validate by Single Sign On – This option is for utilizing an existing non-m-Power sign on with your m-Power applications.
- Data Source: This option is not used.
- Validate by Table: This option is not used.
- Max Signon Attempts: Controls the number of times a user can guess wrong. Once this number has been reached, they will be redirected to the URL listed in the "Signon Fail Redirect" parameter.
- Signon Screen: If you wish to use your own customized signon screen, rather than the one provided to you with m-Power, please change this parameter.
- After Signoff/Signon Redirect: Once your user clicks the signoff button or signs on (from the DICTIONARY.Login) page, they will be automatically redirected to the URLs listed here.
- Signon Fail Redirect: Once your user has exceeded the tries to sign in as defined in the Max Signon Attempts value, they will be redirected to the URL listed here.
Note: In order to configure single signon, there are a few additional steps that are required. Please visit this page to see those additional steps.
Opt Out Applications
Click this tab if you wish to designate any applications within this data dictionary that should not be secured. If an application is listed here, users will not be required to sign-on when accessing these pages.
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 "Admin Menu", then click "Edit Dictionary Files" button, then click the "Sign on Screen" button.
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.
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.
Also, any changes made to mrcSignon2.xml or mrcSignon2.html after they have been loaded into Tomcat's memory will require Tomcat to be restarted before those changes will go into effect.