Sometimes, I do get questions about the combination of eXtensible Data Security and data entities. Some people say it is not possible. When reading the Microsoft documentation, it is stated that it is not supported. Surprisingly, it actually does work, but you have to know how…
It is interesting to read the documentation where Microsoft stated that “Data entities do not support the Extensible Data Security (XDS) Concepts”. Initially, you might think it is not working. However, when something is not supported, it doesn’t mean that it is not working. When a company had implemented e.g. Dynamics AX 2012, then newer versions of Office, Windows, Visual Studio and so on were released. In many cases, the newer versions were initially not supported. The support usually came a bit later. Sometimes a hotfix was required to be compatible; sometimes a new cumulative update of Dynamics AX was adding the alignment. In other cases, it was just working, but a statement came later. The reason is that it should be tested carefully before Microsoft can take responsibility. So, it is also a legal statement. If you are using unsupported software or combinations, Microsoft cannot be held liable for not correctly functioning systems. In addition, when there is no support, it might also work now, but in a future release it might be deprecated.
Extensible Data Security and data entities
Now back to the topic. When I read it is not supported, I had multiple thoughts. Questions like: Are there any pitfalls? Are some parts not working? Are there performance issues? Is it not tested by Microsoft? Is it about out of the box entities which are not aligned with data entities? Or even: Does Microsoft has a lack of knowledge on their own framework? All wild thoughts. Probably I should ask Microsoft about the reason. However, I’m always stubborn and trying out things myself. Continue reading what I have done to get it working and learn from my test cases.
Is a data entity a view?
When you create an XDS policy on a table which is used on a form, like restricting sales orders per region, then you would have the SalesTable and SalesLine tables most likely part of the security policy. If you only have these tables in the security policy, then indeed the data entities will not be restricted. Now here comes the (public) secret…
When you create a data entity, during the synchronization with the database, also a view is created. In fact, you can access the entity as a view. I will make a bold statement here that a data entity is in fact a view. At least from the perspective of SQL calls. But note that a view is not automatically a data entity. There is more under the cover when you create data entities.
The target tables are accessed by the data management framework using the data entity view. When a view is used on a form or in coding, the view is interpreted by the kernel as separate table. For this reason, the data is not constrained if you didn’t add the view also on the security policy. So, by adding the data entity view as constrained table on the security policy, it is working. I will show it below with an example.
Please note that you should test the results carefully before deploying it in a live environment.
This blog is provided as is and I’m not responsible for any side effects when you do apply it in your production environment or ISV solutions.
In the past, I had created some examples on XDS policies. One of them was related to retail channels. In the example with retail channels, you can assign retail channels as organization assignment on security roles. On the forms it is working correctly, like you can see in the screenshot below.
In this scenario, only 11 out of 38 retail stores are visible for this user. When using the option ‘Open in Excel’ or export Stores using data management, all stores were listed. So, there is a need to also constrain the data entity.
Adding the data entity as constrained table is quite simple on your own security policies. In Visual Studio, find the data entity name. Then open the security policy in a solution and add the entity. In my example, I will add the RetailStoreEntity as Constrained Expression as this is the name of the data entity used as Stores entity. The option constrained expression is used to add the view as there is no table relation defined. In the property Value, you can add a query value like: (RetailStoreEntity.RetailChannelId == RetailChannelTable.RetailChannelId). Also, make sure the Constrained property is set to Yes. Then build the solution and make sure a database synchronization is successful.
If you need to add constrained tables on security policies from the standard application or an ISV solution, you can’t extend this object type. Only Security roles and duties can be extended. In this case, you can duplicate the security policy and make changes. In this case, you have to review settings to not having duplicate security policies active on the same role. You might need to work with the properties Context type and Context string to get the correct result.
Testing and results
When you did build the solution with the data entities as constrained tables, make sure the database is synchronized before you start testing.
When now using the data management to export retail stores, the retail operations manager, will only get the stores which were assigned to him.
Also, when opening in Excel, only the records part of the permission is visible. So, adding the data entity as view is directly having effect on both data management and OData. (The Excel add-in is using the OData interface to read and write records.
As I had chosen the option to constrain all operations on the retail security policy, I did also perform tests to see if I could add or update records which were outside of the permissions. In this case, all attempts failed.
However, as the retail operations manager, I was able to see the data management projects for the retail stores, created by another user with other retail stores assigned. In general, when the processing history is available, you can still download the file with data that doesn’t belong to you. How to solve this potential security leak, I will explain in a next blog.
As summary, it is possible to use the eXtensible Data Security together with data entities. In this example, I have not tested the performance impact. Also, I have not tested this on a production environment. As of this moment it is unclear why Microsoft made the statement that data entities do not support XDS. A valid reason could be related to not having an extension story on security policies or not having included data entity views on standard security policies. It might also be related to the fact that the combination was not tested by Microsoft.
If you intend to use the information in this blog for your own scenarios, make sure, you check and test all possible scenarios carefully. Also make sure you will read my next post how to secure the data management projects.
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!