Saturday, October 21, 2017    
Portuguese 
Spanish 
Skip Navigation Links
Home
My Account
Forum
Try It!
Buy It!
Skip Navigation Links
About
Contact Us
Site Map
Skip Navigation LinksHome > 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

Overview
StrataFrame Role Based Security provides a convenient, yet extremely thorough methodology of embedding security at the base level of your application.  The ultimate goal of any security system is to prevent a breach into unauthorized areas of the application from all points of user interface.  Many application developers are faced with the arduous task of designing and implementing a security system that resides on top of an existing framework. 

Security within Strataframe is engineered at the most elementary level of the framework.  This allows the developer to set security rules with associated business objects and UI controls. 

End-User Security Application Included

Strataframe Role Based Security also provides the developer with a robust Security Application for development and maintenance of global security preferences, permissions, roles, and users.  The Security Application may be embedded and distributed with your own application, with a royalty free runtime license.   

Technical and User Help
Role Based Security is also distributed with both Technical Help to be used by the developer for implementation within your application, and with User Help that explains the Security Application for the end user.  Of course, the User Help may be distributed royalty free runtime.


Global Preferences
View Larger Image
Global Preferences

Preferences Overview
The global preferences are used to enforce universal constraints within the security system. With the exception of password expiration and session lockouts, the values cannot be overridden. The preferences exist in order to control password strength, password policies, logon regulations, and session locking.

For example, the maximum and minimum password length, the minimum time between password changes, the maximum password age, and the complex passwords flag are a few of the properties associated with the 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.

Permissions
View Larger Image
Permissions

Permissions Overview
Resources within the application (i.e. form, module, business object) are assigned a permission. This permission is required to access or manipulate that resource within the application. The permission is then granted or denied to specific roles and users to indicate whether the users have the right to access or manipulate that resource.

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.

How Permissions are Used
Typically, permissions are divided into one of the following categories:
  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.

Permission Actions
Several actions are available when a permission has been rejected at runtime.  Obviously, these actions are established by the developer based on the needs of the application function.  These actions are:

  • No Message - This option is used when no message needs to be displayed to the end user.  For example:
    1. Programmatic Access - This option may be used for programmatic access when user intervention is not necessary. 
    2. Field Level - If this is set for a field and its access is denied, the user will not be able to view the contents of the field (it will be blank). The actual data that is bound to the field is not changed, only its viewing state.
  • Message - The message entered in the Message or Key text box will be displayed to the end-user.
  • Message Key - The message key entered in the Message or Key text box will be looked-up and its corresponding text will be displayed to the user.
  • Replace each Character - This selection is the same as the "No Message" selection, the only difference being that instead of blanks being displayed, the character "X" will be used to replace the field contents. Again, only the viewing state is changed with this selection, the actual data is unharmed.
  • Roles
    View Larger Image
    Roles

    Roles Overview
    In role-based security, permissions are associated with roles.  Users are then made members of roles, thereby acquiring the associated permissions. The purpose of the role is to group like tasks such as nurses, doctors, or insurance clerks together, thereby helping manage users and control access to application functions.

    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.

    Users
    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.

    Restriction Sets
    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.

    Security keys
    View Larger Image
    Plumbing Security Into Your Application

    Incorporating Role Based Security into your application is made easy using the Strataframe Security system.  Using a granular approach, security may be embedded into each area of your application.  As previously mentioned, the Security Application is ready to use and install in your user sites; thus, much of the coding is already done.  The programmatic interface is made simple as well.

    Security Keys
    Security Keys are the basic security elements that allow you to customize and embed security into your application.  Easily established via the Security key Type Editor, security keys may be created and maintained for every element deemed necessary by the developer.  For example, a security key would be established for each form with restricted access rights.  Another security key would be established for a business object, detailing whether the user has access to the business object, and if so, whether they have create, edit, and viewing privileges.

    Another type of security key may reflect access rights to fields within business objects.  This allows field sensitive data to be restricted for editing or view based on the user roles and privileges.  This approach enables the developer to decide the level of security needed for all areas of the application.

    Standard Logon Form
    View Larger Image
    Programmatic Access

    All of the methods and classes are easily incorporated into StrataFrame applications since they exist at the most basic hierarchal level.  This makes incorporation of role based security seamiless in appearance to the end user of your application.  The following shows a few examples of how to incorporate particular security actions and features within your application.

    Showing the Initial Logon Form
    Showing the initial login form within a StrataFrame application is accomplished through the MicroFour.StrataFrame.Security.Login class. This class has a LoginFormType property that accepts the System.Type of the form that will be shown as the login form. This form type defaults to MicroFour.StrataFrame.Security.LoginForm and can be set to any custom login form that implements the MicroFour.StrataFrame.Security.ILoginForm interface.  A custom login form may also be created and incorporated into the security application. 

    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.

    Sample - Showing the Initial Login Form [Visual Basic]
    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;
        }
    }



     

    Portuguese
    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.










      










     

    Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

    Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.