Home > Application Framework > Role-Based Security StrataFrame Role Based Security is very comprehensive and provides the end-user with the expected protection afforded by a well designed software security system.  Its ultimate goal is to prevent a breach into unauthorized areas of an application from all points of a user interface.  The actual implementation for the developer is straightforward and very well documented.  This security system is more advanced than a typical out-of-the box framework security module.

Role Based Security Overview

View Larger Image

Global Preferences

Password Complexity
The requirements for a complex password follow closely to the requirements defined by Microsoft® for complex password within a Windows® 2003 system.

The exact specifications for a complex password are:

• The password must be at least six characters long.
• The password must contain characters from at least three of the following five categories:
  • English uppercase characters (A – Z)
  • English lowercase characters (a – z)
  • Base 10 digits (0 – 9)
  • Non-alphanumeric or symbols (for example: !,$,#, or %)
  • Unicode characters
• The password cannot contain three or more consecutive characters from a word in the user's account name. For example, if the account name is "John L. Doe", a password would not meet the minimum complexity requirements if any of the following combinations was contained within the password: "joh", "ohn", "doe".

Logon and Sessions
Preferences also contains the settings for user logon and session inactivity lock.  A password input interval may be established that specifies the amount of time a user must wait after an invalid logon attempt before he/she is allowed to logon again.  This methodology discourages automatic programs designed to hack system passwords.

Session Inactivity Locks allow the user to establish the amount of time of inactivity before the session is locked and the user mus re-authenticate before continuing to use the application.  This feature is very useful for applications where the user workstation is located in a public access area.  If used, this option will hide any active application form at the time the session is locked; thus, preventing unauthorized access or view.

View Larger Image

Permissions

The permissions available depend on the application and are assigned by the software developer and cannot be created or edited outside of the development environment. Typically, a permission is binary: either you have a particular permission or you don't; however, any permission can be configured to also allow read-only access.

1. Form-Level Permission - Access to the form is either granted or denied.
2. Table-Level Permission
   • Table-Level Add - A user can add a record to a table.
   • Table-Level Edit - A user can edit a record within a table.
   • Table-Level Delete - A user can delete a record via the form.
3. Field-Level Permission - Access to a field can be specified as either editable, read-only, or denied.

Not all levels of permissions are required to exist for all forms, therefore, it is not necessary or even practical for a permission to exist for every type of event that exists within an application.  For example, for certain maintenance forms within the application, it is only necessary for a single permission to be assigned to deny access to the maintenance form itself; the more granular levels are not required.  On the other hand if a form contains sensitive information that not all users should be allowed to view or edit, the developer can force the security for that part of the application to be more detailed, assigning a separate permission to several different fields within a single table.

View Larger Image

Roles

The assignment of a permission to a role is a simple binary function: permissions are checked to assign access and are unchecked to deny access. Furthermore, a role can be controlled at a more granular level with actions, auditing, and its restrictions of use.  The objective of a role-based security system is to manage the predominance of the access rights at the actual role level and only override permission at the user level when necessary.

View Larger Image

Users

Users Overview
The purpose of any security system is to control user access. A well designed system aids the application administrator when actually configuring a user's access rights. As previously stated, the objective of a role-based security system is to manage the predominance of the access rights at the actual role level and only override permission at the user level when necessary.

This technique allows changes to be made on a global level, the actual role, and ultimately inherited at the individual user level. Nevertheless, it is important to be able to granularly control any user without effecting roles or other users. This system is designed to incorporate the necessary control and access for the end-user.

In addition to the user name and password information, several properties allow for flexibility in the security system.  You may elect to deactivate the use account after a particular date, mark the user as inactive, make the user an Administrator, or elect to use Windows authentication for the user account.  Session timeouts may also be established at the user level.

View Larger Image

Restriction Sets

Restrictions Set Overview
A Restriction Set is used to create a global user access rule that is comprised of days-of-week, time-of-day, workstation, and action. A Restriction Set is used to enable or inhibit a user’s access depending on the action (grant, deny, or read-only).  In many applications, the user should be restricted to the time and possibly the workstation on which he/she normally functions.

This feature helps prevent password sharing (or theft) in an application setting.  Since most of the control and auditing of an application starts and ends with the security system, the restrictions sets enable enforcement on a granular basis pertaining to time and workstation.

View Larger Image

Plumbing Security Into Your Application

View Larger Image

Programmatic Access

Once the LoginFormType has been set (or left to the default value), you can call the Login.ShowLoginAndAuthUser() method to show the login form and authenticate a user into the system. The method will return a Boolean value indicating whether the end-user was authenticated or if he/she canceled out of the form and the application should exit.

Following is sample code (Visual Basic and C#) for using the Logon form.  Although not included in this document, sample code for all elements of the StrataFrame Role Based Security is similar in use and structure.  The ShowLoginAndInitMainForm() method within the AppMain.vb (Program.cs) file is provided to give a location to show the initial login form for the application.

Imports MicroFour.StrataFrame.Security.BusinessObjects
...
Private Shared Sub ShowLoginAndInitMainForm( _
ByVal e As ShowLoginAndInitFormEventArgs)

'-- Set the login form type to the appropriate form type (optional)
Login.LoginFormType = GetType(MyLoginForm)

'-- Show the login form and set the return value back to e.ShowMainForm
'   The true value passed to the method tells the method to allow the
'   end-user to cancel the login form, which will return False from the 
'   method.
e.ShowMainForm = Login.ShowLoginAndAuthUser(True) 
End Sub

Sample - Showing the Initial Login Form [C#]

using MicroFour.StrataFrame.Security;
...
private static void ShowLoginAndInitMainForm(ShowLoginAndInitFormEventArgs e)
{

//-- Set the login form type to the appropriate form type (optional)
Login.LoginFormType = typeof(MyLoginForm);

//-- Show the login form and set the return value back to e.ShowMainForm
//   The true value passed to the method tells the method to allow the
//   end-user to cancel the login form, which will return False from the 
//   method.
e.ShowMainForm = Login.ShowLoginAndAuthUser(true);
}

Retrieving Global Preferences from the Database
A shared (static) method is provided to retrieve global preference from the database.  Executing MicroFour.StrataFrame.Security.BusinessObjects.SFSPreferencesBO.RetrieveSecurityPreferences() retrieves the preferences from the SFSPreferences table in the database and populates the properties in the SecurityBasic class.  For example, the "SessionTimeout" property will contain the default time that a user's session can remain idle before the session will timeout and lock.

Specifying the Encryption Key for User Data
User data is stored within the SFSUsers database table using 3DES encryption. The key for the 3DES encryption is specified by using the SecurityBasics.SetSecurityKeyAndVectorForUserAuthentication() method. This method creates a hash of the given key and uses it at the System.Byte[] that is used for the encryption key and the initialization vector of the 3DES algorithm.  Even though the data is stored in standard databases, this methodology ensures that the security details will not be compromised.

Accessing Permissions Programmatically
The MicroFour.StrataFrame.Security.SecurityBasics.CurrentUser contains the GetPermission() method that is used to programmatically retrieve the PermissionInfo for a given permission key. The method accepts a single string parameter that indicates the permission key for which you want to retrieve the PermissionInfo. Once the permission info is retrieved, you can determine the action that should be performed.

Sample – GetPermission() [Visual Basic]

Imports MicroFour.StrataFrame.Security
...
Private Sub CheckMyPermission()
'-- Retrieve the permission and test it
If SecurityBasics.CurrentUser.GetPermission("MyPerm").Action = _
PermissionAction.Grant Then

'-- Enable the control
Button1.Enabled = True
Else
'-- Disable the control
Button1.Enabled = False
End If
End Sub

Sample – GetPermission() [C#]

using MicroFour.StrataFrame.Security;
...
private void CheckMyPermission()
{
    //-- Retrieve the permission and test it
    if (SecurityBasics.CurrentUser.GetPermission(@"MyPerm").Action ==
        PermissionAction.Grant)
    {
        //-- Enable the control
        Button1.Enabled = true;
    }
    else
    {
        //-- Disable the control
        Button1.Enabled = false;
    }
}

View Larger Image

Localization

Pre-Localized Runtimes
The StrataFrame Role Based Security application may be localized for any language.  Currently, localization sets have been created for English, Spanish, Portuguese, German, French, Italian, and Russian, .  The application objects, including forms, labels, text boxes, and lists may all be localized to one of the seven language settings.

All user messages have also been localized to the pertinent languague.  This allows developers to embed the security application in their applications for release to the end user.