Securing a menu item is not enough – table permissions

In the two earlier posts, I talked about missing parts and controls when you would create privileges from scratch. In this post, I will continue explaining about reasons for missing elements on forms due to table permissions. Or maybe you would like to restrict certain fields from being visible to users.

Missing fields

As mentioned in my previous blog, a form design consists of Bound controls, Unbound controls, and Calculated controls. Bound controls are linked to a physical database field. Calculated controls (aka display fields) can have logic to sum field values, but can also be used to lookup field values from different tables. What are the possible reasons for not having all fields visible on the forms for business users? Continue reading to learn more about table and field permissions as well as the table permissions framework.

To illustrate that tables and fields are part of the security framework, I will start with an example where I created a privilege with just two display menu items: All vendors (VendTableListPage) and Vendor bank accounts (VendBankAccount).

When assigning a role with this new privilege, the bank account details can be opened. It will show a record, but the actual bank account number and IBAN fields are missing. In the orange marked section, you will see the layout of the same form when having the system administrator or a properly defined role assigned.

In addition, the bank account number on the vendor details is not visible, This is a display field retrieving information from the vendor bank account details, based on the default bank account number set on the vendor.

What is the reason for the missing fields? It can have two causes. Either table and field permissions are used to restrict access to these fields or it is due to an additional data security layer for sensitive data called Table Permissions Framework (TPF). The link refers to AX 2012 documentation where this framework got introduced. Data is not accessible or write actions will not be completed if the user is not having explicit table or field permissions set on the privilege or the security role. In earlier versions, the user got an error on the form stating that he doesn’t have access to one or more fields in the table. Now, the fields will be hidden and the data is not visible to the end user. As I didn’t add table and field permissions to restrict access myself, the Table Permissions Framework is the root cause.

In Visual Studio, there is a property called AOSAuthorization. If this property has a value set, additional permissions should be added to the security which will then show the tables and fields to the users. Just granting the menu item permissions on a privilege is not sufficient. You should be aware of TPF and check if you need to add permissions next to the menu item access.

How can you recognize which tables and fields are impacted by the Table Permissions Framework in the application? As mentioned above, you can check table and field properties on the table objects in the Application Object Tree (AOT) accessible in Visual Studio. You would need access to a development environment for this purpose. In many cases, a person managing the security via the user interface will not have access to the development environment. For that purpose, I compiled a list of all tables and fields being part of the Table Permissions Framework. You can download an Excel workbook with the information at the bottom of this blog or from the downloads page.

Manage table and field permissions

I explained the root cause of the missing fields due to the Table Permissions Framework. We now must add the permissions to the security. We have multiple options, all with a particular impact. Firstly, I will provide a list of the options:

• Permissions on form data source
• Permissions on privilege
• Permissions on security role

Let’s start with the first option. Form both the user interface and the development, you can add permissions on the data source used on the form for which you granted permissions via a menu item. If you are using the security configuration form, go to the privilege, select the menu item. Then in the References column select the form name. When you selected the form name, you can view or add Data sources. When you select the data source VendBankAccount, you can add references and include the fields AcccountNum and BankIBAN. In the Select properties section, you can grant read and update permissions for the fields as per the requirement. Then click on the OK button to add the field references. Ensure to publish the changes.

Note that the table VendBankAccount itself does not have the AOSAuthorization property set, so you can have the permissions for the table as Unset.

When developing the privilege in Visual Studio, you can also add the table and field permissions like shown in the screenshot below.

After adding the table and field permissions, ensure you perform a build and database synchronization.

When navigating to the vendor bank account form, the user is able to view and update the vendor bank account number and IBAN. However, if you check the vendor details form, the display field with the bank account number is still empty. The reason for this is because the permissions were set on the entry point for the vendor bank account details and this does not inherit permissions on other forms.

To be able to have the display method visible on the vendor details, the permissions on the form data source is not the correct solution. Instead, you can set table permissions on the privilege. In that case, both the vendor details and the vendor bank accounts will inherit the permissions from the privilege.

In Visual Studio, you can add the table and field permissions on the Permissions node of the privilege.

In the list with options to provide table permissions, I also mentioned adding these on the security role level. The way to configure or customize it, is similar to the privilege. The only difference is that in case you set the permissions on the role level, it will be regognized within all duties and privileges added to that role. When you want to reuse the same privilege in multiple roles, the better option would be the privilege level. Also, when you have the permissions on the role and copies a role and remove duties and privileges, then still the role itself has the table permissions which might be not intended.

Restricting table and field permissions

In the opposite of granting table permissions, you can use the table and field override options for restricting access to tables and fields. To ensure access for certain tables or fields on a form should be reduced, you can use the Deny permission. In case you would need to restrict permissions and have only read rights for the default bank account number field on the vendor table, the Update property should be set to Deny. With the Unset permission, as the field is not restricted with the Table Permissions Framework, it would inherit the permissions from the table level. For overwriting the table permissions on the field level, the Deny option has a higher priority. Note that when you choose to use the deny option, there is no other role, duty or privilege which can overrule this. So, be very concious about when using the deny permissions.

You can find another example how to use the deny permissions in one of my previous blog posts: Security how-to: Only finance users are allowed to see cost prices in Dynamics 365 Finance and Operations

There is more…

Before leaving the page, here is a download link to the Excel worksheet as refenced above with a list of all tables and fields having the AOSAuthorization property enabled.

AOS Authorization list

1 file(s) 24.42 KB

Download

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!

The post Securing a menu item is not enough – table permissions appeared first on Dynamicspedia.