Microsoft Dynamic AX 2009 : Configuration and Security - Security Framework (part 3) - Security Coding

3. Security Coding

In this section we cover the Trustworthy Computing features of Dynamics AX, focusing on how they affect security coding. We describe table permissions, code access security, impersonation in batch execution, and the best practice rules for ensuring deployment-wide compliance.

Table Permissions

The table permissions framework provides security for tables that reside in the database and are available through the AOT. Annotating specific create, read, update, and delete operations on tables, combined with assigning user group permissions on tables, enables the AOS to authorize individual user permissions on tables.

The AOSAuthorization property specifies the operations that can be performed on a table when combined with user permissions set on the User Group Permissions form. Figure 5 shows the table property form and values for AOSAuthorization.

Figure 5. Table property form

The AOSAuthorization property is an enumeration with the possible values described in Table 1.

Table 1. AOSAuthorization Values

Value	Description
None	No AOS authorization validation is performed (default value).
CreateDelete	Create and delete authorization validation is performed on the AOS.
UpdateDelete	Update and delete authorization validation is performed on the AOS.
CreateUpdateDelete	Create, update, and delete authorization validation is performed on the AOS.
CreateReadUpdateDelete	All operations are validated on the AOS.

To secure the database tables even further, you must have a set of data manipulation language (DML) validation routines at the AOS server location when inserting, reading, updating, or deleting records from the database tables. The following four system-defined methods are included in the Override Method group to support the routine validation, located in the AOT under Data Dictionary\Table\Methods:

• AOSValidateDelete

• AOSValidateInsert

• AOSValidateRead

• AOSValidateUpdate

Table 2 describes the behavior of the AOS when authorizing an authenticated user on a table, including the user group permissions setting and the AOSAuthorization property value.

Table 2. AOSAuthorization Property Values

		Property Value
		None	Create	Read	Update	Delete
User Group Access Value	No access	Success	Failure	Failure	Failure	Failure
	View	Success	Failure	Success	Failure	Failure
	Edit	Success	Failure	Success	Success	Failure
	Create	Success	Success	Success	Success	Failure
	Full control	Success	Success	Success	Success	Success

Code Access Security

The code access security (CAS) framework provides methods that can make dangerous APIs more secure against invocation attempts by nontrusted code (code that doesn’t originate in the AOT). If you extend the CodeAccessPermission class, a derived class can determine whether code accessing the API is trusted by checking for the appropriate permission.

If the API executes on the server tier, the impact of malicious code that could exploit the API is more severe in a shared environment, so you must secure the API. To secure a class that executes on the server tier, follow these steps:

1.	Derive a class that can’t be extended from the CodeAccessPermission class.
2.	Create a method that returns the class parameters.
3.	Create a constructor for all the class parameters that store permission data.
4.	Override the CodeAccessPermission::isSubsetOf method to compare the derived permission class with CodeAccessPermission to determine the existence of the required permissions for invoking the API you want to secure.
5.	Override the CodeAccessPermission::copy method to return a copy of an instance of the class created in the first step. This step helps prevent the class object from being modified and passed to the API that is being secured.
6.	Call the CodeAccessPermission::demand method before executing the API functionality that you’re securing. The method checks the call stack to determine whether the permission required to invoke the API has been granted to the calling code.

Additional information about code access security and securing APIs is available in the Microsoft Dynamics AX 2009 SDK.

Batch Jobs

Dynamics AX 2009 introduces a new and more secure type of batch framework that is completely server bound. Rather than having to start a client and open the Batch Processing form, you can now schedule a batch job so that the server automatically picks up and executes it at a given time.

A batch job can be composed of multiple batch tasks that can be executed in sequence or in parallel. For a batch task to run on the server using the new batch framework, the job must use the runAs function. When this type of batch processing is used, the user who initiates the batch processing can’t interact with the batch task or view its output. In addition, the task must not access any client-side resources while executing.

Dynamics AX 2009 also continues to support batch processing that doesn’t use the runAs function and requires the client to execute. And if you need to, you can easily update old batch-enabled classes to use the runAs function.

Note

When you move batch tasks to the runAs function, you must ensure that there are no additional Dynamics AX application runtime interactions.

To identify possible runtime interactions, use any of the following approaches:

• Perform a manual code review.

• Identify transition exceptions in the Infolog by converting the X++ class to a server-bound batch job (as in the following syntax example), submitting the X++ class for batch processing, and checking the Infolog for transition exceptions.

• Identify client/server interactions using the client/server trace by submitting the unmodified X++ class for batch processing and checking the client/server trace for client/server interactions.

If you discover any runtime interactions, you should eliminate them by refactoring the application logic involved. When the class is ready to use the runAs function, you must override a method shown to return true, as shown here.

public boolean runsImpersonated() { return true; }

Note

Batch jobs in Dynamics AX 2009 can contain a mixture of legacy and new batch tasks. The tasks that use the new framework automatically execute on the server, whereas the legacy tasks require the batch processing form on the client to be running.

Best Practice Rules

The Best Practice tool can help you validate your application logic and ensure that it complies with the Trustworthy Computing initiatives. The rules that apply to Trustworthy Computing are grouped under General Checks\Trustworthy Computing in the Best Practice Parameters dialog box, as shown in Figure 6. The Best Practice Parameters dialog box is accessible from Tools\Options.

Figure 6. Best Practice Parameters dialog box with Trustworthy Computing rules