What's new: Role-based security
Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
In earlier versions of Microsoft Dynamics AX, the management of application security was complex and time-consuming. Administrators had to determine which tables and fields were required for a task, and then grant a user permissions for those tables and fields. In Microsoft Dynamics AX 2012, security management is more intuitive and less time-consuming. Administrators manage security by defining roles and then assigning users to those roles. Developers assign permissions to program artifacts such as tables, forms, and form controls. Permissions are grouped into privileges and duties that are assigned to roles.
Overview
Item |
Description |
|---|---|
Required feature |
Yes |
Product areas affected |
All |
Stakeholders |
Technical decision makers Implementation team members Independent software vendors (ISVs)/developers Partners |
New functionality
The system administrator and the developer each manage parts of the new security system. The administrator defines the roles that are used in the organization and assigns users to those roles. The developer defines the duties that are used to grant permission to the tasks that each role performs.
.gif "Dn527126.collapse_all(ru-ru,AX.60).gif")
What’s new in security for system administrators
What’s new in AX 2012
What can you do? |
Microsoft Dynamics AX 2009 |
AX 2012 |
Why is this important? |
|---|---|---|---|
Define user groups. |
Security was not defined by default. Administrators had to create their own user groups and grant those groups access to application objects. |
Permissions for all application objects have been grouped into task-based privileges and duties. Sample security roles and duties are provided for every area of Microsoft Dynamics AX. Relevant privileges are assigned to these roles and duties by default. You can use the sample security roles and duties as they are, modify them to fit the requirements of your business, or create new security roles and duties. For information about the default roles, see Security role reference. |
Management of user security has been simplified. |
Set user group permissions. |
Administrators had to create user groups and manually assign users to those groups. To grant a user group permission to perform a particular operation, the administrator had to identify the application objects, such as tables, fields, and menu items, that were required for the operation. When a person changed jobs, the administrator had to manually update that person's permissions in Microsoft Dynamics AX. |
Many security roles are predefined to make security setup easier. The administrator grants access to the duties that users in a role perform. The administrator no longer has to identify the application objects that are required for an operation. Instead, the developer now associates the necessary permissions in the Microsoft Dynamics AX Application Object Tree (AOT) on each relevant item. Because rules can be set up for automatic role assignment, the administrator does not have to be involved every time that a user's responsibilities change. After security roles and rules have been set up, role assignments can be updated based on changes in business data. For more information about role assignment rules, see Assign users to security roles. |
User security is aligned with your business. |
Reuse permissions across companies. |
User groups could not span multiple companies. If the same functional role was required in two companies, the administrator had to create two user groups. Therefore, the number of user groups could grow quickly. For example, in a business that has 50 functional roles in 50 companies, the administrator had to create and manage 2,500 user groups to appropriately assign permissions. |
A single set of roles applies across all organizations. The administrator no longer has to create and maintain separate user groups for each organization. Although roles themselves are not specific to an organization, the administrator can still assign a user to a role in specific organizations. |
Management of user security has been simplified. |
Define permission levels (read only, create, update, and delete). |
Security keys were used to define permission levels for user groups. |
Separate default privileges are defined for each permission level. Security keys are no longer used. |
Management of user security has been simplified. |
Enforce regulatory and procedural compliance. |
There were no built-in features to help prevent fraud and guarantee compliance. |
Fewer security objects are assigned to fewer groups of users. You can audit for compliance based on business activities instead of program elements. The administrator can set up rules for segregating duties to make sure that a user does not gain access to conflicting duties. For example, a rule can specify that the same person cannot both acknowledge the receipt of goods and pay the vendor. For more information about how to segregate duties for regulatory or procedural compliance, see Set up segregation of duties. |
User security is improved. |
Allow external users to access Microsoft Dynamics AX through Enterprise Portal for Microsoft Dynamics AX. |
User authentication was based on Active Directory Domain Services. All users were required to be domain users. This requirement applied even to external users of Enterprise Portal. To help secure other data on the network, the administrator had to set up group policies to prevent external users from accessing that data. |
Users can be authenticated by using methods other than Active Directory. Therefore, external users no longer require domain accounts to access Enterprise Portal. For more information about how to grant external users access to Enterprise Portal, see Deploy an Enterprise Portal site that uses forms-based authentication. |
Management of user security has been simplified, and user security is improved. |
Use improved data security filters. |
When data filters were created through the record-level security feature, the fields that the filters were based on had to be in the same table as the data that was filtered. |
A user can create data security policies based on data that is contained in a different table. For more information, see Security Policies in the AOT for Data Records. |
Data security controls are improved. |
Use data security that is based on effective dates. |
The feature was not supported. |
Administrators can specify whether users have access to past, present, or future records, and can specify different levels of access for each kind of record. |
Data security controls are improved. |
Prevent users from accessing unauthorized data. |
All information was sent from the server to the client, and the client hid unauthorized fields from the user. |
The server filters information. Only information that the administrator grants the user access to is sent to the client and to the user. |
Data security controls are improved. |
Consistently enforce security for all client types. |
The Table Permissions Framework (TPF) was used to deny access to tables. All data was sent to the client, and specific fields in client forms were hidden, based on permissions. Tables that were not protected by TPF were freely accessible by code. |
TPF permissions can be applied at the field level. Because more authorization is performed on the server, permissions are more consistently enforced, regardless of the type of client. For more information about TPF, see Manage data access by using the Table Permissions Framework. |
Data security controls are improved. |
Make sure that you have the correct Microsoft Dynamics AX licenses for users. |
Licensing was not based on named users. |
Licensing is based on the roles that users perform in the organization. The Named user license count report displays information about the user licenses that are required, based on the security roles that users are assigned to. For more information, see Named user license count report (SysUserLicenseCountReport). |
Verification of licensing compliance is easier. |
What’s new in Microsoft Dynamics AX 2012 R2
Feature |
Description |
|---|---|
Enhancements to the Named user license count report |
The Named user license count report can display the user IDs and aliases that are currently assigned to each license type. |
What’s new in security for developers
What’s new in AX 2012
Many elements in the AOT have properties that are related to role-based security. However, for the developer, the central location of role-based security is under the Security node.
Role-based security has mechanisms that help secure both columns and rows in tables. You can help secure the following elements:
Tables and table fields – You can often help secure these elements by limiting access through menu items and forms that interact with the tables.
Table records – You can help secure these elements based on the data values in the records.
What can you do? |
AX 2009 |
AX 2012 |
Why is this important? |
Where can I find more information? |
|---|---|---|---|---|
Create security permissions on individual AOT elements. |
The feature was not supported. |
The system automatically generates sets of permission specifications on forms and other AOT elements. The permission specifications are inferred by the system to match the details of each form. The developer can modify the permission specifications on any given form. The developer selects the set of permission specifications that applies to each menu item that refers to the form. The developer uses the AOT to activate the selected permission specifications. The developer can combine many active permissions into one privilege. Active permissions are created in the AOT, under the Security > Permissions node. One privilege can correspond to the various actions that are required to perform one particular business task. Either the system administrator or the developer can assign a privilege to a user role. All users who are assigned to the role gain that privilege. |
The new security system takes less work to maintain as your business evolves. Security constructs can be reused more easily. Data that the user does not have permissions to see is never sent from Microsoft Dynamics AX Application Object Server (AOS) to the client. Appropriate security does not rely on forms for enforcement. |
For more information, see Automatic Inference of Permissions in AOT Security. |
Implement security policies for table records. |
The record level security (RLS) feature was used to filter access to table records. RLS security constructs applied only in individual tables. RLS was applied only if the developer explicitly called RLS to enforce security. Therefore, security enforcement could be accidentally omitted. |
Security policies for table rows behave like a where clause in SQL. A security policy is based on a query under the Queries node in the AOT. The details of the policy are specified under the Data Sources > Ranges node. Therefore, foreign key relations between tables can be part of a security policy. Security policies are assigned to user roles. |
Security policies can restrict access to table rows, based on foreign key relationships between tables. One security policy can replace several RLS specifications. After a security policy is created in the AOT and assigned to a user role, the system automatically enforces the policy. Therefore, developers do not have to add calls to a security system in their code. The RLS feature will be removed from a future version of the product. |
For more information, see Security Policies in the AOT for Data Records. |
Special considerations
If you are using an earlier version of Microsoft Dynamics AX, your existing security setup cannot be directly upgraded to role-based security. You must evaluate your current user groups and determine the best way to implement them in AX 2012. For more information, see Best practices for upgrading to role-based security.
To effectively use role-based security, you must plan and set up the roles that are required for your business. Work with the managers who oversee the different groups in the business to determine the appropriate permission levels for roles. For example, work with a manager in the Finance department to determine permission levels for Finance roles.
More information
For more detailed information about role-based security, see Role-based security in Microsoft Dynamics AX.
For more information about Extensible Data Security (XDS), see the white paper Developing Extensible Data Security Policies.