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:

• Only allowing a user to see records they’ve created
• Only allowing a salesperson to see customers within a particular territory
• Restricting a user to only see sales order from a particular customer or customer group

In this blog, we discuss:

• The basic concepts of XDS
• Guidelines for developing an XDS policy
• An example of how to create and apply an XDS policy
• Applying an XDS policy to multiple roles
• Troubleshooting XDS policy issues
• How Fastpath can help with D365FO security

XDS Concepts

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.

• Constrained Table – A constrained table is the table (or tables) whose data will be restricted (secured) based on the policy from an associated table. In this example, the SalesOrder table is the constrained table.
• Primary Table – The primary table is the table used to restrict the data of the associated constrained table. In this example, CustTable is the primary table. The primary table must have a direct relationship to the constrained table.
• Policy Query – The policy query is the SQL query that secures the constrained table data as specified using a given XDS policy found in the primary table and will return only the information based on the restrictions set in the primary table.
• Context – The context controls how the policy is applied. The two types of contexts are Role Context and Application Context.
  • Role Context – Role context applies the policy based on the roles assigned to the user.
  • Application Context – Application context applies the policy based on information set by the application.

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)

Guidelines for Developing an XDS Policy

Because using XDS can affect application performance, Microsoft has several recommended guidelines for developing an XDS policy:

• Consider the reasons why we are using XDS. Identify the requirements and use cases to justify using XDS.
• Identify the set of constrained tables and understand the relationships they have with the primary table.
• Analyze the data access patterns, table sizes, and existing indexes of the constrained and primary tables.
• As a recommended practice, simplify queries as much as possible and avoid unnecessary joins.

Example: Create and apply 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.

• Create a new query and set the data source of the query to the primary table. Perform any filtering or joins required for the query to return the desired results. In our example, we will limit the user to only see customers with a CustGroup value of' 10' and Name with a value of 'Major Customers' (Figure 1).

Figure 1 – Set the query filters, CustGroup and Name in CustomerGroupQuery

3. Next, to create the Security Policy, we set the following parameters:

• Set Constrained Table to 'Yes'.
• Set Primary Table to 'CustGroup'.
• Set the Query to the name of the query we created in step 2 (in this example, 'CustomerGroupQuery').
• To apply this policy to a specific role, we set this in the Role Name field. In this example, we use the role named 'FpTestRole' (Figure 2). If we leave this field blank, the policy will be applied across all roles in the environment.

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:

• Set the Name field to the constrained table, 'CustTable'.
• Set Table Relation field to the primary table, 'CustGroup'.

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

Applying an XDS policy to multiple roles

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.

• ContextString – Set the Content Type to ‘ContextString’ to change the value of the Context String parameter via X++ code (via the XDS::SetContext method).
• RoleName – Use 'RoleName' to assign the policy to a single role. This has the same effect as setting the Role Name field.
• RoleProperty – 'RoleProperty' will apply the policy to multiple roles via the Context String value. If a role has the same Context String value, then that role will have the XDS policy applied.

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

Troubleshooting XDS policy issues

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:

• Execute a snippet of X++ code to view the SQL statement generated for a particular XDS policy. An example can be found here. 
• 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 (Figure 8).

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.

How Fastpath Can Help

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.