Extensible data security model – XDS Ax2012

Security policies enable developers and administrators to block access to subset of data rows and tables. It is similar to Where clause in select statement.

This way administrators can protect data access to unauthorised users. For instance, a payroll manager need not have access to purchase order details.

Previous version of Ax refers this concept as “Record Level Security

We shall take an example where the role has to have access only to the vendors from 4200000 till 4209999 and also the vendor account number starting with 799. Meaning the role should not have access to any other vendor accounts apart from the above mentioned.

Let us see how to implement this XDS in Ax environment. Before that let us get familiarised with new terms used in this policy.

  1.  Primary table  : This is the main table in the query on which the policy is imposed. In our case, Vendor table is the primary table where we have to define the said range.
  2. Constraint table : These tables have foreign key relation on the primary table and their contents will be secured based on range defined in primary table.  In our case, it will be Purchase table where the vendor display will be limited to the values defined in primary table.
  3. Policy query: Every XDS policy has a query where the constraints (ranges) are defined. You can nest multiple data sources in the query.
  4. Policy Context: Context type in the policy. It can be one of the following – Role Property/ Role Name/Context string.
    1. Context String : You specify a value here and this will be matched with the Context string property defined for a role.
    2. Role Name : This specifies the role for which the policy is applied.
    3. Role property : This is used in combination with ContextString to specify multiple roles context.

Now let us start our implementation:

  1. Define a query : We need a query to specify the values to be restricted for the XDS policy.


Since we are restricting certain vendor values for the role, we define them in the range.

2. Next step is create a new policy from AOT -> Security -> Policies.


3. As we already know, primary table here is Vend table. Use the query we created in step 1. Unless the policy is enabled, it will not have effect though mapped to the roles.  The operation type would be “Select”.

4. Next comes “Context Type”. we are using Role Property in order to be used by multiple roles. And the string we define as “Vendors”.

5. Now our query and policy are ready. How do we use them? Answer is create a new role and map the context string defined in the previous step to that role.


6. we are in the final step. In order to test this , make this new role as a subrole to existing role . On logging , the role will be able to see only the vendor records for the range mentioned in the query.


If the XDS policy is to be applied only for a single role, change ContextType to Role Property and the Context string with the value as Role name.

In this way, there is no need of subrole to be defined. Loggind on to the role gets the expected result.


About AnithaEswaran

Hello all, Thanks for visiting my blog. I started this blog to share my learning with Ax members . Since I am from technical background, most of my posts would be from X++. Thanks to my mentor and my colleague Romain who guided and helped me in learning many new concepts in Ax. This instilled confidence in me to handle and troubleshoot complex issues. Feedback wrt to my blog entries are most welcome …
This entry was posted in Ax Security, Ax2012, Dynamics Ax and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s