This article is written by Ahmed Mohamed Rafik Moustafa, the author of Microsoft Dynamics AX 2012 R3 Security. In any corporation, some users are restricted to work with specific sensitive data because of its confidentiality or company policies, and this type of data access authorization can be managed using extensible data security (XDS). XDS is the evolution of the record-level security (RLS) that was available in the previous versions of Microsoft Dynamics AX. Also, Microsoft keeps the RLS in version AX 2012, so you can refer to it at any time.

The topics that will be covered in this article are as follows:

• The main concepts of XDS policies
• Designing and developing the XDS policy
• Creating the XDS policy
• Adding constrained tables and views
• Setting the XDS policy context
• Debugging the XDS policy

(For more resources related to this topic, see here.)

The main concepts of XDS policies

When developing an XDS policy, you need to be familiar with the following concepts:

After understanding the previous concepts of XDS, we move on to the four steps to develop an XDS policy, and they are as follows:

1. Design the query on the primary tables.
2. Develop the policy.
3. Add the constrained tables and views.
4. Set up the policy context.

Designing and developing the XDS policy

XDS is a powerful mechanism that allows us to express and implement data security needs. The following steps show detailed instructions on designing and developing XDS:

1. Determine the primary table; for example, VendTable.
2. Create a query under the AOT Queries node:
   •     Use VendTable as the first data source
   •     Add other data sources as required by the vendor data model:

     

Creating the policy

Now we have to create the policy itself. Follow these steps:

1. Right-click on AOT and go to Security | Policies. Select New Security Policy.
2. Adjust the PrimaryTable property on the policy to VendTable.
3. Settle the Query property on the policy to VendProfileAccountPolicy.
4. Adjust the PolicyGroup property to Vendor Self Service.
5. Settle the ConstrainedTable property to Yes to secure the primary table using this policy.
6. Adjust the Enabled property to Yes or No, depending on whether or not you want to control the policy.
7. Settle the ContextType property to one of the following:
   •     ContextString: Adjust the property to this value if a global context is to be used with the policy. After using ContextString, it needs to be set by the application using the XDS::SetContext API.
   •     RoleName: Adjust the property to this value if the policy should be applied only if a user in a specific role needs to access the constrained tables.
   •     RoleProperty: Adjust the property to this value if the policy is to be applied only if the user is a member of any one of roles that have the ContextString property settled to the same value.

The following screenshot displays the properties:

Adding constrained tables and views

After designing the query and developing the required policy, the next step is to add the constrained tables and views that contain the data by using the created policy.

By following the next steps, you will be able to add constrained tables or views:

1. Right-click on the Constrained Tables node.
2. Go to New | Add table to add a constrained table; for example, the AssetBook table, as shown in the following screenshot:

   

   When adding the constrained table AssetBook, you must determine the relationship that should be used to join the primary table with the last constrained table.

3. Go to New | Add View to add a constrained view to the selected policy.

Repeat these steps for every constrained table or view that needs to be secured through this policy.

After finishing these steps, the policy will be applied for all users who are attempting to access the tables or views that are located on the constrained table's node when the Enabled property is set to Yes. Security policies are not applied to system administrators who are in the SysAdmin role.

Setting the XDS policy context

According to the requirements, the security policy needs to be adjusted to apply only to the users who were assigned to the vendor role. The following steps should be performed to make the appropriate adjustment:

1. Adjust the ContextType property on the policy node to RoleProperty.
2. Settle the ContextString property on the policy node to ForAllVendorRoles:

   

To assign this policy to all the vendor roles, the ForAllVendorRoles context should be applied to the appropriate roles:

1. Locate each role that needs to be assigned to this policy on the AOT node; for example, the VendVendor role.
2. Adjust the ContextString property on the VendVendor role to ForAllVendorRoles:

   

For more information, go to MSDN and refer to Whitepapers – Developing Extensible Data Security Policies at https://msdn.microsoft.com/en-us/library/bb629286.aspx.

Debugging XDS policies

One of the most common issues reported when a new XDS policy is deployed is that an unexpected number of rows are being returned from a given constrained table. For example, more sales orders are being returned than expected if the sales order table is being constrained by a given customer group.

XDS provides a method to debug these errors. We will go over it now.

Review the SQL queries that have been generated. The X++ select has been extended with a command that instructs the underlying data access framework to generate the SQL query without actually executing it.

The following job runs a select query on SalesTable with a generated command. It then calls the getSQLStatement() method on SalesTable and dumps the output using the info API.

static void VerifySalesQuery(Args _args)
{
SalesTable salesTable;
XDSServices xdsServices = new XDSServices();
xdsServices.setXDSContext(1, '');
//Only generate SQL statement for custGroup table
select generateonly forceLiterals CustAccount, DeliveryDate from salesTable;
//Print SQL statement to infolog
info(salesTable.getSQLStatement());
xdsServices.setXDSContext(2, '');
}

The XDS policy development framework further eases this process of doing some advanced debugging by storing the query in a human-readable form. This query and others on a given constrained table in a policy can be retrieved by using the following Transact-SQL query on the database in the development environment (AXDBDEV in this example):

SELECT [PRIMARYTABLEAOTNAME], [QUERYOBJECTAOTNAME],
[CONSTRAINEDTABLE], [MODELEDQUERYDEBUGINFO],
[CONTEXTTYPE],[CONTEXTSTRING],
[ISENABLED], [ISMODELED]
FROM [AXDBDEV].[dbo].[ModelSecPolRuntimeEx]

This SQL query generates the following output:

As you can see, the query that will join the WHERE statement of any query to the AssetBook table will be ready for debugging. Other metadata, such as LayerId, can be debugged if needed.

When multiple policies apply to a table, the results of the policies are linked together with AND operators.

Summary

By the end of this article, you are able to secure your sensitive data using the XDS features. We learned how to design and develop XDS policies, constrained tables and views, primary tables, policy queries, set the security context, run SQL queries and learned how to debug XDS policies.

Resources for Article:

Further resources on this subject:

• Understanding and Creating Simple SSRS Reports [article]
• Working with Data in Forms [article]
• Learning MS Dynamics AX 2012 Programming [article]