Overview of Security in MM .NET

User security in MM .NET is data-driven and configurable by both developers and end users. By default, we've taken the approach of setting user security at the user interface level. This makes it extremely easy for end users to set up and maintain application security in an intuitively obvious way.

For example, as discussed in the Help topic End-User Security Setup for Controls, a user can go into Security Setup mode, which displays a special icon next to each control on a form that is marked as "secure":

If they click an icon, it launches the User Security Setup dialog allowing them to set user and role access for the selected control:

Setting up security this way acknowledges the fact that most end users think very literally. This allows them to see the control they want to secure, and set user/role access on the spot without the extra step of launching a separate User or Roles form.

Specifying Edit, Deletion, and Creation Rights

MM .NET's custom security can also be used to specify whether end users have edit, creation and deletion rights. You can do this by setting the access on the appropriate edit, create, or delete controls. For example, the following image demonstrates setting the access rights to read-only on a New button:

Users and Roles

Security access can be set at either the user or the role level. You can specify the different user roles by means of the Roles form:

You can specify the roles that a user belongs to by means of the Users form:

For details on setting up these forms in your application, see Step 5 and 6 of the Help topic Enabling User Security in a Windows Forms Application.

Security Control IDs

All MM .NET Windows Forms and Web Form controls have a ControlID property that can contain a Globally Unique Identifier (GUID). If this property is empty, it indicates the control is not secure. If you assign a GUID to this property, it identifies the control as being secure.

As shown in the following sequence diagram, when a control instantiates at run time, it checks the value of its ControlID property. If it's not empty, the control makes a call to the Security Manager, which determines the specified access level to the control for the current user. It then stores the access level to the control's AccessLevel property which in turn calls the appropriate "Set Access" method:

Controls that are "No access" for a user do not appear at run time. Controls that are "Read Only" access are visible, but their values cannot be changed (for most controls, this means setting their ReadOnly property to true). Controls that are "Full Access" can be viewed and their values can be changed.

In a Windows Form application, when a user logs into the system, all relevant security records are read and cached by the Security Manager so that checking and setting the security level of a control is extremely fast.

Security Outside the Context of the User Interface

Although the instructions in this guide discuss security in the context of the user interface, you can actually use the MM .NET security architecture in other ways. For example, you can assign other application elements (even particular events or processes) a unique GUID. To determine the user access level for a given element, you can call the Security Manager's GetAccessLevel method that accepts a single GUID parameter. This method returns the access level for the current user. An alternate overload of this method accepts both a user primary key and a GUID so you can check the access level for any user at any time.

For details, see the Help topic Security Business Objects.