What's New: User and data security
Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
This topic describes the enhancements to security in Microsoft Dynamics AX 2012.
Role-based security
In previous releases of Microsoft Dynamics AX, managing security could be a lengthy and difficult process. Microsoft Dynamics AX 2012 introduces role-based security, which makes security easier to manage by providing the following benefits:
Security that is aligned with your business
In previous releases, Microsoft Dynamics AX administrators had to create their own 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. Identifying these elements could be a difficult and lengthy process. When a person changed jobs, the administrator had to manually update that person's permissions in Microsoft Dynamics AX.
In Microsoft Dynamics AX 2012, security is role-based, and many security roles are predefined to make security easier to set up. In role-based security, users are assigned to roles based on their responsibilities in the organization and their participation in business processes. The administrator no longer has to identify application objects and grant access to those objects. Instead, the administrator grants access to the duties that users in a role perform. 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.
Reusable permissions
In previous releases, 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 with 50 functional roles in 50 companies, the administrator had to create and manage 2500 user groups to appropriately assign permissions.
In Microsoft Dynamics AX 2012, 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.
Default and sample security definitions
In previous releases, security was not defined by default. Administrators had to create their own user groups and grant those groups access to application objects. In Microsoft Dynamics AX 2012, permissions for all application objects have been grouped into task-based privileges and duties. For example, the administrator no longer has to grant access to the Create sales order form and all of the related application objects. Instead, the administrator can grant access to the Maintain sales order duty, which includes all of the permissions that are required to view, create, modify, and delete sales orders.
Sample security roles and duties also make security easier to set up. Roles and duties are provided for every area of Microsoft Dynamics AX, and 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 needs of your business, or create new security roles and duties.
Note
By default, program access is defined for the default security roles. However, no data restrictions are applied by default.
Compliance and auditing
In previous releases, administrators had to manually audit for compliance. There were no built-in features to help prevent fraud and guarantee compliance.
Role-based security in Microsoft Dynamics AX 2012 is easier to audit, because fewer security objects are assigned to fewer groups of users. In addition, because of the concept of roles and duties, you can audit for compliance based on business activities instead of program elements.
In Microsoft Dynamics AX 2012, you can set up rules for the segregation of duties to guarantee that a user does not have access to conflicting duties. For example, you can set up a rule that specifies that one person cannot both acknowledge the receipt of goods and pay the vendor.
For more information, see Role-based security in Microsoft Dynamics AX and Set up segregation of duties.
Extensible data security framework
The extensible data security framework provides the following benefits to the system administrator who helps secure data in Microsoft Dynamics AX 2012:
Improved filters for data security
In previous releases, the record-level security feature was used to help secure the data. The filters that were used for record-level security could not be based on fields that were contained in a separate table from the data that was being filtered. For example, to filter sales lines, you could not use the customer location, because the customer location field is not contained in the sales line table. In addition, record-level security was enforced only through the client interface.
In Microsoft Dynamics AX 2012, the extensible data security framework can be used to help secure the data. By using the new framework, you can create data security policies that are based on data that is contained in a different table. Data security policies are enforced at the server, regardless of the type of client that is used to access the data. In addition, policies can take security privileges into account. For example, the administrator can grant View access to one subset of sales orders and Edit access to another subset of sales orders.
Warning
The record-level security feature is still available in Microsoft Dynamics AX 2012, but it will become obsolete in a future release. Filters that you previously set up for record-level security can still be used. If you set up new filters, we recommend that you create data security policies by using the extensible data security framework.
Data security that is based on effective dates
In Microsoft Dynamics AX 2012, you can specify whether the users in a role have access to past, present, or future records. A user can also have different levels of access based on effective dates. For example, a user can have access to view past records, and access to create and edit present records.
For more information, see Data security in Microsoft Dynamics AX.
Server enforcement of security
In previous releases, authorization was performed primarily on the client. Therefore, permissions could be validated differently by the Windows client, the Enterprise Portal for Microsoft Dynamics AX client, and other types of client.
The addition of the Table Permissions Framework (TPF) to some tables in Microsoft Dynamics AX 4.0 and Microsoft Dynamics AX 2009 shifted some authorization to the server. However, TPF permissions were applied at the table level, not at the field level. Therefore, TPF could be used to deny users access to whole records, but could not be used to deny access to specific fields that were associated with a record. To limit access to fields, the administrator could set up permissions to show or hide the fields in client forms. However, because all data was sent to the client, tables that were not protected by TPF could be freely accessed by code, regardless of the user's permissions.
In Microsoft Dynamics AX 2012, because TPF permissions can be applied at the field level, more authorization is performed on the server. Therefore, permissions on protected fields are consistently enforced, regardless of the type of client.
For more information, see Manage data access by using the Table Permissions Framework.
Flexible authentication
Since Microsoft Dynamics AX 4.0, user authentication has been based on Active Directory. All users have been required to be domain users. Even external users of Enterprise Portal have had to be domain users. To help secure other data on the network, the administrator had to set up group policies to prevent external users from accessing that data. In Microsoft Dynamics AX 2012, users can be authenticated by using methods other than Active Directory. Therefore, external users no longer require domain accounts to access Microsoft Dynamics AX. For more information, see Deploy an Enterprise Portal site that uses forms-based authentication.