D365/AX7 – How to Implement Security Policy – Context Type Role Name

Problem

There are several practical scenarios where we are said to provide users the access to the forms but only allow them to view a set of records based on some conditions. At the same time, other users should be able to view a whole set of records of the data.

Solution

In order to achieve the above mentioned requirement, the security policy comes into action.

The security policy can be created three ways.

·         Context string: Use it if a context is used to determine whether the policy should be applied. Whenever it is required this context string needs to be set by the application using the XDS:SetContextAPI.

·         RoleName: Use it if the policy requires to be implemented only for a user in a specific role that accesses the constrained tables.

·         RoleProperty: Use it if the policy is to be applied only if user is a member of any one of a set of roles that have the context string property set to the same value.

Let’s have a quick demonstration on how security policy can be implemented using RoleName

Consider an example where logged in employee should be able to view only the vendor on vendor list page which is mapped to its employee record.

Step#1

Create an AOT query which returns the set of records which should be displayed to the user conditionally. For the above mentioned scenario, the query would look like below.

Step#2

Create a security role as below.

Step#3

Create a new security policy and set the properties as below.

Context Type: RoleName

Primary table: Select the table from the query as primary table to apply the record level security

Constraint Table: Set to ‘Yes’ if the Primary table should be used to restrict the records.

Operation: Select the operation which should be restricted on primary table using this security policy.

Query: Set the query you created in step 1.

Role Name: Set the role name as you created in step 2.

Build your model/project and synchronize the database (to make your role available on the security configuration form) and the security policy is set to be applied with the role.

Execution

Apply the role to the user and grant the privilege to the vendors list page. When the user login to the application, only the selected vendor is viewable to the user.

To check how to implement security policy using other context types, please check the blog.

Howto Implement Security Policy – Context Type Role Property (Context String)

Howto Implement Security Policy – Context Type Context String

D365/AX7 - Manage data access using AOS Authorization

Overview

Some of the database tables might contain some sensitive data which needs to be secured at the additional level to the security roles/privilege. The data such as employee’s personal details and salary details, financial data of the organization etc. should only be allowed to designated personnel of the organization to manage or view. In Microsoft Dynamics AX, this level of security can be imposed on the data by AOS Authorization.
AOS Authorization is a property associated with the TPF i.e. Tables Permission Framework in Dynamics AX, that adds additional level of security to the tables consisting sensitive data, and allows the administrator to manage access to such data.
When an attempt is made to access or to perform any operation on TPF-protected table, the AOS verifies if the user is authorized to perform respective action on the table. If the user does not have the appropriate permissions, the AOS does not complete the operation. These operations could be read, create, update or delete.

AOS Authorization Property

When concerned about how to enable AOS authorization on a table, following are the possible values for the AOS property on the table.

·         None

·         CreateDelete

·         UpdateDelete

·         CreateUpdateDelete

·         CreateReadUpdateDelete

The default value for AOS Authorization property on any table is None. Let’s say if the AOS authorization is set to CreateDelete on a table, then the AOS will authorize and confirm if the user has appropriate permissions for Create and Delete operations on the table. If the required permissions are lacked by the user, the application throws an exception. However, the rest of the operations, i.e. Read and Update are not checked by the AOS.

The AOS performs the authorization of TPF-protected tables by the following table methods.

·         aosValidateDelete

·         aosValidateInsert

·         aosValidateRead

·         aosValidateUpdate

Creating Security Roles for TPF-Protected Tables

Suppose if a report in Dynamics AX contains sensitive data related to an employee along with other basic information. If that sensitive data is maintained by a table which has the property AOS Authorization set to CreateReadUpdateDelete, then the report might not execute successfully by the user if at least Read permission is not granted to the user.
When creating the security privilege for the report getting data from the TPF-protected tables, we need to add the given table to security privilege and specify permissions explicitly for that table.