Dynamics 365 Finance and Operations Security Infrastructure?
In this article, I will try to explain the Dynamics 365 Finance and Operations security architecture. There is a docs article that I like very much, I will try to recap the topics by referencing it. It is very important to understand the security infrastructure. In today’s projects, managing security and authorization can be a very demanding process. In order to manage the needs correctly, it is necessary to know the infrastructure and the features, capabilities and constraints of security tools. In this article I will address the following topics. I did not translate them into Turkish. Sometimes there is a semantic shift, so I think explaning them is better.
• Security architecture
• Role-based security
• Duties
• Privileges
• Permissions
• Authentication
• Authorization
• Auditing
Finance and Operations application uses role-based security structure. Authorizations are given to roles, users are not directly authorized. Users are assigned roles. A user without any role has no authority in the system. The user assigned the admin role has full authorization. More precisely, they are not subject to any restrictions. Role-based security is a hierarchical structure as seen in Image-1.
Image-1
Role-based security
Role-based security has actually been created parallel to the work of business units. Role is the structure in which the necessary authorizations are gathered for a position with certain duties to fulfill those duties. The role is actually parallel to the employee’s actual job in the company. It does not mean that every employee has a role. In some cases, a single person may be managing different business processes. So they must have multiple roles. It is essential to organize roles according to the job, not the person. At least one role is required to log into the system. Generally, everyone is given the role of System User. You can use the System administration > Users > Assign users to roles form to assign the role.
Role assignment is made by admin accounts. Basically, roles consist of Duties and Privileges.
Image-2
Duties
Duties are where the necessary authorizations are gathered to carry out a certain work process. A task can be assigned to multiple roles. Therefore, a change you make to the duty automatically affects the assigned roles. The role can be assigned directly in Privilege, but for a more manageable infrastructure, it is necessary to create and use the duties.
Image-3
Privileges
It is the structure where the authorizations required to do a certain job are gathered. For example, the payment cancellation privilege only has the authorization required to do this job. You can give this privilege directly to the role, but as I said above, it would be a better approach to collect them in duties and assign them to roles. Security and authorization objects are defined for all objects in the system. You can find and replace the ones you need and add new ones. Especially in new developments, it is absolutely necessary to create Privilege. Duty may not be required for every development. It may be enough to grant this authorization with a specific duty, but not without Privilege.
Image-4
Permissions
Permissions refers to the level of authorization to access a specific object. This can be a MenuItem or any object. Generally, authorization is given through the entry point. And these are usually MenuItems. In some cases we also use it to directly define authorization for an object of the form.
Authentication
This is my favorite feature in the new version. I can use all tools with a single email. One of them, of course, is the Finance and Operations application. To enter the application, your user login must be created. I explained it in my previous article. Usually users are expected to be in Microsoft Azure Active Directory (AAD), but you can also add external users. You can set up 2-step verification.
Authorization
Authorization controls access to the Finance and Operations application. Security permissions are used for this. Security permissions determine how certain objects of the application are accessed. These objects are: menus, menu items, action and command buttons, reports, service operations, web URL menu items, web controls and fields.
Finance and Operations application uses a context-based security, so we define the level of access to a certain object. When you associate a privilege with an entry point, you also define an access level. Such as Read, Delete, update.
Auditing
User login and logout times are recorded. You can access these records from the admin account. (System administration > Inquiries > User log).
In this article, I tried to introduce you to the security infrastructure. It is a very extensive and detailed topic. Generally, projects have a person or team responsible only for these processes. When not designed correctly, maintenance costs and problems can be annoying. It is imperative to place the due importance and test well during the project phase. Generally, since consultants have admin privileges, they can skip tests with the required roles. Here it is recommended that key users do tests with the relevant role, not as an admin. I will continue to address security-related issues.
Regards.
www.fatihdemirci.net
TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, security architecture, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM
