Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 31.10.2007, 23:40   #1  
Blog bot is offline
Blog bot
24,236 / 809 (75) +++++++
Регистрация: 28.10.2006
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.

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 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 form
The AOSAuthorization property is an enumeration with the possible values described in above image.
AOSAuthorization Values
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:
  • AOSValdiateDelete
  • AOSValidateInsert
  • AOSValidateRead
  • AOSValidateUpdate
In below table 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.
AOSAuthorization Property Values
Code 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.
Batch Jobs
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:
  • Perform a manual code review.
  • Identify transition exceptions in the Infolog by converting the X++ class to a server-bound batch job (see 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 run-time 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.
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
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 20:28.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.