Inside Dynamics AX 4.0: The Security Framework

[Blog bot]

Источник: http://feeds.feedburner.com/~r/Insid...framework.html
==============

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.

Authentication overview

Note
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.
Organizing Security

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

Note
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.
Tip
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:

• No access Members of the user group cannot access the item or any sub-items that the item controls.
• View access Members of the user group are allowed to view the item, but they cannot 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 have full access to the item, and no commands are disabled.
• Members can also provide additional rights in special cases if full access is given to the administration items.

Note
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.
Applying Security
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.
Domains
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.
Note
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.
Note
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.
Note
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:

• Security Windows-relevant security elements, sorted alphabetically
• Security (Incl. Web) All security elements, including Web-specific elements (such as activity centers, deployment options, and cross functions), sorted alphabetically
• Country/Region-Specific Legacy functions relevant for the individual countries and regions, sorted alphabetically
• Main Menu Functions structured according to the main menu within the Dynamics AX application runtime

These elements are the main overview elements, but additional filters will be available if the menu node does not have a parent, such as Task Panes or Tools. This means that customized menus can be presented automatically in the filter, if the preceding criteria are met.

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.
Important
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.
Record-Level Security

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:

• Allowing members of a sales user group to see only the accounts they manage
• Prohibiting financial data from appearing on forms or reports for a specific user group
• Prohibiting account details or account IDs from appearing on forms or reports for a specific user group
• Restricting form and report data according to location, country, or region

When you enable record-level security, you select user groups and the appropriate database table by using the Record Level Security wizard, and then you execute a query that specifies the fields and criteria to be applied. The query criteria are specified using the generic Query form and are added to the individual database table that was chosen with the wizard. Note that record-level security is configured per company, so the wizard and criteria definitions must be executed for each company.
Important
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:

• Using display and edit methods
• Using a FormListControl, FormTreeControl, or TableListControl control to show data
• Using a temporary table as a data source

Whenever a display or edit method is used to return a value from another row, you must evaluate the business impact of displaying this data. If your evaluation shows signs of unwanted information disclosure, you should perform an explicit authorization in X++ code to check permissions before calling these methods. The following code shows an explicit authorization.
Note
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:

• When the value is calculated
• When the value is based only on fields in the current record

http://insidedynamicsax.blogspot.com/
</img> </img> </img> </img> </img>


Источник: http://feeds.feedburner.com/~r/Insid...framework.html