Role-Based Security System

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

The Microsoft Dynamics AX security system implements a role-based security model. The primary security specifications are privileges for table fields, and policies for table records. From the perspective of the developer using the AOT, a role is an aggregation of security specifications. The security specifications are designed to support a group of job activities performed by users with a known set of job responsibilities.

The Microsoft Dynamics AX system administrator assigns roles to the users. The users through those role assignments acquire the permissions to perform specific system operations. You should choose role names that describe the job activities performed by users of the system. For more information about role-based security, see Role-based security in Microsoft Dynamics AX.

Strengths of the Role-based Security Model

The strengths of the Microsoft Dynamics AX role-based security system include the following features.

Feature	Description
Easy administration	System administrators do not need to know the individual tables needed by users. Developers know which tables to bundle into sets called privileges or duties. The system administrator needs to know only which privileges make sense for each given role. Easier security administration leads to significantly lower total cost of ownership.
Conveniently reusable	The privileges and policies are designed to be easily reused as users and roles change. You can apply a single set of roles across all companies and organizations.
Automatic inference	The automatic inference feature makes it easy for developers to bundle form permissions into privileges.
Regulatory compliance	The role-based model makes it easy to audit the security structure of the application. You can better comply with regulatory requirements such as those from Sarbanes-Oxley (SOX), International Financial Reporting Standards (IFRS), and the United States Food and Drug Administration (FDA). You can set up a segregation of duties rules to make sure a user does not have access to conflicting duties. For example, you can set up a rule specifying one person should not be granted access to both create and release a purchase order. In another example, you can set up a rule specifying one person cannot both acknowledge the receipt of goods and pay the vendor.

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.