Inside Dynamics AX 4.0: The Security Framework
The security framework within Dynamics AX uses the Microsoft Windows Integrated Security platform and Active Directory directory service to authenticate user or system interactions before they are authorized by the Dynamics AX role-based security. Using 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 but can be shared between multiple Windows users. The application role for the individual Dynamics AX user is determined by the user groups with which the role is associated, and it 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 defines the entire application role. User groups can be shared by multiple Dynamics AX users, as shown in below image.
Windows authentication is the only authentication scheme available in Dynamics AX 4.0. The option to work with the SQL Server authentication, available in earlier versions, no longer exists.
The role-based Dynamics AX security framework is comprised of users, company accounts, domains, user groups, table and field permissions, and record-level security. 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. Subcategories of application modules are structured by using the method that matches the main menu structure.
The flow chart in below image illustrates how authorization is validated for the individual user group and how configuration keys and parent security keys affect the final security access.
Validation of authorization
Configuration keys and parent security keys are element properties that are added to the individual security key. When adding the properties, only one of the two properties can be used 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 makes it easy to relate the main menu items with the security elements when configuring user group permissions.
To simplify the navigation experience, all application modules use category naming.
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:
The security framework presents only the user interface elements that the users have 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.
The process for applying the security framework to the Dynamics AX application includes the following seven steps, which must be performed after the licensing and generic configuration is completed:
1. Create users.
2. Create user groups.
3. Create company accounts.
4. Create domains.
5. Set permissions for user groups and domain combinations.
6. Set table and field access.
7. Set record-level security.
Configuring the security of the Dynamics AX application involves the use of domains. A domain is a collection of one or more company accounts that allow you to define user groups with the same permissions in a company with several subsidiary businesses, while allowing the same user groups to have other permissions within other companies. Domains make it easier to maintain user group security when several companies use the same security profile.
A single company account can belong to more than one domain.
Domains allow great flexibility in the configuration of user group permissions. They can generate a strict security policy, in which each user group in each domain is a distinct entity with absolutely no access between groups or domains, or one user group can have company account access to similar group data, forms, and modules across multiple domains. The latter option simplifies the access configuration of corporate services such as controllers, multi-site planners, human resource functions, and other functions that centralize or share assignments and tasks. In below image illustrates how domains and user groups can work together in multiple ways within the same security framework.
An example of the relationship between domains and user groups
The domain security key SysOpenDomain controls access to information about users, user groups, company accounts, and domains. Using the domain security key in user groups provides access to records in all domains.
Dynamics AX includes only one domain by default: Admin. The Admin domain always includes all companies. It cannot be removed, and no companies can be deleted. Use the Admin domain for any user groups that need access to all companies. When the license key domain is not purchased, domains are still visible and functioning, but access is limited to the Admin domain only.
User Group Permissions
Permissions and user rights are granted to groups, which allows the system administrator to define a set of users that share common security privileges. When you add a user to a group, you give the user all the permissions and user rights assigned to that group. By default, user groups cannot access any menus, reports, forms, tables, or fields in Dynamics AX. User groups can be shared between all Dynamics AX user types: Windows users, Web users, or anonymous users, such as Business Connector users.
A user who is a member of more than one group inherits the highest permissions level of the two groups. A user cannot access the application without being added to at least one user group.
When configuring group permissions, the system administrator works with a hierarchical security tree that represents all the available security keys and includes application module access, individual permission levels, and Help text that explains the security element. The User Group Permissions form allows for configuration of high-level permissions and very detailed permission levels for individual user groups. In below image shows the configuration interface that system administrators work with to assign permissions.
The User Group Permissions form
You can use the User Group Permissions form to display the security elements by selecting one of the following Viewing filters, which are available at the top of the form:
If you set the permission level to Full Control on the parent node key, security key children, menu items, and tables will inherit the same permissions. However, if you set any other permission level, permissions will not be inherited below the parent menu item. If a permission level is required for the entire sub-tree, the Cascade button grants the current permission level when clicked.
If you change permissions for a user group, especially if you demote permissions, you should follow the best practice of instructing all group members to restart their Dynamics AX client, so the permission changes will take effect.
Within any enterprise, some users are restricted from working with certain sensitive data for reasons regarding confidentiality, legal obligations, or company policy. In Dynamics AX, authorization for access to sensitive data is managed via the table-based record level security (RLS) framework that builds on the restrictions enforced by user group permissions. With user group permissions, you restrict access to menus, forms, and reports for group members. The RLS framework allows you to add additional restrictions to the information displayed in reports and on forms. These restrictions are automatically applied by the Dynamics AX application runtime when the application requests data from the database table included in the RLS framework. The restrictions are included by extending the WHERE clause within the SQL statement with the defined RLS query details.
Common uses of record-level security include the following situations:
If an application role that uses multiple user groups has record-level security applied on a certain table within a company account, maximum access is given to the role. For example, if one user group has no record-level security for the Customer table and another user group allows users to see only a subset of the customers, the user will have access to all customers.
The following is the process for enabling record-level security for a user group for a particular database table:
1. Start the Record Level Security wizard.
2. Select a user group.
3. Select tables.
4. Complete the wizard.
5. Mark an available table, and then click Query.
6. Add the query criteria.
By default, the tables in the wizard are presented based on the TableGroup property with the value set to Main, and they are grouped according to the parent security key matching the main menu structures. Setting the value to Main results in a subset of the tables. However, you can expand the selection by clicking Show All Tables.
The RLS framework is automatically invoked by the kernel when criteria has been applied to database tables, but it could require additional work in certain situations, such as the following:
For more security-related information on using display and edit methods, refer to the Microsoft Dynamics AX SDK.
Populating a FormListControl, FormTreeControl, or TableListControl control with data from a query can lead to unwanted information disclosure. In such cases, you must manually activate the record-level security, as shown here.
When the form cache is filled with data from a temporary table, you must ensure that the data conforms to the record-level security. This includes tables declared as temporary in the code, as illustrated in the following code example, and tables in the AOT whose Temporary property is set to Yes.
Record-level security is not required in the following situations:
</img> </img> </img> </img> </img>
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|axStart: Microsoft Dynamics AX 2009 Hot Topics Web Seminar Series||Blog bot||DAX Blogs||0||06.08.2008 12:05|
|Inside Dynamics AX 4.0: Security||Blog bot||DAX Blogs||0||29.10.2007 10:50|
|Inside Dynamics AX 4.0: The Web Framework||Blog bot||DAX Blogs||0||25.10.2007 03:04|
|Inside Dynamics AX 4.0: Usage Scenarios||Blog bot||DAX Blogs||0||04.10.2007 05:15|
|Inside Dynamics AX 4.0: Inside the Business Connector||Blog bot||DAX Blogs||0||04.10.2007 05:15|
|Опции темы||Поиск в этой теме|