Easy Security: The Technical Side

The technical side of NAV Easy Security

NAV Easy Security is a solution to maintain permissions for Microsoft Dynamics NAV. Permissions can be maintained from the RoleTailored Client or the Classic Client.

Maintaining permission from the RoleTailored Client is possible when using the "Standard" security model in the SQL database. Only setup of new users and the synchronize after import of new objects requires using the Classic Client.

If the Enhanced security is used, all users must be synchronized from the Classic Client after permissions have being published. Also, when adding or changing objects, a full synchronization of the users must be performed from the Classic Client.

Table structure

NAV Easy Security is based on a process of working with permissions offline. To allow this, the tables in the live system (referred to as "Live" in the following) are associated with permissions copied to a new set of tables (referred to as "Easy Security" in the following). This copy always happens through a Restore Point. A Restore Point (referred to as "Restore Point" in the following) can be created both from "Live" and "Easy Security" tables, and a "Restore Point" can be written to "Easy Security" and partially to "Live".

A Visio diagram is available on Mergetool.com. Easy Security Visio Diagram

Below are 3 drawings of the different tables. Each group of nine tables contains a similar field structure. Some of the tables in "Easy Security" and "Restore Point" have been renamed to make a more consistent naming.

Live tables

The "Live" tables for permissions are all global to all companies. The information stored in these tables is available to be viewed in every company in the database. The "Easy Security" and "Restore Point" tables are not global to all companies, allowing for only limited access to the definitions of logins and roles.

Restore Point tables

The "Restore Point" is used to save complete permissions, both from "Live" and "Easy Security". The tables have been renamed to use the consistent naming in NAV Easy Security, but they are similar to the "Live" tables except that a version field is part of the primary key.

In the Windows Login table a field User ID has been added. When moving a Restore Point from one domain to another, lookup of names is not possible. This can be solved by adding the Windows Login SID to the Windows Login Mapping table with the appropriate information. After the information is added, logins will use the nicer names.

Easy Security tables

In "Easy Security", several tables other than the standard nine tables are available to maintain permissions in a more efficient interface. Database Logins and Windows Logins are maintained from a new table "Login" that allow assigning permissions as another user and many more features.

Roles can be grouped with a "Role Group" containing roles or other role groups. The same goes for companies that can be grouped with a "Company Group" containing multiple companies.

The Login Access Control allows adding both roles and group of roles to a login. Only company groups can be used in the access control. This is done to very easily handle renaming of a company or adding a second test company without changing all the access controls for the logins. During the installation process a group is built for each company used in the existing permissions.

Login Permissions are created when updating the login in "Easy Security". Only objects in the Limited Access Object table are by default included. This is done to limit the data created when updating logins. With a large installation with 200 users, 20 companies, using form, report and page level permissions,more than 20,000,000 records could be deleted and created, potentially causing slow performance.

Role Builder

The Role Builder Module adds another way of maintaining and building roles by using recordings and only adding a few permissions to either limit or add extra permissions. The Role Details are used to recreate Roles based on the Role Recordings and Role Builder Permissions. A few roles are special (like ALL and SUPER) and cannot be maintained in the Role Builder.

In the Classic Client, recording of permissions is done using the Client Monitor. Before starting a recording, the database should be closed and reopened to ensure the object cache is not loaded with objects. If this is not done, the recorded permissions for objects can be missing.

Below is a diagram of the tables in Role Builder and their relations with the "Easy Security" tables.

A Role can contain multiple Role Recordings and Role Builder Permissions. Recordings are added first to the Role Permissions, and the Role Builder Permissions can be used to add or reduce the permissions in the role after the recordings are added. For example access could be removed for a codeunit (412) even if the recording included it.

Role Details, related tables, and Recordings can be exported and imported easily, moving data between a test and a live environment. A recording can be performed by a partner and imported at the customer site if the customer has not purchased the license for the Client Monitor.

Source Code Analyzer

Updating permissions by adding table relations and flowfield definitions makes recordings and creating permissions in roles much easier. Only the primary tabledata permission needs to be added in the permissions and related tabledata permissions will be added from the source code. The process of scanning the source code is based on the actual code in the database. This ensures that customizations and add-ons will also be included. By using the Role Builder and Source Code Analyzer, it is also possible to have a role based on a recording that will be updated in the future if another add-on or customization is added.

Below is a diagram of the tables in Source Code Analyzer and the relations with the "Easy Security" and Role Builder tables.

The Source Code Analyzer data can be created based on lookup into tables in "Easy Security" or "Live". Only the relations based on Easy Security can be added to roles.

Working offline with Restore Points

A very important part of NAV Easy Security is the ability to work with permissions without changing the actual users. The Easy Security tables can be changed and recreated without affecting the users in the database.

The tables in "Easy Security" and "Restore Point" are not used in the active companies and will have a limited number of records. Because of the many flowfields of the type COUNT, most of the tables are very well indexed. This will cause publishing and similar operation to be a little slower, but the performance in the NAV Easy Security application is much better.

"Restore Points" are used for moving data from "Easy Security" to "Live". The diagram below explains the process of moving the data between the tables.

As the picture shows, it is only possible to move "Easy Security" to a "Restore Point" and a "Restore Point" to "Live" this ensures that no direct changes are done. Because every publishing of permissions builds a restore point, it can be reversed very easily to the state before the publishing.

A "Restore Point" can also be exported and imported to allow moving permissions from one server/database to another.

Publishing permissions

To publish permissions,a couple of steps are required. The Publish Permissions window makes this very easy.

In most cases, all steps should be processed. Click on the Publish after selecting the steps. The user doing the publishing of permission must be a SUPER user. The step, Update All Roles from Roles Details, requires that the Role Builder module has been purchased.

It is possible to only do a few steps or only create a restore point by selecting the actions under functions.

Don't Like

Related resources

Download software from Mergetool.com