Extensible data security policies
This article provides an overview of Extensible Data Security (XDS) policies in Finance and operations apps. XDS allows developers to supplement role-based security by restricting access to table records based on security policies. The query in the policy applies a filter and only records that satisfy the conditions of the filter will be accessible from the restricted tables.
Data security policy components
Constrained tables: The table or tables from which data is filtered or secured. For example, in a policy that secures access to transactions based on customer, the CustTrans would be an example of a constrained table.
Primary table: Used to secure the content of the related constrained table. In the example below, the CustTable table would be the primary table. The primary table must have an explicit relationship to the constrained tables.
Policy query: Used to secure the constrained tables content using a range condition on the primary table contents. Only records that are included in the range will be accessible. The range can, for example, be based on a specific value for Customer.
Context – Controls the conditions under which a policy is applicable. Two main types of contexts are available:
Role context: Based on the roles that the user is assigned. There are two sub-options for role context:
RoleName – Indicates that the security policy is only applied to the application user assigned to the role equal to the value of RoleName.
RoleProperty – This value is used in combination with the ContextString property to specify multiple user roles context. It is applied when the Context String value defined in the Role Property field for the policy is the same as the ContextString field value for the assigned user roles.
Application context: Applied if the context string set by the application using the XDS::SetContext API is the same as the value defined in the Context String field for the policy.
In the Application Object Tree (AOT), policies and their components are displayed under Security > Policies.
The policy query is added to the WHERE clause, or ON clause, on SELECT, UPDATE, DELETE and INSERT operations involving the specified constrained tables. Unless carefully designed and tested, policy queries can have a significant performance impact. Therefore, make sure to follow simple but important guidelines when developing an extensible data security policy. For more information, see the "Developing efficient extensible data security policies" section in Developing Extensible Data Security Policies (White paper) [AX 2012].
When two or more security policies apply, the intersection (not the union) of the records that are included by each policy are the only records that can be accessed. This means that a record must satisfy all the applicable security policies before access to the record is allowed.
XDS is not supported for financial dimensions and using XDS with financial dimension data will result in corruption of the data.
For information about how to debug policies, create more advanced policies, including chaining of restricted tables, table relations based on expressions and much more please refer to these resources:
Submit and view feedback for