Security in Dynamics 365 F&O

Today we will talk about a topic that usually leaves us a little unprepared in each implementation. It is hated and loved in equal proportion. Security in F&O is a vital part of the system that can do wonders with many optimizations. Let's see it!

What do we refer to when we talk about Security at D365 F&O? When we mention the subject, many of us older people remember to register accounts in Active Directory and then in Ax2012 and assign security roles, etc. A whole story that only a few knew how to do.

Not much of it has changed, although the forms and concepts are slightly different. To talk about security in F&O, we have to start by talking about the security architecture, which is the following:

Here we can see that Security in Dynamics consists of three segments.

In the first instance, the Authentication tells us how to access the system. It is the first access key and resides in AAD (Azure Active Directory). A user must be created in the AAD within the corresponding Tenant to access F&O.

To explain this a little more, the tenant is an instance or a place created by our company where all the services we will use are associated. To access it, it is necessary to have an email account (a user) that allows the tenant to enter.

Once we have our user registered in the AAD of our tenant, will we then be able to access F&O? Not yet. First, we must move on to the second security instance, Authorization, which controls user access to the application's features.

In particular, the Authorization controls each user's access to the menus, menu items, actions, buttons, controls, reports, etc... of our F&O client. In particular, it works with a security scheme based on Roles that we will explain later.

Once Authorized, we have one more level of security, Data Security. Instead of authorizing access, we restrict access to database data, tables, and records. Through a functionality called "Extensible data security policies" (XDS), we can extend the security of roles, restricting access to specific objects and records in the database. In some other posts, we can talk a bit more about XDS, but for now, we will continue with Role-Based Security.

Role-based security.

This concept was born as part of the "Authorization" we saw before. Here security is not assigned directly to users but is given directly to roles. What does this mean? Security privileges to menus, forms, and fields are set to roles within the organization, such as an accounting clerk, and then users are given to the accounting clerk role. We will not have those security privileges if we do not have that role within our user. This allows us to have very dynamic security management. If security policies change, roles are modified or changed without going from user to user, changing access. In the case that we need to make a massive change,

We will see the following concepts if we look carefully at the previous graph in the Authorization section.

Roles: They are the heart of the security assignment. They typically describe a position or position within the organization that performs multiple activities, such as "Accounting Officer," "Purchasing Agent," or "Sales Manager." Roles are those that are assigned to users. A single role or more than one can be set. The combination of roles is always positive, giving access instead of restricting it. Roles can be associated with organizational hierarchies and help us provide security or even work with approval flows by role hierarchies. By default F&O, it brings security roles that contain all the system's functionality.

Duties: Duties describe the accesses of a business process. For example, "Maintain purchase orders". By associating a duty with a security role, we associate a position with a business process. In other words, if we want our role "Purchasing officer" to be able to "Keep purchase orders", we add the duty to the role, and that's it. Duties have multiple privileges corresponding to the business process they refer to. Within their name, we can distinguish if they are from ABM, because usually start with the word "Maintain", or only for query because they begin with the word "View".

In compliance with international standards (for example, SOX or IFRS), there is a control segregation functionality that allows us to load security restrictions so that, for example, a user who makes sales invoices is not assigned also to be able to pay them.

Privileges: Security privileges manage security at the level of each system control. Each job and action can be associated with roles and duties. The best thing to do is associate it with duties for easier maintenance, but nothing prevents us from associating them with roles.

Permissions: Permissions are each action of each control that has the privilege. We can control whether a privilege can read a record or modify it through permissions.

Finally, we have an Audit section, which allows us to review and control access to the system through logs and, added to a series of security reports, will allow us to review access information quickly and detect any anomaly.

So far, we have left this first part. In the next post, we will see how we handle all role-based security within F&O.

See you in another Consejo Dynamicsl!!