With the push in D365FO for automating everything from deployment to servicing to testing one of the questions I’ve heard numerous times is how do you perform/is it possible to perform automated role access testing? This comes into play for a number of reasons:

• With the quick releases of Microsoft D365FO I need a way to quickly ensure that my custom roles have the correct access even after updates
• I want to validate that the combination of roles have access to a specific table or field that allows a user to perform an action
• I want to validate that specific roles have access to custom objects
• I want to validate that the table permission framework is correctly set up for a particular table field

Along with many other use cases.

I knew going into this that there was very little information on how to go about doing this but knew that I was going to be using the SysTest framework and was looking for a way to decorate the tests by injecting which role(s) I wanted to run the tests with. And luckily, Microsoft has provided a way to do this with the SysTestSecurityAttribute.

SysTestSecurityAttribute Setup

The first thing I had to do was to learn the syntax required for the SysTestSecurityAttribute in the SysTest framework, which looks like this:

[SysTestTargetAttribute(classStr(SysTestSecurityContext), UtilElementType::Class), SysTestSecurityAttribute(‘personaName’, [‘RoleSystemName’], true)]

It takes in 3 parameters:

• str personaName – in my testing this can be any string
• container securityRoleNames – a string array which contains the list of roles (using the system names) you want to run your test with
• bool isDefaultPersona – in my testing this should be set to true

I then would use this to decorate my testing class and ensure that the tests are ran under the roles I specify. Now I have some setup to do for testing, I created a custom role (FpTestRole) and granted it DELETE permission to the VendTableListPage menu item display but no explicit access to any fields on the VendTable itself and used the out of the box Accounting Manager (LedgerAccountingManager) role which does have explicit access to certain fields on the VendTable.

Scenario 1 – Test the FpTestRole to see if it has DELETE permission to the VendTable

The FpTestRole does have DELETE permission to the VendTableListPage menu item display which has the VendTable as a data source. So this test shows that the SysTestSecurityAttribute test process is taking into account the new relationship between entry point security and data source security

Scenario 2 – Test the FpTestRole to see if it has DELETE permission to the VendTable -> Tax1099RegNum field

Now I wanted to test to see if table permission framework (AOSAuthorization) is being honored, since I know the FpTestRole does not have this permission this test should fail which it does so we can confirm that this is being taken into account.

Scenario 3 – Test multiple roles

Now I want to test multiple role access against our current test, I know that the Accounting Manager role has explicit DELETE permission to the VendTable -> Tax1099RegNum table field so now when I add this role to my testing parameters these tests should pass, which they do. So we can confirm that multiple roles are working as well.

Notes:

Be sure to perform the following actions between each run of your tests:

• Build your solution
• Execute an iisreset command from Command Prompt
• Build the model

If I did not do these steps I had some inconsistent results as far as tests passing and failing.

Conclusion

Obviously this framework is extremely powerful and could be used to dramatically cut down your testing from a security perspective.

I still have quite a bit to explore and play around with surrounding the SysTestSecurityAttribute but I wanted to get this out and let everyone know about this. Like always, if you have questions feel free to reach out!

References:

SysTest Framework Supports Role Based Testing?