Developing a security artifact using AOT

A security artifact is an architect of a security system within an entire system or application environment. In Microsoft Dynamics AX 2012, the security system contains the following artifacts (ordered by hierarchy):

• Policies: Security policies are a set of security roles that control the working environment
• Security role: This represents the scope of work for every person in the organization
• Duties: These are responsibilities that perform tasks for a specific business objective or process cycle, and they contain a set of application process privileges
• Privileges and permissions: These are a group of access rights granted to users

The following screenshot shows the security artifacts that you can develop from the AOT to build your security environment:

Setting permissions for a form

The first step is to control access to the data in any form in the AOT; if you open any form in the AOT, you can set permissions to CRUD:

• Create
• Read
• Update
• Delete

These types of permission are set automatically for tables that are used in the form (CRUD; this function is called auto-inference. Auto-inference configures table permissions in a form (CRUD), and the system automatically adds or updates the (CRUD) nodes by navigating to AOT | Forms | <FormName> | Permissions.

You can set up the permission manually, and you can do this not only for a form, but also for several AOT elements that include:

• Services | <ServiceName> | Operations | <OperationName>
• Reports | <ReportName>
• Parts | Info Parts | <InforPartName>
• Forms | <FormName>
• Web | Web Files | Web Controls | <WebControlName>

Note

When you open the Permission Type (Read) node by navigating to AOT | Forms | <FormName> | Permissions, you will notice that you have the ability to set controls for a table as securable objects or server methods.

Assigning permissions to privileges

Privileges are a set of permissions that provide access to a securable object. It is the second step after specifying permissions when developing a security artifact.

Using the auto-inferred table permissions and securing menu items with privileges, you can control access to the data in a form.

In the preceding screenshot, the AccountDistCustFreeInvoiceMaintain privilege contains an entry point, AccountingDistCustFreeInvoice. This is a menu item that points to a form.

In the Properties tab, the AccessLevel value is set to Delete, and this means that when a user accesses the form through this particular menu item, the security framework in MS Dynamics AX will be under the Permissions | Delete node in this form and will grant access to the tables that are listed under that node.

In this example, you will notice a relation between the privileges, entry points, and permissions that determine the user access permissions if they access this privilege through a security role.

Note

The menu items in the AOT act as a higher layer of abstraction for a form, reports, and so on, and it contains a complete list of the items that can be presented in a menu.

Each menu item has the following security properties:

• Create permissions
• Read permissions
• Update permissions
• Correct permissions
• Delete Permissions

These properties can refer to the nodes under this: AOT | Forms | <FormName> | Permissions.

Entry points refer to a programming object that is at the start of an application functionality and can be directly associated with privileges.

Entry points can be referred to a lot of object types, such as form, job, info part, query, report, SSRS report, and class.

For example, for an entry point referring to a menu item that is referring to a form, permissions are defined in the AOT node as Permissions | Form | Menu Item | Entry Point (on a privilege).

The following figure (Developer Network on http://msdn.microsoft.com) illustrates the sequence of using auto-inferred permission:

As a security best practice, you have to check the following:

• One entry point must be assigned to a privilege
• Every privilege must be contained in at least one duty
• Every duty must be contained in at least one role
• Every role must be contained in at least one process cycle

Validating and testing a security privilege

After you implement the data security structure in Microsoft Dynamics AX 2012, you will want to make sure that you make accurate changes. For the testing process, you need to do the following:

1. Create a role by navigating to AOT | Security | Roles.
2. In the AOT, assign the appropriate duty or privilege to the new role.
3. Create a test user account (such as axtest3) by going to System Administration | Common | Users | Users.
4. Assign the user to a role by going to System administration | Setup | Security | Assign users to roles.
5. Start the application with a command line or shortcut that is similar to the following (wrapped lines):

   %windir%\system32\cmd.exe /c runas /savecred /user:mywindowsdomain\axtest3 "C:\Program Files (x86)\Microsoft Dynamics AX\6.0\Client\Bin\Ax32.exe" 
   

Applying a configuration key

Configuration keys allow administrators to set the security for a user group by minimizing access to a user group to reduce the potential attacks.

The benefit of the configuration key is to protect sensitive data in the database and prevent users from changing code and objects in the application.

Configuration keys are applied for the following:

• Tables
• Fields
• Views
• Menus
• Menu items
• Form controls
• Indexes
• Extended data types
• Report controls

The following screenshot shows the configuration keys:

To create a configuration key, follow these steps:

1. Expand the Data Dictionary node in the AOT.
2. Right-click on the Configuration Keys node and select New Configuration Key.
3. Right-click on the configuration key and click on Properties.
4. Rename the configuration key by modifying the Name property.
5. Right-click on the object and click on Create in the shortcut menu.
6. Right-click on the object and click on Save in the shortcut menu.

Note

When you disable a table in the configuration key that is listed in the AOT in Microsoft Dynamics AX 2012, you must decide whether to manually delete the data that is in the table or not. In the earlier versions of Microsoft Dynamics AX, when you disable a table in the configuration key, the table is dropped from the SQL Server and all the data is deleted. This change happened in AX 2012.