Security (XDS)

Data security policies
Prerequisite – Please note to work through this lab you will need to have Admin rights to the system and have basic AOT navigation skills.
Microsoft have introduced an alternative to the ‘Record level security’ used in AX 2009 which caused huge performance issues. This alternative is known as ‘XDS’ (Extensible Data Security).
The concept is extremely simple and it doesn’t take long to setup a XDS query of your own. In this blog I will start by explaining the ‘concept’ behind XDS after which I will run through a simple lab.
Note – Microsoft have have made extensive notes on this feature. Please find the links at the bottom of this page.
Concept
“XDS limits a specific Role to only see a specific set of data within an AX table”  
Above I’ve attempted to summaries in one line the primary function of XDS. In essence the XDS security policy will apply a permanent filter onto a specific table within AX. To understand this better I will work through a simple business requirement.
Company A have two manufacturing sites (Site 1 and 2) they require the Production managers (Worker Z, Worker Y and Worker X) to see specific sets of data.

Worker	Site 1	Site 2
Z	Yes
Y		Yes
X	Yes	Yes

Above we are attempting to display that the share the same AX security roles (the ability to access the same forms and preform the same tasks) however they should only be able to see the data from their respective sites.
Requirement gathering for XDS
The first step in setting up an XDS policy is simply identify the table you would like to apply a filter too, the field you are filtering on and the variants of this filer. So working through this for the scenario above you would end up with:

• Table to be filtered?                                  Production order table
• Field you would like to filter on?               Site
• Variants required?                                     1 and 2

Next we will need to identify the Primary table and the Constrained tables. These have been defined below:
Constrained table – The constrained table act as the table you desire the filter to appear upon (Note – There can be multiple constrained tables as long as the primary table and the filtered field can been seen in that constrained table).
Primary table – The primary table can typically be defined as the field used to filter the constrained table.
In order to identify which tables meet the above definitions navigate to the table you desire to filter upon and identify the appropriate table relationships. Below I have worked through the example of filtering the production order table down by site. This should help you to apply the same logic to your desired business scenario.

1. Open Production control > Common > Production orders > All Production orders.
2. Make sure you have the field site displayed to do this click View > Dimensions
3. Select site and save the changes
4. Firstly we will identify the Constrained table, right click on the field ‘Production order number’ and click ‘Personalize’ in the menu
5. Within the Personalization screen identify the table used (this can be seen in the screen shot below)
   
   
6. Next we will need to identify the primary table and field. In our case the field ‘Site’
7. Right click the field ‘Site’ and select ‘Personalize’
8. Within the Personalization screen identify the table and field used (this can be seen in the screen shot below)
   
   
9. This information has been summarised below:
   

   	Primary table	Filtered field	Applier filter	Constrained table
   XDS – Production orders – Site 1	InventDim	InventSiteID	=”1″	ProdTable
   XDS – Production orders – Site 2	InventDim	InventSiteID	=”2″	ProdTable

10. If you can create an advance query to represent your desired outcome you will also be able to create this using XDS. Also it will help you understand how the relationships work.
    

Pre-XDS setup
Prior to setting up the XDS policy you will also need to create a new Role within AX. This will generate less maintenance than applying the XDS directly to an existing security role. If you were to apply the XDS security policy directly to the production manager security role you would need to then create two production security roles and therefore maintain two production manager security roles rather than the one security role with an additional XDS role on top of that. Instead I would suggest that you create three new security roles one called ‘XDS_Site_1’, ‘XDS_Site_1_2’ and ‘XDS_Site_2’.
To do this follow these steps:

1. Open the AOT (Ctrl+D)
2. Navigate to Security > Roles
3. Right click on the ‘Roles’ node and select New Role
4. Name the roles appropriately (remember to change the name and the label)

Setting up XDS
In this next section we will run through the steps you would need to take in order to create the XDS policy.

