StrataFrame Security Documentation Send comments on this topic.
Adding Security to an Application

Glossary Item Box

Purpose: The purpose of this document is to provide step-by-step instructions on how to implement StrataFrame’s role-based security within an application.

Adding Security to an Application

To add security to an application:

  1. Create your application from the StrataFrame Windows Application w/ Security template – If you do not create your application from the Windows application template that includes security, you will need to complete the following steps manually:
    1. Add a reference to MicroFour StrataFrame Security.dll – The MicroFour StrataFrame Security.dll contains the role-based security implementation and must be referenced by your application.
    2. Show a Login Form to set the CurrentUser – You can either show the default login form, or create a login form from the Login Form Template. This login form should be show from within the ShowLoginAndInitMainForm() method within the AppMain.vb (Program.cs) file.  For more information, refer to Showing the Initial Login Form.
    3. Initialize Session Locking - (optional) – The code required to initialize session locking should be added to the InitApplication() method within the AppMain.vb (Program.cs) file.  For more information, refer to Initializing Session Locking.
    4. Specify the Security Key for encrypted user data – User data stored within the database is encrypted using 3DES encryption. A key must be specified to seed the encryption algorithm. This code should be added to the InitApplication() method within the AppMain.vb (Program.cs) file.  For more information, refer to Specifying the Encryption Key for User Data.
    5. Specify the SecurityDataSourceKey - (optional) – If the security tables (SFS* tables) are not located within the database referenced by the default DataSource, then you must add a DbDataSourceItem with access to the database containing the tables, and specify the SecurityDataSourceKey to inform the role-based security module where the security tables are located.  For more information, refer to Setting the SecurityDataSourceKey.
    6. Retrieve global preferences from the database – The global preferences should be retrieved from the database and stored within the SecurityBasics class properties. The code to accomplish this should be placed within the InitApplication() method within the AppMain.vb (Program.cs) file.  For more information, refer to Retrieving Global Preferences from the Database.
    7. Specify default values – There are additional properties on the SecurityBasics class that contain default values for your application and should be configured within the InitApplication() method of the AppMain.vb (Program.cs) file. These default values specify everything from the usernames and passwords for built in accounts to the default denied action and denied message.
  2. Add a custom login form - (optional) – Adding a custom login form to your application is not required, but is recommended because the base login form does not display an application logo or company logo of any kind.  For more information, refer to Creating a Custom Login Form.
  3. Create permissions for the application within the Role-Based Security Editor – The permissions for an application must be created at design time through the Role-Based Security Editor. Once the permissions are created, they can them be attached to objects within the application to permission required to access that object.  For more information, refer to the Adding a New Permission and Assigning Permissions topics.
  4. Create Roles and Users for the application within the Role-Based Security Editor - (optional) – You can optionally create pre-defined roles and users that can be deployed with your application. These roles and users must be defined within the Role-Based Security Editor for your application.  For more information, refer to the Adding a New Role and Adding a New User topics.
  5. Assign security keys to objects within your application – Once the security keys have been defined through the Role-Based security editor, they must be attached to objects within your application to define the permission required to access that object. You can assign permissions to Business Object Fields, Business Object Actions, and Forms.
  6. Programmatically test permissions within your application - (optional) – You can enable/disable or show/hide objects within your application by programmatically testing the CurrentUser’s permissions and adjusting object properties appropriately.
  7. Add the ability to show the SecurityDialog within your application – The SecurityDialog is used within your application to provide a maintenance form to your end-users that allows them to maintain users and roles.  For more information, refer to Calling the Security Maintenance Dialog.
  8. Deploy the security data with your database – The SFS* tables within the StrataFrame database are required for the StrataFrame security module to operate at runtime. The SFS* tables must exist in a location that is reachable by your application through one of your DbDataSourceItems. The Database Deployment Toolkit has the ability to deploy both the SFS* tables and the data for the tables containing the users, roles, and permissions you specify. Without the DDT, you must manually add the SFS* tables to your database script for deployment and devise a method to deploy the contents of the SFS* tables in the StrataFrame (design-time) database to your application’s database at runtime. You only need to gather the records that match your project, identified by the appropriate record within the SFSProjects table.  For more information, refer to Deploying Security Data.