Problem
Enhancements in the security development process for Dynamics
365 for Finance and Operations (D365FO) presents challenges for organizations
with many environments to maintain.
Background
Prior to D365FO, AX security was 100% development
based. Privileges, Duties and Roles were
application objects and deployed through organizations via standard development
DevOps procedures. For the purposes of
this discussion, we will call this method of security development design time. By compiling the security changes into the
application and then deploying the updated code, it required IT development
resources to be very involved in the process.
With the introduction of Dynamics 365 for Finance and
Operations, Microsoft has introduced a new alternative for security
development. Security modifications can
now be made at run time with the new
security definitions stored in the database.
Security Privileges, Duties, and Roles can now be created from inside
the application, and those roles can be exported and imported to allow movement
between systems. There is no code
required, and as such, a developer is not required to handle the security
development.
You can use either method to create security customizations
in the current system. I’m not aware of
any official statements from Microsoft around their intentions regarding
maintaining both the design time and run time options for developing security. However, Microsoft has been clear in their
intent to steadily move customizations out of the code base and into
configurations where possible. Their
sealing of the platform is the strongest indicator of their intent to limit
code modifications.
Columbus and To-Increase have embraced the run time
development option in our Security
and Compliance Studio product. In
our experience, the run time option has the benefit of allowing business
analysts and dedicated security personnel the ability to directly work on
creating the security components. Security
changes made in the run time environment don’t require code compilation;
therefore, the time between development and testing can be significantly
reduced. Moving security development
away from design time means that deploying security modifications via a DevOps
pipeline is no longer sufficient. That will
account for the design time changes, but will not cover any changes made in the
run time.
Solution
Our recommended approach is to utilize the Data
management framework to keep the design time security objects in sync
across all environments. There are predefined
data entities that can be leveraged to handle this process.
Security
Type
|
Data
Entity
|
Privilege
|
Security privilege metadata customizations entity
|
Duty
|
Security duty metadata customizations entity
|
Role
|
Security role metadata customizations entity
|
From your primary security development environment, you can
create an Export project that consists of these three Entities. For each environment needing to be
synchronized, you can create an import project that takes the package created
in the export. Both the export and import jobs can be scheduled for an automatic
deployment option.
 |
| Data Management Security Import Project |
It is important to note that this change does not restrict a
company from continuing to develop security objects via design time where it makes
sense. Those changes can still be distributed
throughout the environments via their traditional DevOps pipeline.
Alternate Solution
If all the D365 instances are created and administrated through LCS in
the Azure cloud, it is possible to deploy updated security configurations using
the Configuration and Data Manager in LCS.
You will still create the export file as in Solution and then load the
package created into the LCS Configuration and Data Manager. From there it can be deployed to other environments.
Summary
While we can appreciate the added complexity that
maintaining design time and run time security development can bring, we believe
the run time approach added by Microsoft brings great benefits. Eliminating the
source code compilation time and effort to deploy source code changes means a significant
reduction in the time to deploy and test security changes. This can allow organizations to move quickly and
still reliably test new security modifications.
Empowering the security analysts to be more involved in the actual
creation of the security objects can also shorten the security creation process
for some organizations. Finally, leveraging the Data Framework to move these
security objects in a structured manner will provide a reliable way to ensure
that the critical work of security is applied to all managed instances.