There are a lot of questions about security in D365FO and how it differs from previous versions of AX. If we look specifically at user permissions we can see a couple of things that have changed.
In AX the access level is hierarchy based with one access level being assigned to each object:
No Access -> Read -> Update -> Create -> Correct -> Delete (Full Control)
An excerpt from an MSDN on the topic has the following:
Read is the weakest permission, and Delete is the strongest. Delete permission includes every other permission. Create permission includes Update and Read. You can set the permission value to NoAccess to prevent all access to the entry point.
The Correct permission applies only when a time state table is involved. This permission authorizes you to issue update records in a time state table.
Below you can see that you are only able to assign one Access Level per object.
In D365FO the permissions still follow this hierarchy of permission strength but allow for a piecemeal assignment. This means you can individually select Read, Update, Create, or Delete for each object you are securing. There are also different access types for each access level: Unset, Grant, and Deny. Grant means that the user has the ability to this access level for this object, and Deny means that the user is explicitly being denied this access, and Unset means you are not granting nor denying access to the object so if another role, duty, or privilege grants access to the object then the user will have access.
One thing to keep in mind, is that the Deny access type overrides any Grants assigned to the user for this object from any role, duty, or privilege.
D365FO also has a new data type called a Data Entity. A data entity is basically a SQL view that will take a normalized database object that could exist across multiple SQL tables and creates one object that an end user can interact with. It is a very powerful feature that can be used by developers and 3rd party applications to interface with D365FO.
Permissions for a data entity include one more property called Integration Mode. This setting will dictate if this element is accessible from OData and/or an import/export or connector integration.
Entry point Description Data services The ability to use OData services (API) for the entity. Data management The ability to use asynchronous integration options for the entity, such as import/export and connector integration.
These changes in the security model will need to be kept in mind when designing and applying security to an end user.
It’s hard to find well-informed folks on this topic, but
you seem like you understand what you’re talking about!
Thanks
Greetings! Really helpful guidance on this article!
It really is the small changes that make the biggest
changes. Thanks a lot for sharing!
Is there any way to restrict the list of entities the user see when connection is made using OData ?
I need to restrict the list of entities which are shown in Power BI to the user as per the access to the entities given to the user on D365FO.
Lalit,
This can be done one of two ways:
– You can use something like XDS to restrict the underlying access to the objects themselves and therefore would affect the entities the user would see in OData
– The other option would be to add the filtering on the OData query string itself, since D365FO OData is built on top of the OData framework all querying functionality from that standard can be applied here
So for example if I wanted to return just customers who have a Customer Group Id = 20 and are within the USSI legal entity I could do something like this:
data/Customers?$filter=CustomerGroupId eq ’20’ and dataAreaId eq ‘ussi’&cross-company=true
Which once converted in the URL, looks like this: data/Customers?$filter=CustomerGroupId%20eq%20’20’%20and%20dataAreaId%20eq%20’ussi’&cross-company=true
More information on the OData filtering options can be found here: https://www.odata.org/odata-services/