Microsoft introduced the Extensible Data Security (XDS) Framework as part of AX 2012, and this feature has been enhanced in D365FO. XDS is Microsoft’s answer to ‘record level security’ in AX and D365FO and is a supplement to role-based security in these applications. XDS is a programmatic way to set security policies which limit what data a user has access to within a table.
Examples of when XDS can be used:
In this blog, we discuss:
XDS works by setting parameters in one table to restrict the data returned from another table by placing a WHERE or ON statement in an SQL SELECT, UPDATE, DELETE, or INSERT statement.
Some key terms and concepts of XDS are explained below. For the example in this section, we will apply these terms to secure the SalesOrder table using parameters defined in the customer group table, CustTable.
Policies and policy components are found under Security > Security Policies in the Application Object Tree (AOT).
Security > Security Policies in the Application Object Tree (AOT)
Because using XDS can affect application performance, Microsoft has several recommended guidelines for developing an XDS policy:
In this example, assume we want to restrict users to only see specific customers, found in the CustTable table, based on a specific customer group, the CustGroup table.
1. First, we want to determine the Constraint and Primary tables. In this example, the CustTable table is the constraint table, and the CustGroup table is the primary table.
2. Now create a policy query around the CustGroup. This query should return only those results allowed by the policy that is used to restrict the constraint table.
Figure 1 – Set the query filters, CustGroup and Name in CustomerGroupQuery
3. Next, to create the Security Policy, we set the following parameters:
Figure 2 – Set the query parameters
4. Now add a constrained table to the policy, in our example it is CustTable (Figure 3), and set the following parameters:
Figure 3 – Add the constrained table and Table Relation to the security policy
5. Next, build the solution and perform a database sync of the project so the XDS policy becomes live. Figure 4 shows a before and Figure 5 shows an after view showing the effect of the XDS policy on a user assigned to the role named ‘FpTestRole’.
Figure 4 – User access before XDS policy is applied
Figure 5 – User access after XDS policy is applied
To apply an XDS policy to multiple roles, use the Context Type and Context String parameters on the policy. The Content Type parameter determines how the Context String parameter is handled. The Content Type has three possible values: ContextString, RoleName, RoleProperty.
If the Context Type is set to RoleProperty, then any role with a Context String of the value we input in the Context String parameter will be assigned that XDS policy. As shown in Figure 6, for the XDS policy named CustomerGroupPolicy, if we set the Context String value to 'CustGroup_XDSPolicy'…
Figure 6 – Set the Context Type to RoleProperty to apply the security policy to multiple roles
…and then set the same Context String value on a role (in this example, FpTestRole), then any user assigned that role would have the XDS policy applied to them (Figure 7).
Figure 7 – Set the Context String for a role to match the Context String of the policy to apply an XDS policy to that role
If an XDS policy returns more or fewer rows from a constrained table, it is necessary to debug the XDS policy. Two methods for debugging are:
Figure 8 – The ModeledQueryDebugInfo column displays the SQL query for this XDS security policy
Another issue that you may notice is a performance impact once XDS policies are applied. In this case, you need to review the simplicity of your queries, verify the indexes on your tables, that proper joins are being used, and consider the number of rows within each table you are using.
XDS is one way to provide access security to your Microsoft Dynamics 365 Finance and Operations environment.
To help further secure you user application, Fastpath offers a suite of products for D365FO that helps identify, mitigate, and prevent unauthorized user activity:
Access Risk Monitor – Our Access Risk Monitor (ARM) helps you identify Segregation of Duties (SOD) threats and analyze who has access to critical data at a granular level. SOD tools come with pre-defined rulesets built by Fastpath's team of certified internal auditors. Using ARM, companies can perform periodic user access reviews to verify users are given the appropriate access and certify the results for audits.
Audit Trail – Audit Trail tracks user activity with minimal impact on system performance, noting critical changes to data and configuration settings, when, and by whom, including before and after values.
Identity Manager – Streamline user setup while adding approvals and audit trails into the process. Grant users elevated access for emergencies and specify start and end times for the duration of that access.
Security Designer – Create new roles or edit existing ones. Identify where conflicts currently exist vs. where they would exist if the proposed changes went into effect. Decide which model best fits your needs with the lowest possible risk level and then implement the changes.
Risk Quantification – Quantify the financial exposure of Segregation of Duties conflicts in your ERP environment and assign a value to those risks. Delivering this critical information to auditors allows them to focus on the key areas with the greatest monetary impact on the organization.
Manage User Licenses – See how each user, role, duty, and privilege are requiring a particular license type and get insight into how security changes are affecting your licensing requirements.
To learn more about how to make sure your D365FO security is as tight as possible, get the eBook, 30 tips and tricks for D365FO Security . Start improving security right away with these tips on improving security via setup, process change options, mitigation tools, and principles for improved security going forward.