Security model
The reason for describing the company concept and security simultaneously is because they're combined in finance and operations apps. While Dataverse has more separation, when you're connecting these components through dual-write, you need to consider both. The following image shows a breakdown of the finance and operations apps roles, privileges, and permissions, and it shows the branch of Dataverse ownership for entities and actions.
Dataverse and finance and operations apps have the same security model. Essentially, a user has security roles, and each security role gives that user several privileges.
The security model in both differs in a few areas. In Dataverse, privileges give the user the ability to view Dataverse entities and actions, and ownership helps protect the data. Conversely, in finance and operations apps, privileges give access to endpoints; if a user has access to a form, they have access to the underlying data source and table. In Dataverse, the entities are simple and de-normalized, whereas finance and operations apps contains dozens of tables, and it's a heavily normalized environment. These factors can make it difficult for you to determine the underlying table access rather than accessing the specific endpoint or form.
However, both have similar security regarding entities. Finance and operations apps can give access to an entity, which gives access to the underlying tables of that entity. Therefore, entities that are exposed through dual-write are advantageous because you can use the same security concepts for the underlying data.
Dual-write security
Dual-write security runs as a service-to-service call, and the user doesn't need to exist in both systems to have access to the data and make calls. If the data flows from finance and operations apps and is written to Dataverse, then the default dual-write team for the business unit owns the record. If the data flows from Dataverse and is written to finance and operations apps, then the data area concept scopes the record, and the system bases security on the legal entity.
Virtual entity security
The security in virtual entities differs from dual-write because virtual entities try to solve a different problem. Virtual entities allow Microsoft Power Platform technologies, and those who are using Dataverse natively, to access an assortment of data from finance and operations apps without signing in to the separate system. For that construct, you want an individual user to read and view records out of finance and operations apps in the context of their privileges. Because this process doesn't involve copying the data between two systems, like dual-write, you need to keep the user and their security in context to view the records and data.
For this arrangement, for virtual entities, you impersonate the Dataverse user in finance and operations apps when they make a virtual entity call. You would make a service-to-service call behind the scenes to impersonate the user and have the original user context for who created the call. In finance and operations apps, you complete a Run As operation to impersonate the user. Everything that the user does is related to their privileges, so they must have correct access to finance and operations apps. Basically, the user in Dataverse who makes the call must exist as a user in finance and operations apps. They must be licensed and have the correct security for the data that they're trying to access.
Virtual entities have three types of patterns for authentication and access:
User is accessing finance and operations apps data - For this pattern, you pass along the user and object ID into finance and operations apps, where the user must exist and have privileges to access the data that they need.
Portal access (anonymous and authenticated)
Anonymous portal access - For this pattern, you set the anonymous portal access in the System parameters area in finance and operations apps. The user who's created and set in the anonymous portal is in control of the portal access through the system parameters. The data that's exposed to that user, and the access that the user has, are what the anonymous users through the portal have permission to access.
Authenticated portal access - For this pattern, you use the Power Pages feature in System parameters to create access along with a contact record in Dataverse. That record in Dataverse controls what the contact can access. No access to that contact record from Dataverse is provided. So an external portal user mappings entity saves the settings for that contact and maps to a user in finance and operations apps. Each user can be separate, or you can create one user to manage all connections from Dataverse.
Service-to-service access as an application user - For this pattern, you create a Microsoft Entra ID and set it to a user inside of finance and operations apps. If an application user in Dataverse triggers a call through virtual entities, the service finds the originating Microsoft Entra ID and determines which user ID that the call should run as inside of finance and operations apps. If an explicit service-to-service ID isn't set up in finance and operations apps, then an access denied error occurs.