1. The first thing you will need to do when creating an XDS policy will be to create a project within the AOT. This will help to keep your work together and simplifies the deployment of code too.
2. Open the AOT (Ctrl + D)
3. Open the projects screen (Ctrl+Shift+P)
4. Right click the ‘Shared’ folder and select New > Project
5. Select an appropriate name for the project (XDS_PRODUCTION_ORDERS_SITE_1)
6. Right click and Open the project

Now we have created a suitable work space to create our policy we will now need to build the query that we would like to run. This should mirror the query set-up in step 10 above.

1. Right click you project and click New > Query
   
   
2. I find it helpful at this point to also name the query to do right click the query and select ‘Rename’ (XDS_InventDim_SITE_1)
3. Next we need to define the primary table
4. Expand the query and right click the ‘Data source’ and select New Data Source
5. This will create a new node called ‘INVALID TABLE_#’
6. Selecting this node should bring up a properties plane on the right hand side of the development screen
7. In the properties screen first select an appropriate name and then specify the table you would liking this node should bring up a properties plane on the right hand side of the development screen
8. In the properties screen first select an appropriate name and then specify the table you would like to filter on.
   
9. We have now selected the primary table but we still need to define the ‘Range’ (Criteria) for the filter.
10. Expand the data source you created and right click on the ‘Ranges’ node and select New Range.
    
    
11. Again using the Properties screen amend the following fields:

Name	XDS_Site_1
Field	InventSiteId
Value	=”1”

1. Next select the field’s node and again in the properties amend the property ‘Dynamic’ to ‘Yes’.
   

Now we have set the query up we need to setup the XDS policy to apply the query to the constrained tables and relate to a specific AX role.

1. Right click the main project ‘XDS_Production_Orders_Site_1’ and then click New > Security > Security Policy
   
   
2. Select the ‘SecurityPolicy1’ node and modify the properties to be:

Property	Value
Name	XDS_Production_Site_1
Label	Restrict Production orders to site 1
PrimaryTable	InventDim
Query	XDS_InventDim_Site_1
PolicyGroup	Production
ConstrainedTable	Yes
Enabled	Yes
Operation	All operations
Context Type	RoleName
Role Name	XDS_Site_1 (setup in step 14)

1. Next we need to define the constrained table. Expand the security policy node to reveal the ‘Constrained table’ node right click this node and select New > Add table by relation
2. Within the properties set the following values:

Property	Value
Constrained Table	Yes
Table	Prodtable
Table Relation	InventDim

1. We have now setup out XDS policy. Remember to COMPLIE THE WHOLE PROJECT! To do this right click the project and click ‘Compile’ this should then remove the red line next the project. (If it doesn’t try closing the window and navigating to it again)

Now we have successfully created the XDS security policy we will need to test that it works to do this you will need a test user account (Don’t apply it to your user as you will then not be able to change yourself back to admin!)

1. Open System administration > Common > Users > Users
2. Select the test user you would like to apply the policy too
3. Select Assign roles and select the roles Production manager and XDS_Site_1
   
   
4. Close your AX application and open again as a different user to do this hold down ‘Shift’ and right click the AX application and select ‘Run as different user’
5. Navigate to the appropriate area and test that the filter has been applied.

Summary
To recap on out original requirements we had 3 users Z, Y and X with the following requirements:

Worker	Site 1	Site 2
Z	Yes
Y		Yes
X	Yes	Yes

To achieve the requirements of Z and Y you would need to create two policies as we did in the example above. However, it should be noted that you CANNOT STACK XDS policies by this I mean if you wanted user X to see sites 1 and 2 but not site 3 you should not apply both two policies created above as they will cancel each other out and you will end up with no data displaying you would need to create a new policy with a query such as =”1”,”2” in a new XDS security role.
The final outcome should be as follows:

	AX ROLES
	Production manager	XDS_Site_1	XDS_Site_2	XDS_Site_3
Worker Z	Yes	Yes
Worker Y	Yes		Yes
Worker X	Yes			Yes