I had the privilege of recently attending the Dynamics 365 Tech Conference in Seattle, WA, and joined a class on the Dynamics 365 (D365) for Operations Security Model. This seminar focused on the core differences in security implementation between Dynamics AX and Dynamics 365 for Operations and covered some differences in technology and methodology.
Security Framework & Approach
At the core, the security framework and approach is essentially the same between Dynamics AX 2012 and D365 for Operations. One of the major differences is the concept of the separation between design time and run-time environments. In AX 2012, if you made changes to a security object (say a privilege), it would be immediately effective and an end-user would simply have to log out and back in the client to see those changes. In D365 however, those changes need to be “published” and a batch job of sorts will run (typically within five minutes) and implement those changes. Therefore, security changes may not be immediate.
Entry Point Security
Another key change in security surrounds Entry point security. One difficulty we encountered in AX 2012 was that if I had a security role that needed read access to a table or menu item on one privilege and delete permissions was given elsewhere on the form on another privilege, AX gave the role access to the form regardless of where the user came in on (if they came into the form through a read or delete entry point). This really was difficult sometimes during troubleshooting because it meant reverse engineering and “peeling the onion” back on every possible security touch point to the form or table in question to see where that access came from. Now in D365 for Operations, if the user came in from a read menu item, the delete will be ignored. This was really how AX 2012 should have worked, in that now Dynamics is respecting the developers intent here. This will really help in making security a bit easier to troubleshoot.
Security Reports & Diagnostic Tools added to D365
Some new security reports and diagnostic tools have been added to D365. When logged in as a system administrator, on the Options for any form there is an option for “Security Diagnostics”. This shows you all of the roles, duties, or privileges that give a user access to that form. Say, for example, a user comes in on a form and can’t access something they need to. A system administrator can navigate there, click on Security Diagnostics, and there will be buttons to “Add duty to a role” and other security-related tasks which essentially provide many of the security tasks at a form-level.
Removal of Tools
One last interesting part to mention regarding security in D365 are some removals. The Security Development Tool is no more! This was a valuable tool for many AX 2012 developers and system administrators and it will be greatly missed. There are a few pieces here in there in terms of tools in the D365 client as well as Visual Studio that accomplish (most) of what the Security Development Tool offered, but it is not a complete replacement. The biggest aspect that I will miss the most is the ability to traverse the AX menu navigation tree, down to the button or menu item object and add/remove permissions from there. There is currently no replacement for this functionality:
Time will tell if this is a viable solution or if something else will need to be developed.
Second, the use of Active Directory groups for user provisioning has not been removed per se, but it has been disabled by default. The notion behind this surrounds the protection of segregation of duties. When using Active Directory groups, I’m essentially turning my AD administrator into an AX administrator with full control thereof, thus it is turned off by default but can be enabled through a configuration key.
Exciting things are coming with the new D365, and hopefully, security will be easier to implement and lighter to manage.