Inside Dynamics AX 4.0: Security Coding
The development of Dynamics AX 4.0 included many new Trustworthy Computing initiatives for more secure, private, and reliable computing experiences. The following sections focus on these security initiatives and how they affect security coding. Specifically, this section covers table permissions, code access security, impersonation in batch execution, and the best practice rules for ensuring deployment-wide compliance.
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 Application Object Server (AOS) to authorize individual user permissions on tables.
For each table described in the AOT, a new property is introduced, called AOSAuthorization. The property describes the operations that may be performed on a table when combined with user permissions set on the User Group Permissions form. The illustration in below image shows the table property AOSAuthorization and its available values.
The table property formThe AOSAuthorization property is an enumeration with the possible values described in above image.
AOSAuthorization ValuesTo 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:
AOSAuthorization Property ValuesCode Access Security
The Code Access Security (CAS) framework provides methods that can make APIs more secure against invocation attempts by non-trusted code (code that does not 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, and the utilization should be secured. To secure a class that executes on the server tier, follow these steps:
1. Derive a class that cannot be extended from the CodeAccessPermission class.
2. Create a method that returns the class parameters.
3. Create a constructor for all of 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 that 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 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 are 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 SDK.
Dynamics AX 4.0 introduces a new and more secure type of batch job that uses impersonation. Rather than executing the batch job type as the user who is running the batch process, you can now use the new runAs function to execute it as the Dynamics AX user who initially submitted the job. When this type of batch processing is used, the user who initiates the batch processing cannot interact with the batch job or view its output. Dynamics AX 4.0 includes support for batch processing that does not use the runAs function. Batch-enabled classes in Dynamics AX that do not use the runAs function can easily be changed to do so, if appropriate.
When you move batch jobs to use the runAs function, you must ensure that there are no additional Dynamics AX application run-time interactions.
To identify possible run-time interactions, use any of the following methods:
Classes in batch journals are executed according to whether they are legacy or use runAs. In other words, a batch journal can contain a mixture of batch run modes.
Best Practice Rules
Applying the principles of Microsoft's Trustworthy Computing effort involved adding about 50 new rules to the Best Practice tool to help you validate your application logic and ensure that it complies with the new security initiatives. The new rules are grouped under General Checks\Trustworthy Computing in the Best Practice Parameters dialog box, as shown in below image. The Best Practice Parameters dialog box is accessible from Tools\Options.
The Best Practice Parameters dialog box with Trustworthy Computing rules
</img> </img> </img> </img> </img>
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series||Blog bot||DAX Blogs||0||06.08.2008 12:05|
|Inside Dynamics AX 4.0: The Security Framework||Blog bot||DAX Blogs||0||31.10.2007 11:40|
|Inside Dynamics AX 4.0: Security||Blog bot||DAX Blogs||0||29.10.2007 10:50|
|Inside Dynamics AX 4.0: Usage Scenarios||Blog bot||DAX Blogs||0||04.10.2007 05:15|
|Inside Dynamics AX 4.0: Inside the Business Connector||Blog bot||DAX Blogs||0||04.10.2007 05:15|
|Опции темы||Поиск в этой теме|