Tutorial

Advanced XDS policies (secret recipies in AX 2012)

Advanced XDS policies (secret recipies in AX 2012)
Published in
April 2015

Almost every production company has some secret recipe that needs to be visible only for specific group of people inside the company.

These recipes in Microsoft Dynamics AX terms are actually BOM’s (Bill Of Materials) which needs to be hidden for the unauthorised persons. In this article I’ll show you two part solution which uses the XDS (Extensible Data Security) policies.

Part 1

In first part of the solution we need first to create a query for each set of data that we want to protect. The range for our query would be all the BOM’s that have the product name ‘SecComposition’. In order to build the query we should go by the physical table relationships i.e. starting from ‘BOM version’ as these policies should be valid for any version of the composition and going all the way down to ‘EcoResProductTranslation’ table as this is the table that stores the product names and we want to put a range on it.

And if you build the queries like that you will notice that there are actually two branches that start from ‘BOMVersion’ table and that’s why we need to build two queries and two policies based on them in order to cover all of the possible user scenarios. The second query that you should build should look like following:

Notice that we have also a second range for the ‘LanguageId’ in both queries and this is because ‘EcoResProductTranslation’ holds the product names in any language. And to define the language that we want the policy to be in rule we are setting this range with a function instead of fixed value. The value should be ‘(currentUserLanguage())’.

Now that we have the queries ready we should build the XDS policies and associate them with the roles that we want to limit from viewing the secret recipes. So build policies like following:

And for the second query:

As you can see we must set the property ‘UseNotExistJoin’ to yes as we want to show all the BOM’s except the ones that we select from the queries so this is the way to reverse it. Other properties that are very important are ‘ContextType’ set to ‘RoleProperty’ and the ‘ContextString’ set to ‘NotProductDesigner’ which will be association point between the policies and roles.

Not that we have built the policies we should set the property ‘ContextString’ to ‘NotProductDesigner’ for all the roles that we want to prevent from seeing BOM’s named ‘SecComposition’:

But this is very demanding task so I have built a job that does this for all the roles except for ‘BOMProductDesigner’ which in this case will be the only role that is allowed to view the secret recipes:

static void xdsUpdateBOMRelatedRoles(Args _args)

{

   TreeNode                    roleNode;

   SysSecObjectsAnalyzeType    secObjectsAnalyzeType;

   SysSecGeneralObjectType     secGeneralObjectType;

   SysSecFlatDataTable         flatDataTable;

   Counter                     counter = 0;

   FromTime                    startTime = timeNow();

   #Define.CompoundRecipesContextStr('NotProductDesigner')

   #Properties

   #AOT

   //Generate related roles data into SysSecFlatDataTable

   SysSecObjectsFromSecurableObject::GenerateData('BOM', 44);

   //iterate through the roles and update the context string property

   while select Role from flatDataTable

   {

       roleNode = TreeNode::findNode(#SecRolesPath + '\\' + flatDataTable.Role);

       if (roleNode.AOTname() == 'BOMProductDesigner')

       {

           roleNode.AOTsetProperty(#PropertyContextString, '');

           roleNode.AOTsave();

           roleNode.treeNodeRelease();

           roleNode = null;

       }

       else

       {

           roleNode.AOTsetProperty(#PropertyContextString, #CompoundRecipesContextStr);

           roleNode.AOTsave();

           roleNode.treeNodeRelease();

           roleNode = null;

       }

       counter++;

   }

   info(strFmt('%1 roles have been updated in %2.', counter, timeConsumed(startTime, timeNow())));

}

Part 2

Now you would think that we have finished everything but we must limit the ‘SysAdmin’ role as well just that we cannot limit this role at all. So the solution is to create alternative administrator’s role which will contain everything as the standard administrator role except the roles maintenance part because we should limit these alternative admins to elevate their privileges by their own. So we create a new role called ‘AltSysAdmin’ and drag and drop all the duties selected from a second AOT. Then we should just remove the duty called ‘SysSecSecurityMaintain’:

And that’s it with the development part just now we need to test the solution and testing security has never been easy because of the impersonation that we must do. We should test several roles including the ‘AltSysAdmin’ and the ‘BOMProductDesigner’ and one randomly chosen role. To easy this task you can create windows batch files with the ‘runas’ command for different users that you will test and then you will just run the BAT files:

runas /user:DOMAIN\testuser1 "C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe "D:\Dev_Box_USR.axc""

You will have these test users associated with the specific role in Microsoft Dynamics AX administration. So this completes the solution about representing secret recipes in Dynamics AX and securing them and I hope you’ve enjoyed it.

Happy DAXing.

Written by
Viktor Ristkovski

Microsoft Dynamics developer since 2009 (starting from Dynamics AX 2009) with experience in multiple Dynamics implementations across Europe and in almost any technical area of Microsoft Dynamics. Comes from Skopje, Macedonia, Graduated at Technical University in Varna, Bulgaria as Computer Science Engineer. Always supported by his lovely wife and daughter.