The security framework within Dynamics AX
uses Integrated Windows authentication and Active Directory to
authenticate user and system interactions before they are authorized by
the Dynamics AX security framework. Using Integrated Windows
authentication allows automatic logon to the Dynamics AX application
without collecting user name and password information.
A
Windows-authenticated user can be associated with only one Dynamics AX
user. The application role for the individual Dynamics AX user is
determined by the user groups with which the role is associated. The
application role also defines the user interface actions that a user is
authorized to perform and the data that the user is authorized to view
and modify. You can create an application role by adding all the
necessary functionality to one user group, or you can
create a collection of user groups that define the entire application
role. A user group can contain multiple Dynamics AX users, and each
Dynamics AX user can be part of multiple user groups, as shown in Figure 1.
Note
Integrated
Windows authentication is the only authentication scheme available in
Dynamics AX 4.0. The option to work with the SQL Server authentication,
available in versions earlier than 4.0, no longer exists. |
Organizing Security
The
Dynamics AX security framework is composed of users, company accounts,
domains, user groups, table and field permissions, and record level
security. The organization of application security in Dynamics AX is
associated with security keys and their relationships with menu items,
form controls, tables, and fields, which together operate as the
connection layer between the application logic and the application role
configuration. The security keys reduce the complexity of setting up
the overall security of individual user groups per domain because the
references to configuration keys can remove unused functionality.
Parent security keys can enable or disable entire application modules
for user groups. Subcategories of application modules are structured by
using the method that matches the main menu structure.
The flow chart in Figure 2
illustrates how authorization is validated for an individual user group
and how configuration keys and parent security keys affect the final
security access.
Note
Configuration
keys and parent security keys are element properties that are added to
the individual security key. When adding the properties, you can use
only one of the two properties at a time because a configuration key
indicates that the security key is the parent, and the parent property
indicates that the security key is a subcategory. |
When
you create security keys, the parent security keys function as the
application module keepers for the underlying child security key
categories: Daily, Setup, Journals, Inquiries, Reports, Periodic,
Miscellaneous, and Tables. These categories define the user interface
for the substructure of the application module within the Dynamics AX
main menu. This arrangement makes it easy to relate the main menu items
with the security elements when you’re configuring user group
permissions.
Tip
To simplify the navigation experience, use category naming for all application modules. |
The
security keys control the initial permission levels to functionality
within the application, but they depend on the menu items and the table
permissions framework for detailed security configuration. The
permissions are assigned to user groups within their corresponding
domains using the following five permission levels:
No access Members of the user group can’t access the item or any subitems that the item controls.
View access Members of the user group are allowed to view the item, but they can’t use it.
Edit access Members of the user group are allowed to view and use the item.
Create access Members of the user group are allowed to view and use the item, and they can also add new items.
Full control
Members of the user group are allowed to view the item, but they can’t
create, delete, or edit. Members can also provide additional rights in
special cases if full access is given to the administration items.
If
you set the access level for a menu item or security key to full
control, all children of the selected node are automatically set to
full control. If you set the access level to anything other than full
control, the children do not inherit the permissions automatically. In
such cases, you can use the cascade functionality by clicking the
Cascade button. Clicking the Cascade button automatically grants the
same access level to all the nodes in the subtree under the node.
Note
The
security framework presents only the user interface elements that the
user has access to, and it handles the appropriate access level for
individual users. Security is applied on the user interface, which is
the user’s entry to the application through menus, menu items, reports,
and forms. |
Permission
levels are assigned and accessible from the user group permission form,
which facilitates the entire permission assignment process beyond
simple node creation.
