Chapter 6: Security for Developers

6-1
CHAPTER 6: SECURITY FOR DEVELOPERS
Objectives
The objectives are:
Set permissions on application elements.
Design and create security policies.
Secure unsafe Application Programming Interfaces (APIs) using the
Code Access Security framework.
Authenticate data returned from display methods.
Introduction
This chapter introduces some more advanced security features of Microsoft
Dynamics AX.



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-2
Permissions
The Development I in Microsoft Dynamics AX 2012 training course discussed
roles duties and privileges. These security levels cover access to single elements,
for example forms, and groups of elements needed to perform a duty. A
developer is responsible for defining more granular security levels by setting
access on tables and controls in a form, or by associating classes that perform an
action with a permission.
Form Permissions
Each form in the Application Object Tree (AOT) has a permissions node that
contains either four or five sub-nodes - Read, Update, Create, Delete and Correct.
Correct is only displayed if a table in the form has Date Effective data. Under
these nodes are four additional nodes - Controls, Tables, Server Methods and
Associated Forms.
When a table is added to a form data source, the table is automatically added to
the Tables node for each of the Permissions sub-nodes. Each of the nodes under
the Tables node has an EffectiveAccess property which sets what access is
allowed to the table
The EffectiveAccess property is automatically set based on properties on the data
source. If the data source property AllowDelete is set to No, the EffectiveAccess
property is set to Update. If the data source property AllowEdit is set to No, the
EffectiveAcces property is set to Read.

FIGURE 6.1 EFFECTIVE ACCESS IN THE VENDOR INVOICE JOURNAL
FORM
To set access for a control in the form, set the Securable property on the control
to Yes. The control can then be added to the Controls node under each of the
permissions nodes.



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Chapter 6: Security for Developers
6-3
Code Permissions
Code permissions are a set of custom permissions that are created manually in
the AOT under Security > Code Permissions. Menu items, especially Action
menu items, can use these by setting the LinkedPermissionType property to
CodePermission and the LinkedPermissionObject to the name of the code
permission. Service operations can also use code permissions by setting the Code
Permission property under the Service operation > Operation method >
Permissions > Associated Code Permissions node.
FIGURE 6.2 ACCESS TO POST A FREE TEXT INVOICE
Security Policies
Security policies use Extensible Data Security (XDS).
Definitions
The following definitions are used in conjunction with XDS.
Constrained table: This table or tables hold the data filtered based on the policy.
Primary table: This table is used to determine how data is filtered. For example,
for a filter based on an employee, the primary table would be the HcmWorker
table.
Policy query: This query is used to return data from the primary table that is then
used to filter the data in the constrained table.
Context: This controls the circumstances under which the policy is applied.

