In dealing with many different companies that use Microsoft Dynamics AX ERP software, we often come across unique needs – sometimes it turns up in a process, other times via a customization, and sometimes even in managing their security.
We can most often use the role-based security that is offered in the Microsoft Dynamics AX user interface, but in some instances, this may not be enough. Sometimes we may need to segregate viewing data by specific criteria in a single table. For example, what if a company has a Human Resources team where some members manage Hourly staff data and others manage Salary staff data and neither should have access to their non-assigned areas. What should we use to manage this scenario?
This is where Extensible Data Security (XDS) framework comes in. As per Microsoft, XDS ‘enables developers and administrators to secure data in shared tables such that users have access to only the part of the table that is allowed by the enforced policy.’ XDS can also be used alongside role-based security for a comprehensive security offering.
Architecture of XDS
The XDS model requires some introduction due to the differences in the framework to that of the role-based security that most of us are familiar with.
A constrained table is the table used in a given policy from which the data is filtered based on the policy query.
Example: A security policy that secures all employment related information in tables like HcmEmployment, HcmEmploymentBonus. These are the constrained tables and are always linked to the primary table of the policy.
A primary table is setup to secure the data of the constrained table.
Example: To secure all payroll information based on legal entity the HcmWorker table must act as the primary table.
A policy query is used to secure the constrained tables specified in a given XDS policy. This query will return data from a primary table that is then used to secure the contents of the constrained table.
Context property is very important to the setup of XDS. If the context is not set, then the policy, even if enabled, is not enforced. It can be setup in two ways: role contexts and application contexts.
A role context enables policy application based on the role or roles to which the user has been assigned. An application context enables policy application based on information set by the application.
Now that you are familiar with these key Microsoft Dynamics AX XDS security concepts, let’s look at how to put these tools to use.
To implement XDS the following steps must be followed:
- Construct the query on the primary table
- Create the security policy
- Add the constrained tables and views at policy
- Set the context
- Enable the policy
Here is an example of an AX built-in Security Policy property table utilized for restriction of the DirPartyTable by specific Address Book setting:
Maximizing performance through the use of XDS constructs
Utilizing XDS security often means that sophisticated querying of data is required to get to desired result sets. This can affect the performance of the system and cause concern for end users.
To lessen this negative effect, XDS constructs are used. XDS constructs are temporary tables which are populated once for every client session to hold static data – like legal entities or departments for the logged-on user that are most frequently referenced. This static data can be used in subsequent calls to reduce performance issues.
To create constructs, the XDS() table method is used to create a temporary table as an extensible data security construct. The developer can write code in this XDS() method to populate the temporary table.
This newly created temporary table is used with the policy query to avoid additional joins which will provide overall improved performance with the XDS implementation.
Some additional XDS implementation tips
Here are few more tips in implementing the XDS framework in your environment:
- Although the XDS tool is a smart way to control data security needs globally to the server, it should NOT be used to secure all tables of a module in the system. The result will incur decreased AX performance. Only set XDS on the tables you want to defend.
- Limit/minimize the use of joins in your policy query when it is setup with policies to avoid performance issues.
- Be sure to make use of the XDS constructs approach with XDS() method to avoid additional query joins for each user session.
- XDS policies can be organized by applying (1) multiple security roles (2) on the basis of an application context that is secured by code (3) with metadata in the case of queries.
- Policies can be applied to any query statement like Select, Insert, Update, Delete , or All operations (Select, Insert, Update and Delete)
XDS framework is a valuable component in the AX security model. It provides the ability to further lockdown sensitive corporate data in an increasingly customized manner to assist companies in providing information to only those that need it.
Technical Solutions Consultant
Rakesh is a developer and solution architect who assists companies in the extension of Microsoft Dynamics to meet their unique needs. Rakesh has built solutions for a variety of disciplines including Manufacturing, Supply Chain, Warehouse Management, Business Intelligence and more.