The Extensible Data Security (XDS) framework is a feature in D365FO and AX 2012 that allows users to supplement role based security and allow access to tables to be restricted by a policy. This feature was an evolution of the record-level security that existed in previous versions of Dynamics AX.
In simple terms, XDS is placing a WHERE (or ON) statement on any SQL SELECT, UPDATE, DELETE, or INSERT statement done to a table based on parameters from another related table.
Data Security Policy Concepts
Before we jump into how the functionality works we need to have an overview of some of the concepts and terms. In the below terms I’m going to use the example of wanting to secure the SalesOrder table based on the customer group.
- Constrained table – is the table(s) given a security policy from which data is filtered or secured, based on the associated policy query. In the above example, the SalesOrder table would be the constrained table.
- Primary table – is used to secure the content of the related constrained table. In the above example, the CustTable would be the primary table. The primary table must have an explicit relationship to the constrained table.
- Policy query – the query used to secure the constrained table contents via the primary table contents
- Context – the piece of information that controls the circumstances that a given policy is applicable. Contexts have two categories:
- Role Context – enables a policy based on the role(s) the user is assigned
- Application Context – enables a policy based on information set by the application
Developing an Extensible Data Security Policy
Before you begin developing XDS policies there are a couple things understand/keep in mind:
- Understand the scenario requirement/use case of why you are using XDS
- Identify the constrained and primary tables and analyze the relationships between them
- Analyze the data access patterns, table size/record counts, and existing indexes of the constrained and primary tables
Demo Scenario
If we take the scenario that we want to limit the customers a particular user sees based on a specific customer group, how would we set that up?
- The first thing to do is to determine your Constraint and Primary tables, in this case the CustTable table is our constraint table and the CustGroup table is our primary table.
- Next we create the policy query around our CustGroup, we want this query to return the results that we want to restrict the constraint table with
- Create a new Query, set the data source of the query to the primary table and then perform any filtering or other joins that need to be done for this query to return the results you want to filter by
- In our case we are limiting the user to only be able to see customers that have a CustGroup of ’10’ and Name of ‘Major Customers’
- Now we can create our Security Policy, we set the following parameters
- Constrained Table to Yes
- Primary Table to CustGroup
- Query to the name of the query we created in step 2
- If we want this to be applied to a specific role we can set this in the Role Name field, if you leave this blank it gets applied across all roles in your environment
- We then add a constrained table to the policy, in our case CustTable and set the following parameters
- Name field is the constrained table, CustTable
- Table Relation is the primary table, CustGroup
- Now if we build the solution and do a database sync of our project our XDS policy becomes live, to show what this does I did a before and after using a user assigned the FpTestRole to show the affect of the XDS policy
User access without XDS policy applied
User access after applying XDS policy
Now one question I had is, how do you apply an XDS policy against a group of roles? Well this is where the Context Type and Context String parameter on the policy comes into play. The Context Type parameter determines how the Context String parameter is handled. The Context Type has 3 different values:
- ContextString – should be set if you want to change the value of the Context String parameter via X++ code (via the XDS::SetContext method)
- RoleName – should be set if you want this policy to be assigned to a single role, this has the same effect as setting the Role Name field
- RoleProperty – allows for applying the policy to multiple roles via the Context String value, if a role has the same Context String then that role will have the XDS policy applied
If we set the Context Type to RoleProperty, then any role with a context string of the value we input in the Context String parameter will be assigned the XDS policy. So if we set the Context String value as CustGroup_XDSPolicy,
and then we set the same Context String value on a role, any user assigned that role will have the XDS policy applied to them.
Ensuring Efficient XDS Policies
Using XDS within D365FO will have an impact on the performance of queries on a table, the goal is to minimize this impact. There a couple things to keep in mind:
- Follow standard best practices of developing SQL queries (using indexes on join conditions, correct primary keys, etc)
- Simplify queries as much as possible, don’t have unnecessary joins
How to Debug/Troubleshoot Issues
If while using XDS you come across an instance where a user has more or less rows from a constrained table than you think they should you will have to try and debug the XDS policy. There are two ways of doing that:
- Execute a snippet of X++ code to see the SQL statement generated for a particular XDS policy (an example of this can be found in the white paper resource link below)
- Run a SELECT statement against the ModelSecPolRuntimeEx table to see the human readable query stored for this XDS policy
- For example, if we look for the CustomerGroupPolicy from the example above in the table the ModeledQueryDebugInfo column shows the SQL query
Another issue that you may see is a performance impact once XDS policies have been applied. In this case you will need to review the simplicity of your queries, the indexes on your tables, the proper joins are being used, and take into account the number of rows within each table you are using.
Conclusion
I hope this gave an overview on how to use the Extensible Data Security framework to extend your role based security to allow for fine grained control of user access. As always, feel free to reach out with any questions.
Hi Alex,
Would it be possible to exclude a from from it’s underlying security policy? To be specific, we need to apply different warehouse security policies on Transfer Order form as the “from warehouse” and “to warehouse” have different business rules and should provide different list of warehouses to the user to choose from.
Azad,
You should be able to do this, the idea would be you have to designate a constrained table and policy table. In your case the ‘business rules’ for a user would be your policy (not sure what these entail) but then your constrained table would be your user warehouses.
So users would be assigned access to all warehouses and then XDS would limit which warehouses they could actually see/interact with.
Feel free to reach out if you have any further questions!
Thanks a bunch Alex.
how can I setup the framework to deploy my XDS
Mnoia,
The blog post shows how to set this up in the AOT, the XDS framework is enabled by default in all AX/D365FO environments. The end user just has to set up if they want to implement any XDS policies and then set them up in the AOT.
Hi Alex,
Thanks for a very nice description of the XDS framework!
I have a scenario where I need to restrict the ability to edit certain records. My scenario is very similar to your example, only I don’t want to filter the restricted records out. I only what to restrict if a user can edit the records.
In your scenario that would correspond to not allowing the users to edit the sales orders with CustGroup 10, but they can still view those orders.
I see a property “Operation” on the Policy in your example, which is set to Select. Is this were you would instead set Operation = Update?
Mette,
Yes, if you wanted to change the action that XDS should be applied on you can do it from the Operation parameter. It supports Insert, Update, Create, Delete, InsertUpdateDelete, and AllOperations and these actions follow the same hierarchy as security does. For example, if you set it as Select then XDS would not be applied to Update, Create, or Delete actions for those records. So you need to be sure you are applying XDS in conjunction with security to only allow for the changes to objects you would like.
Hi Alex,
Thank you for your response. I think then, if I want users to be able to view, but not modify, then the Operation to choose would be InsertUpdateDelete.
One more question:
Say you have the policy restricting viewing of sales orders for customers with customer group 10. This policy is applied for Role1.
Another role, Role2, also has access to view Sales orders. The policy is not applied for this role, so a user with only Role2 is able to view all sales orders.
If a user has both roles, which permissons come into force? Does the restriction from the policy applied for Role1 “win” over the permissions given by Role2? In other words, can this user see sales orders for customers with customer group 10?
Mette,
You are correct, the the Operation to choose to affect Inserts, Updates, and Deletes should be the InsertUpdateDelete good catch!
If you have multiple roles assigned the user with one having XDS and one without, the most restrictive access will be granted.
Is it possible to use XDS to restrict the value returning for a particular financial dimension, except if users are using the dimension lookup in the expense management module, where we want all users to be able to see all dimension values?
KG,
If XDS is applied to a role, then the restriction will execute every time the underlying resource is accessed. And since it is done in code, there really isn’t a way to easily turn if on/off. If the users should be able to see all dimension values in one area of D365FO then they would be able to see those dimension values in another area. I will say that you can put different restrictions on the XDS, so maybe the user can see all of the dimensions but is restricted to Create/Update/Delete only certain ones.
EDIT: Trying to fix indentions, because spaces have been trunated.
We have a XDS policy that constrains table A, and there is table B added to the policy, too, as a constrained table of table A. So the policy looks something like this:
|- Policy
|—— constrainted table A
|————-|—— constrained table B (using relation R1)
Basically this works fine. But when we have a form where we use table A and join table B to it using relation R1 (same relation that has been unsed in XDS), the XDS framework will add the securing query to table A (which is good), but in addition will also add table A to table B (as an additional join, due to the XDS policy) and then also add the XDS query to that additionally joined query. So we end up with a query like this:
NON-XDS users:
|- Table A
|——|—— Table B (inner join, relation R1)
XDS users:
|- Table A
|—–|— XDS-Query added to first table A
|—–|—Table B (inner join, relation R1)
|————-|— Table A (added to table B
|———————-|— XDS-Query added to second table A
This is obviously not optimal. I think the optimal query would be this:
|- Table A
|—–|— XDS-Query added to first table A
|—–|—Table B (inner join, relation R1)
Is there a way to tell XDS that it should only apply itself to table A in a form, and not being applied to table B in order to improve the performance?
Mark,
How the SQL is generated for all AOT objects is abstracted away from the end user, I don’t know of any way to modify how it is created. The only option I could think of trying would be to create a view of Table A and the join to Table B then create another XDS policy using this view as the table parameter. I have not tested to see if this will generate different SQL but I think treating the query as a singular object (as a SQL view) might help.
Hi Alex,
thank you for this great post.
Hi Alex,
Great post !
How would it work if instead of the user only viewing CustGroup 10 they want to view all except CustGroup 10?
O Lanz,
Yes you absolutely can, we just have to change the query value. So if we have a list of customers like this:
And we want to show all customers that do not have a CustGroup of 10, we change the query to be:
And now if we go back to Customers we can see all customers except those with a CustGroup of 10:
You actually can use any formats that you use in QueryBuildDataSource logic in that Value parameter.
More information can be found here: https://community.dynamics.com/ax/b/axdaily/posts/and-33-operators-in-query-ranges
Fantastic, thank you so much Alex !
What are the oData (restAPI) service end points to create the security policies?
Hello,
There isn’t an OData endpoint to hit to create/modify XDS policies, XDS policies must be created in code via Visual Studio.
Hello,
My requirement is to show the data on budget analysis form ( Navigation: Budgeting >>inquiry and reports>> budget control>> budget analysis) according to current user.
Saiyada,
I think your requirement might be easier to achieve through extending X++ code on the form load compared to XDS.
Hi,
While getting the SecurityRoles using the odata endpoint, this is the sample example of a SecurityRole returned by the API:
{
“@odata.etag”: “W/\”JzEsMjY1Jw==\””,
“SecurityRoleIdentifier”: “VENDVENDORCONTACTEXTERNALADMIN”,
“ContextString”: “PolicyForVendorRoles”,
“AccessToSensitiveData”: false,
“Description”: “Maintains vendor contact persons and vendor user requests”,
“SecurityRoleName”: “Vendor admin (external)”,
“UserLicenseType”: “Activity”
}
In this, what is the meaning of “ContextString” and from where would I get the List of these ContextString using the odata. Is the meaning of “ContextString” in the data received same as the context string for XDS?
Hello,
The ContextString value on a role is used by XDS to apply an XDS policy across multiple roles easily. If your XDS policy has the ‘Context String’ value set on it then any role with that same context string value will have the XDS policy applied.
Hello Alex,
I need to enable and disable the field based on the user role. i.e
Only for the Project Manager role field on a Form will we enable and for the rest, it will be disabled in D365 FO
Can you please guide me on that?
Awaiting your response.
Arun,
In this case you have a couple different options, but in each case I would recommend utilizing the Deny access type to ensure access is not accidentally given to users you do not want to. I would actually suggest performing this request at the user level instead of the role level as I believe it will be a simpler setup. As otherwise you would have to go to every other role (other than Project Manager) and Deny access to the field. Instead we could:
– Create a role that Deny’s access to whatever field you want to block on your created role
– Then assign this created role to each user that should not have access (you could automate this slightly by using OData and the SecurityUserRole data entity)
Your other option if you wanted to do this at the role level would be to be to create a privilege that Denied access to this field and then assign it to each role in your System except Project Manager
Hi Alex,
Is it possible to make form level controls enable and disable using XDS.
Neetha,
I would not recommend XDS in this case as XDS was not designed to modify security in this way, XDS was designed to limit which records a user could see not what objects on a form a user could interact with.
Hi Alex, I had a requirement. Based on a parameter value in one table. I have to make some fields enable and disable for some users. Is it possible to do through xds.
Neetha,
I would not recommend XDS in this case as this is really not what XDS was designed for. In your case I think custom development would be required to enabled/disable a field based on a value from another table.
Hi Alex, does commands like doInsert, doUpdate, bypass the XDS policy and perform the insert and update operations?
Armanto,
I have not tested if the doInsert/doUpdate methods would bypass XDS but there are plenty of other ways to bypass/disable XDS:
https://ievgensaxblog.wordpress.com/2016/06/14/queryinsert_recordset-ignores-xds-policy/
https://community.dynamics.com/ax/f/microsoft-dynamics-ax-forum/92711/ax2012-xds-disable-security-policy/179043
https://community.dynamics.com/ax/b/shabibax/posts/bypass-or-disable-extensible-data-security-xds-policy-on-runtime-ax2012-and-dynamics-365-for-finance-and-operations
Hi Alex, Thanks for your prompt reply :), In one of our the scenario the XDS is being bypassed by a doInsert method which is a standard Private method in MS class. Don’t know why it is doing like that.. for normal insert or update scenario XDS is working fine. Anyways, Thanks again for the reply, Alex. 🙂
Armanto,
It looks like the doInsert method is used specifically when you want to bypass the normal Insert method. An excerpt from the documentation: https://docs.microsoft.com/en-us/dynamicsax-2012/developer/doinsert-table-method
My guess would be that by performing the doInsert method instead of the Insert method that it bypasses all checks that would normally be performed.
Hi Alex, I hope you are fine and doing well.
I have implemented warehouse level security using XDS. Its working fine for purchase, sales, movement etc. but I’m facing issue while perform Transfer Orders (Inventory Management > Transfer Orders). Transfer Orders form use InventLocation lookup on From Warehouse and To warehouse, as the warehouses are restricted so it won’t show other warehouses in To Warehouse because we have to move inventory to different warehouses. How can I exclude Transfer Orders form from this security ? or is there any way to void InventLocation restriction on this form?
Hello,
When you apply XDS, you are basically putting a WHERE statement clause on SQL events that occur to that datasource. It doesn’t matter which form the request comes from, all requests to that datasource will be constrained by the XDS policy. You may be able to override XDS on the Transfer Orders form by utilizing one of these methods:
https://community.dynamics.com/ax/b/shabibax/posts/bypass-or-disable-extensible-data-security-xds-policy-on-runtime-ax2012-and-dynamics-365-for-finance-and-operations
Thank you so much Alex.
unchecked(uncheck::XDS) worked but only for lookup. when I select a warehouse from lookup it shows error
“The value ‘Warehouse2’ in field ‘To warehouse’ is not found in the related table ‘Warehouses’.”
because it again check warehouse at the time of selection.
How can I deal with it ?
Thanks & Regards,
Hello,
I am not sure what other logic is happening on that form when you select a warehouse, if you are able to see the warehouses then you are overriding XDS for that particular SQL query but there may be other queries from this datasource that may still be restricted by XDS. You would have to ensure that all queries needed to perform the business process are unrestricted.
Hi Alex, I have a problem when compiling, when assigning the CONSTRAINET TABLE property in Yes of the policy, it gives me error: System table not allowed when the constrained property is Yes.
It is worth mentioning that my table has no relation
Thank you.
Jimmy,
I would guess that there is some setup issue with your XDS policy, you need to ensure that the Primary Table parameter and the Constrained Tables on your policy are set like the example below.
Also there should be some relationship between your primary and constrained tables otherwise there would be no way to apply XDS between them.
Thanks for rounding up. This constrained table option can be applied to a system table, that is, an XDS can be applied to a system table.
Hi Alex.
My XSD works perfectly, the XDS was applied to the UserIinfo system table but not directly, in code I made a join to a new table created (which has the XDS assigned), but in the grid the search no longer works nor the filters of the headers of the grid, any ideas?
Jimmy,
I’m going to guess that you mean that the grid filter isn’t filtering any data as you didn’t specify what the actual issue is. You would have to look at the grid filtering logic on whatever form you are currently on and possibly override it to correctly implement your XDS logic.
Here’s some others that have had similar issues:
https://community.dynamics.com/ax/f/microsoft-dynamics-ax-forum/369988/lookup-search-for-inventlocationid-with-xds-policy
https://community.dynamics.com/ax/f/microsoft-dynamics-ax-forum/259255/xds-policy-not-working-for-lookup
To be more specific, QuickFilter no longer works for the grid. I already saw the post but for me it is the opposite, it does not bring the data when wanting to filter. 🙁
Jimmy,
I think the steps to get this working would be the same, you would have to go into the X++ code and look to see where the filter is being applied and do an analysis on why the data is being filtered out.
Hi Alex,
Thanks for this post. A good starting point for XDS !
I have a requirement of which I’m not sure what the best way is to solve this. I have a purchaser that should be able to create purch prices/discounts (Trade agreements), but not sales. And I have a sales person where it should work just the other way around.
Thought of 3 options:
1. Code (my least favorite; do not use code if other workable options are available)
2. Roles/Duties/Privileges. Played around with this but can’t seem to get this working.
3. XDS
Using XDS I can prevent the user from creating a purch/sales trade agreement (form priceDiscAdmTable) by querying out the correct journal names. But when I go to lines (from PriceDiscAdm) I will still be able to create all prices/discounts. For sales and purch. The bottleneck here is that I need to filter on the Enum PriceType (field priceDiscAdmTrans.relation). And I can not find a way yo do this using XDS.
Can you share your thoughts on this ?
Thanks,
Gerard
Gerard,
I think you could potentially do this via security, while you could probably do this via XDS it is not the normal use case for XDS so it would be somewhat complex to set up (as you have found).
I don’t have a lot of background on what forms/datasources control the ability to create purch prices/discounts and where you are making sales. But if these two processes interact with separate datasources and/or menu items/forms this sounds like a great use case for the Deny permission. Where you would grant access to one process but deny the other.
How To Utilize the Deny Permission in Dynamics 365 for Finance & Operations
Hi Alex,
Thanks for taking the time !
With roles/duties/privileges I have another issue. I can deny access on menu-items etc., but once I’m on the form where I set the price agreements I need to restrict access to creation of records based on an Enum. I uploaded an image: https://ibb.co/4T3WJr4
As you can see I can create sales and purchase prices here based on the Enum PriceType (column relation). What I want is if I select Purchase Price, that I’m not allowed to save the record (generate a warning or whatever). But as stated, this is an Enum and not a data relation like “User is not allowed to create salesorder if customergroup = ‘XXX'”.
I find it very strange that I can’t find a any easy solution for this on google. Sounds to me as requirement that’s not that strange. I’m getting the feeling that I need to use code here. Not very complicated, but I want to avoid code if possible…
Any more thoughts you might have are appreciated !
Thanks,
Gerard
Gerard,
In this case, you would have to extend the form functionality by using X++. There is no out of the box functionality that will perform the way you are wanting.
It’s not XDS because like you said this is all being done on the same table, and you are not trying to limit a user to only being able to see/interact with certain objects that meet a criteria you are trying to say that a user should not be able to save an object with a certain value.
And its not security based because you only want to restrict access when a certain value is set.
So the only option left to perform this functionality is by extending the code on that grid column’s drop down event.
Hi Alex,
Not the answer I was hoping for ;o) But I agree with you. Thanks a lot !!
Cheers,
Gerard
Hello Alex,
We are implementing Extended Data Security(XDS) on warehouse-user level. In transfer order form we want to have from warehouse to be filtered from user-warehouse mapping table and in to warehouse no filter is required. But as XDS is enabled on InventLocation table, it is showing only filtered locations in from as well as to warehouse.
We want to implement XDS on From warehouse not for To warehouse.
Can you share your thoughts on this ?
Thanks,
Harika
Harika,
I believe this scenario would require custom X++ logic be applied as I don’t see a way to do this another way. You would have to do something like Andre’s answer on this forum post and apply that on the query that executes for the To Warehouse.
https://community.dynamics.com/ax/f/microsoft-dynamics-ax-forum/92711/ax2012-xds-disable-security-policy/179043
Another option would be to populate a temporary table with the values from the InventLocation table and use that as the datasource for the To Warehouse field.
Hello Alex,
Thank you for your update.
Is there any way we can achieve that without having to write the code everywhere? Also how can we filter the transfer orders on form with that?
Thanks,
Harika
Harika,
No, custom code would be required. The custom code would also be where you can apply any filtering you would like.
Hi Alex,
Thanks for your great article, I have a requirement here. I have 3 branches in my company and want to show stock, customers and item separately to all these 3 braches. That’s mean all these 3 branches should see thier stock, items and customers.
Shabir,
I think you could do this without XDS and just use normal legal entity separation. Each ‘branch’ in your case would be a separate legal entity and then all of those objects (stock, customers, and items) would separated by legal entity and would only be visible within that legal entity.