Share via


Security Policies in the AOT for Data Records

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This topic describes the relationships between the Application Object Tree (AOT) elements that work together to create and apply security policies. Security policies determine the allowable table record accesses for users that are associated to the same security roles that the policies are associated to.

Security policies are based on AOT queries. Queries filter table records by the joining of data sources, and by range specifications that data values must satisfy.

Note

In contrast to security policies which secure table rows or records, security permissions secure table columns or fields.

Creating a Query for your Policy

All security policies are based on an AOT query. The query defines the table records that the policy allows access to. This topic uses the VendProfileAccountPolicy query as an example.

The VendProfileAccountPolicy query has two ranges defined. The ranged named ExternalEntityType allows access only to table records that have the entity type value of Vendor.

The VendProfileAccountPolicy query in the AOT.

The VendProfileAccountPolicy query

Create a Security Policy in the AOT

You create a security policy under AOT > Security > Policies.

Next you set the following properties on your new policy:

  1. Set the PrimaryTable property. This affects the drop-down list for the Query property.

  2. Set the Query property. In the current example the query is named VendProfileAccountPolicy.

  3. Set the ConstrainedTable property.

  4. Set the ContextType property.

  5. Set the ContextString property, if appropriate for the ContextType value.

There are other important properties to set also. For more information about these properties, see Security Policies Properties.

The security policy VendProfileAccount in the AOT.

The VendProfileAccount policy

Gg847361.collapse_all(en-us,AX.60).gifAdd Constrained Tables under the Policy

The query might have several data sources. Typically they are tables that are related by foreign key relations. You increase the number of tables that the policy secures by adding nodes under the ConstrainedTables node of the security policy. You increase the number of tables that are secured by the policy by adding nodes under the ConstrainedTables node for the security policy. The nodes represent a set of tables that are connected by foreign keys relations. Some constrained tables should have foreign key relations with a table in the query. And those tables would have foreign key relations with some remaining tables, and so on. All the constrained tables are linked by foreign keys. Security applies to apply the whole set of constrained tables.

Interaction between Multiple Security Policies

The behavior of the system depends on the number of policies that apply, as explained in the following list:

  • When no security policy applies – There are no restrictions on which records can be accessed.

  • When one security policy applies – The records that are included by the policy are the only records that can be accessed.

  • 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.

See also

Role-based Security in the AOT for Developers

Security Policies Properties

Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.