Using Extensible Data Security (XDS) in Dynamics 365 for Finance and Operations

In this article, we show how XDS will react in certain scenarios and how you could approach more complex business use cases for XDS.

Testing Setup

For each scenario below, the setup required for each instance will be listed. For all tests, I did a full compile as well as a database sync of my test project, I then logged out and logged back into D365FO as my test user.

Scenario #1 – How to Apply Multiple XDS Policies to the Same Role

For my test scenario, I want a role to only be able to interact with Customers and Vendors that have a group (CustGroup/VendGroup) equal to 10. The first thing I did was to create a role that allows full control of both customers and vendors. Here is what the test user sees when assigned this role:

To implement the XDS policies, I first created the Customer and Vendor queries:

I then create the security policies for these queries. A couple things to note here:

• The Context String property for each policy is the same, this will allow us to assign these policies to the same role
• The Context Type is set to RoleProperty, this means that the Context String will be used to determine which role(s) this should apply to
• The Operations property is set to AllOperations, which means all Reads, Updates, Creates, and Deletes will be under the context of XDS
• The Primary Table in each is the corresponding Group table for the object (VendGroup/CustGroup)
• Each policy references the corresponding query (VendorGroupQuery, CustomerGroupQuery)

I then created a role (FpGroupXDSRole) that I assigned the appropriate duties too, notice here that I set the Context String to the same string as my security policies (GroupXDSPolicy). This will apply both XDS policies to this role.

Once this role is assigned to the user, we can see that both policies are applied successfully.

In my test from above, I created the role via the AOT. I also wanted to ensure that a role created from the user interface also works as expected. So I created a role in the Security Configuration area of D365FO and made sure to set the Security Policy Context String to the same string as before (GroupXDSPolicy).

Scenario #2 – What is the outcome if multiple roles with the same access are applied to a user, one having an XDS policy and one that does not?

We will have two roles: FPCustomersRole and FPXdsCustomersRole, both of which will be assigned the CustCustomersMaintain duty which give access to maintain customer records.

With the FPCustomersRole assigned to our test user, the user can see all customer records:

The FPXdsCustomersRole has an XDS policy applied to only show customers with a CustGroup of 10. With the FPXdsCustomersRole applied, our test user can only see those customers with a CustGroup of 10:

Scenario #3 – Can you Apply an XDS Policy to a sub role?

If we apply for the roles with the FPCustomersRole being the base role and the FPXdsCustomersRole being the sub role (so the role with XDS applied to be the sub role):

We get an interesting outcome, our test user can see all customers:

This means that the XDS policy is not being applied.

What happens if we reverse it and have the XDS role being the base role and the normal role being the subrole?

Now the XDS policy is applied correctly:

This idea also works if the base role has no permissions directly assigned to it but has the normal role as a subrole. This type of scenario would be beneficial if one set of users should have XDS applied and another set of users should not, you can control access for both groups with one underlying role and control the XDS portion by creating parent roles with their context string set to the XDS policy that should be applied:

XDS cannot be applied as a sub-role to another role, however, a normal role can be a sub-role to a role with XDS applied and it will function correctly.

Scenario #4 – Can you Have a User Be Able to View All Instances of an Object, but Only Update/Create/Delete Specific Objects via XDS?

In the previous scenarios, I have always set the Operation parameter for a security policy to ‘AllOperations’ but there are other options. One of those is ‘InsertUpdateDelete’, which means that the XDS policy will only apply to those SQL operations:

If we apply this security policy to a role and assign it to a user and load the All Customers form we can see all of the customers:

However this is what happens if you try to create a customer with a CustGroup other than 10:

And here is what happens if you try to edit a record with a CustGroup other than 10:

And here is what happens if you try to delete a customer with a CustGroup of 10:

So, you do have the ability to see all objects but only Update, Create, or Delete objects with a specified parameter defined in the security policy.

Scenario #5 – If There Are Multiple XDS Policies Applied to the Same Role and for the Same Object are the Policies ‘AND’d or ‘OR’d Together?

Let’s use a combination of our CustGroup = 10 security policy and add in a CustGroup = 20 security policy and apply both policies to the same role via security context.

So now if we apply both to the role and assign it to the user we can see that the XDS scenarios are AND’d together as no customers are returned.

Conclusion

The above scenarios show how XDS reacts to different configurations within your D365FO environment. Be on the look out in the future as we look at how to perform XDS when there is not a current primary table to use.