Extensible Data Security (XDS) Role Base Security 2012 & D365FO

Extensible Data Security (XDS)  Role Base Security  2012 & D365FO

Overview

The Extensible Data Security policy framework is the Application Foundation framework provided by Microsoft Dynamics AX 2012 (new feature) in addition to the role-based security in order to secure the data.

Dynamics AX Admins and developers can use the security policies to block access to specific rows in a table. In the AOT, policies can be found under node Security > Policies.

XDS policy can be utilized for setting security privileges on the global address book.

Model of Extensible Data Security ( Source Link)

XDS concepts

Primary Table

A primary table is any table that will be used to restrict data in the constrained table. It is the table that is specified in the policy query.

Constrained Table

A constrained table is a table on which data filtering is applied. It can be a primary table or a table that is related to the primary table.

Policy Query

Policy query helps to secure data in the constrained table defined in the XDS. It is used to fetch data from the primary table, which is then used to restrict data in the constrained table.

Context

Context is the most import part of XDS without which security policy will not be applied. It defines the context on which security policy will be applied. It can have three possible values:

1. ContextString: Defines a specific application context on which security policy will be enabled. It is also called an application context.
2. RoleName: Defines that the security policy will only be applied to a particular Role in the application.
3. RoleProperty: Used to define multiple Roles for a single security policy.

Important

• Role Base security will remain same for AX 2012 & D365FO
• In this blog we will focus with RoleName Context.

Lets Begin!

In this demo we are Implementing XDS on Purchase Order and restricting with warehouse. Initially we will implement XDS with static Warehouse range.

As part of this tutorial, security policy will be applied to the XDS Purchse Order Security Role role

Steps

1. First, create a new Policy query. Open AOT Queries

2. Right click on Project and create a new Query XDS_PurchaseOrder

3.  Open Query Add New Data-Source Purch Table

4.  Set Dynamic Fields No and Manually Select One Field PurchID to Make sure performance will not hurt with you implementation.

5.  Add Range and select InventLocationId and set value properties. In my Case i have set the value 9221122W.

6. Save the query  (In Next Blog We will work with dynamic Range which user can control from UI Level)

7. Now next step is to create security Role

8. Right click on Project and create a new Role XDS_PurchaseOrderSecurityRole

                                           

11. select security from side panel and create Security Role and set the role proprieties Like below screenshot. 

Important 

No privilege required 

12.  Now next step is to create security Policy 

13. Right click on Project and create a new security Policy SLD_TransferOrderSecurityPolicy

14. select security from side panel and create Security policy.

15 set the security policy like below screen shot.

Now Build The Model and Sync Database if you are working on D365 and reset the IIS..

Go to Systems Administrator > Users Form and assign newly created Role to any user, To whom you want to perform testing..

Enjoy.... :)

Important

XDS security will not work if user have Systems Administrator role. 

Example: 2

I’m going to use the example of wanting to secure the SalesOrder table based on the customer group.

• Constrained table – is the table(s) given a security policy from which data is filtered or secured, based on the associated policy query. In the above example, the SalesOrder table would be the constrained table.
• Primary table – is used to secure the content of the related constrained table. In the above example, the CustTable would be the primary table. The primary table must have an explicit relationship to the constrained table.
• Policy query – the query used to secure the constrained table contents via the primary table contents
• Context – the piece of information that controls the circumstances that a given policy is applicable. Contexts have two categories:
  • Role Context – enables a policy based on the role(s) the user is assigned
  • Application Context – enables a policy based on information set by the application

Developing an Extensible Data Security Policy

Before you begin developing XDS policies there are a couple things understand/keep in mind:

• Understand the scenario requirement/use case of why you are using XDS
• Identify the constrained and primary tables and analyze the relationships between them
• Analyze the data access patterns, table size/record counts, and existing indexes of the constrained and primary tables

Demo Scenario

If we take the scenario that we want to limit the customers a particular user sees based on a specific customer group, how would we set that up?

1. The first thing to do is to determine your Constraint and Primary tables, in this case the CustTable table is our constraint table and the CustGroup table is our primary table.
2. Next we create the policy query around our CustGroup, we want this query to return the results that we want to restrict the constraint table with
   • Create a new Query, set the data source of the query to the primary table and then perform any filtering or other joins that need to be done for this query to return the results you want to filter by
   • In our case we are limiting the user to only be able to see customers that have a CustGroup of ’10’ and Name of ‘Major Customers’
   • 
3. Now we can create our Security Policy, we set the following parameters
   • Constrained Table to Yes
   • Primary Table to CustGroup
   • Query to the name of the query we created in step 2
   • If we want this to be applied to a specific role we can set this in the Role Name field, if you leave this blank it gets applied across all roles in your environment
   • 
4. We then add a constrained table to the policy, in our case CustTable and set the following parameters
   • Name field is the constrained table, CustTable
   • Table Relation is the primary table, CustGroup
   • 
5. Now if we build the solution and do a database sync of our project our XDS policy becomes live, to show what this does I did a before and after using a user assigned the FpTestRole to show the affect of the XDS policy

User access without XDS policy applied

User access after applying XDS policy

Now one question I had is, how do you apply an XDS policy against a group of roles? Well this is where the Context Type and Context String parameter on the policy comes into play. The Context Type parameter determines how the Context String parameter is handled. The Context Type has 3 different values:

• ContextString – should be set if you want to change the value of the Context String parameter via X++ code (via the XDS::SetContext method)
• RoleName – should be set if you want this policy to be assigned to a single role, this has the same effect as setting the Role Name field
• RoleProperty – allows for applying the policy to multiple roles via the Context String value, if a role has the same Context String then that role will have the XDS policy applied

If we set the Context Type to RoleProperty, then any role with a context string of the value we input in the Context String parameter will be assigned the XDS policy. So if we set the Context String value as CustGroup_XDSPolicy,

and then we set the same Context String value on a role, any user assigned that role will have the XDS policy applied to them.

Ensuring Efficient XDS Policies

Using XDS within D365FO will have an impact on the performance of queries on a table, the goal is to minimize this impact. There a couple things to keep in mind:

• Follow standard best practices of developing SQL queries (using indexes on join conditions, correct primary keys, etc)
• Simplify queries as much as possible, don’t have unnecessary joins

How to Debug/Troubleshoot Issues

If while using XDS you come across an instance where a user has more or less rows from a constrained table than you think they should you will have to try and debug the XDS policy. There are two ways of doing that:

• Execute a snippet of X++ code to see the SQL statement generated for a particular XDS policy (an example of this can be found in the white paper resource link below)
• 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
• 

Another issue that you may see is a performance impact once XDS policies have been applied. In this case you will need to review the simplicity of your queries, the indexes on your tables, the proper joins are being used, and take into account the number of rows within each table you are using.