There are two types of context:
Role contexts means the policy is applied if the user is assigned to
the role.
Application contexts means the policy is applied based on
information set by the application.



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-4
Scenario: Developing an XDS Policy
This procedure will show how to create a security policy that limiting users from
viewing other users prospects. In some sales environments, sales people closely
guard their prospect information, and they do not want other sales people to view
their prospects data.
A prospect is stored in the smmBusRelTable. The employee who is responsible
for the prospect is stored in the MainContactWorker field. An employee is
connected to the current user through the DirPerson and DirPersonUser tables.
There are two stages in creating the XDS policy - create the policy query and
create the security policy.
Procedure: Creating a Policy Query
The steps to create the policy query are as follows:
1. In the AOT, create a new query, rename it to HcmWorkerUser.
2. From a second AOT, locate the table Data Dictionary > Tables >
HcmWorker.
3. Drag the table HcmWorker to the Data Souces node of the query.
4. In the property sheet of the Fields.node of the HcmWorker_1 data
source, set the Dynamic property to Yes.
5. From the second AOT, locate the table Data Dictionary > Tables >
DirPerson.
6. Drag the table DirPerson to the Data Sources node of the
HcmWorker_1 data source.
7. In the property sheet for the DirPerson_1 data source, set the
Relations property to Yes.
8. In the property sheet for the Fields node of the DirPerson_1 data
source, set the Dynamic property to Yes.
9. From the second AOT, drag the table DirPersonUser to the Data
Sources node of the DirPerson_1 data source.
10. In the property sheet for the DirPersonUser_1 data source, set the
Relations property to Yes.
11. In the property sheet for the Fields node of the DirPersonUser_1
data source, set the Dynamic property to Yes.



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Chapter 6: Security for Developers
6-5
12. Right-click the Ranges node of the DirPersonUser_1 data source,
and select New Range.
13. In the property sheet for the new range, set the Field property to
User, and the Value property to (currentUserId()).
14. Save your changes to the query.
FIGURE 6.3 POLICY QUERY
Procedure: Creating a Security Policy
Follow these steps to create the security policy:
1. In the AOT, expand the Security node.
2. Right-click the Policies node and select New Security Policy.
3. In the property sheet for the security policy, set the Name property to
SmmBusRelUser, set the Label property to Limit Prospects by
User, set the Primary Table property to HcmWorker, set the
Query property to HcmWorkerUser, set the ContextType property
to RoleName, set the RoleName property to
TradeSalesRepresentative, and set the Enabled property to Yes.
4. Expand the SmmBusRelUser security policy.
5. Right-click the Constrained Tables node and select New > Add
table by relation.
6. In the property sheet for the new constrained table, set the Table
property to smmBusRelTable, set the TableRelation property to
MainContactWorker.
7. Save your changes to the policy.



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-6
Procedure: Testing a Security Policy
Use the following steps to test the security policy.
1. Log on to Microsoft Dynamics AX as Nancy. To do this, right-click
the short-cut, while holding the Shift key down, and select Run as
Different User.
2. Enter Nancy as the user and enter the password Pa$$w0rd.
3. Open Sales and Marketing > Prospects > All prospects.
4. Only prospects with Nancy set as the sales rep are displayed.
Code Access Security
Microsoft Dynamics AX Code Access Security is used by developers to protect
Secured APIs from being invoked by un-trusted code (code that does not
originate from the AOT). Code access security does this by verifying the
following:
The code asserted the appropriate permission on the call stack to use
the secured class.
The assert (the request to use the secured class) is executed in trusted
code and saved in the AOT.
The assert is executed on the same tier as the secured class.
Code Access Security covers the use of secured classes on the server tier only.
You do not need to modify or mitigate client-only invocations of secured classes.
Code Access Security must be implemented by the secured class owner and all
consumers of the secured class. The owner secures the secured class by
implementing a specific type of permission class and calling the demand()
method on that class. Each class consumer must explicitly request permission to
invoke a secured class by calling the assert() method on the permission class.
Application code will break unless both of these steps are completed.
NOTE: Code Access Security does not guarantee the validity of any data or
parameters passed to the secured class. Data validation is still the responsibility
of the consumer.
There are six groups of protected standard classes in Microsoft Dynamics AX
Code Access Security:
Direct SQL
Run-time compilation and execution of X++
Data-controlled execution of X++



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Chapter 6: Security for Developers
6-7
File handling
Win32 Interop
Windows API
Example: Consuming a Secured Class
This example shows how to consume the TextBuffer class. The code first creates
a new FileIOPermission object, passing the filename parameter, and then calls
the assert() method.
xserver void MyServerFunction()
{
// Declare the CAS Permission object.
FileIOPermission fileIOPermission;
TextBuffer txtb = new TextBuffer();
Filename filename ="c:\\temp\\myfile.txt";
// Assert that it is okay to read and write files and
// Clipboard because the content is coming from a
static file name.
fileIOPermission = new FileIOPermission(filename,
'rw');
fileIOPermission.assert();
// From file will demand CAS permission (read)
txtb.fromFile(filename); // Read text from file
// To clipboard will demand CAS permission (write)
txtb.toClipboard(); // Copy it to the clipboard
// To file will demand CAS permission (write)
txtb.toFile(filename); // Write text to file
}



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-8
Example: Direct SQL
When direct SQL is used through the Connection and Statement classes, it is
subject to SQL injection threats. Note that record-level security and field-level
security are not enforced on the Statement class.
static void getCustomersDirectSQL(Args _args)
{
Connection userConnection;
Statement stmt;
str sqlString;
;
userConnection = new Connection();
stmt = userConnection.createStatement();
sqlString = 'select * from custTable';

new SqlStatementExecutePermission(sqlString).assert();
stmt.executeQuery(sqlString);
CodeAccessPermission::revertAssert();
}
Display Method Authorization
A display or edit method is used to display data from another table or a
calculated value. In theory, a display method can expose any data from any table.
If a display method returns data from another table (or another row in the same
table), it poses a threat.
If a display method returns data from the same row but from another column, it
also poses a threat. For example, a user might not be allowed to view another
person's monthly salary, but could run a query to ask for the annual salary
(calculated value).
Example: Display Method Authorization
The following example is from the CustCollectionLetterJour table. This method
validates both field access and record level security.
//BP Deviation Documented
display
Addressing collectionAddress()
{
CustTable custTable;
;


Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Chapter 6: Security for Developers
6-9
if (!hasFieldAccess(tableNum(LogisticsPostalAddress),
fieldNum(LogisticsPostalAddress, Address),
AccessType::View))
throw error("@SYS57330");
if (CustTable::checkExist(this.AccountNum))
{
custTable.recordLevelSecurity(true);
select firstonly Party from custTable
where custTable.AccountNum == this.AccountNum;
if (!custTable)
throw error("@SYS57330");
}
return custTable.postalAddress().Address;
}
Summary
This chapter showed how to create XDS policies to secure data based on a
predefined filter, how to assert permission for a secured API and how to secure
code in display methods.


Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-10
Test Your Knowledge
Test your knowledge with the following questions.
1. How is the table that is filtered due to an XDS policy referred to?
( ) Primary
( ) Foreign
( ) Filtered
( ) Constrained
2. Which method in the ExecutePermission class tells the AOS the programmer
has investigated the possible security implications of the code that follows
the command and has assessed that it is safe?
( ) Allow
( ) Permit
( ) Assert
( ) Revert



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Chapter 6: Security for Developers
6-11
Quick Interaction: Lessons Learned
Take a moment and write down three key points you have learned from this
chapter
1.




2.




3.





Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

Development II in Microsoft Dynamics

AX 2012
6-12
Solutions
Test Your Knowledge
1. How is the table that is filtered due to an XDS policy referred to?
( ) Primary
( ) Foreign
( ) Filtered
() Constrained
2. Which method in the ExecutePermission class tells the AOS the programmer
has investigated the possible security implications of the code that follows
the command and has assessed that it is safe?
( ) Allow
( ) Permit
() Assert
( ) Revert



Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement