Compartir a través de

Security Policies Properties

  • Artículo

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

Developers and system administrators can create security policies to deny access to subset of data records in tables.

Constrained Tables of a Policy

You can add tables and views under the Constrained Tables node of a security policy in the AOT. These tables and views relate to the data source table of the query that is named in the Query property of the policy. The following list shows the hierarchy of security policy nodes in the AOT:

  • Security

    • Policies

      • YourPolicy

        • Constrained Tables

          • YourConstrainedTable

            • YourConstrainedSubTable

          • YourConstrainedView

Each Constrained Tables node can contain any number of constrained tables and views. And each constrained table can contain any number of constrained sub-tables.

Security Policy Properties

The following table describes the properties for the AOT node at Security > Policies > YourPolicy.

Property

Required

Description

Name

Yes

The name of the security policy.

Label

Yes

The text that appears on the user interface for the security policy.

PrimaryTable

Yes

The table that is specified in the data source for the security policy query.

Query

Yes

The query which is used by the policy to filter data from the constrained tables that are specified in the policy.

UseNotExistJoin

Yes

Indicates whether the security query must be applied as a not exists join or as an exists join.

PolicyGroup

No

The PolicyGroup property is set by a drop-down list that contains the security policy group names that the system administrator has created.

The system administrator or developer can create security policy groups. This property can be used by administrators and developers to quickly identify groups of related security policies. The system does not use this property during run time.

ConstrainedTable

Yes

Controls whether the security policy restricts the data values in records that are returned from the primary table. The value can be one of the following:

  • Yes – The security policy is enforced on the primary table.

  • No – The security policy is not enforced on the primary table.

Enabled

Yes

Controls whether the policy is enforced by the system during run time. The value can be one of the following:

  • Yes – Enable the security policy.

  • No – Disable the security policy.

Operation

Yes

Controls which data operations the policy is enforced for. The value can be one of the following:

  • Select

  • Insert

  • Update

  • Delete

  • Insert, Update and Delete

  • All operations

ContextType

Yes

Controls the context type of the security policy. The value can be one of the following:

  • ContextString – Indicates that you have to specify a value for the ContextString property. The security policy uses a specific application context for the policy.

  • RoleName – Indicates that the security policy is only applied to the application user assigned to the value of RoleName.

  • RoleProperty – This value is used in combination with the ContextString property to specify multiple roles context.

    For more information, see XDSServices.setXDSContext Method.

ContextString

Yes

This property works in combination with ContextType property. It can specify an application or multiple roles context.

See also

Role-based Security in the AOT for Developers

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