2. 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 company accounts.
|
2. | Create domains.
|
3. | Create user groups.
|
4. | Create users.
|
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 a 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.
A domain 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 it can allow one user group 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, multisite planners, human
resource functions, and other functions that centralize or share
assignments and tasks. Figure 3 illustrates how domains and user groups can work together in multiple ways within the same security framework.
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 can’t 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 isn’t purchased, domains are
still visible and functioning, but access is limited to the Admin
domain. |
User Group Permissions
Permissions
and user rights are granted to groups, allowing 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 can’t access any menus, reports, forms, tables, or fields in
Dynamics AX unless the administrator grants them access. User groups
can be shared among all Dynamics AX users.
Note
A
user who is a member of more than one group inherits the higher
permission level of the two groups. A user can’t 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 you to configure high-level permissions
and very detailed permission levels for individual user groups. Figure 4 shows the configuration interface that system administrators work with to assign permissions.
You
can use the User Group Permissions form to display the security
elements by selecting one of the following Viewing filters, which are
available near the top of the form:
Security Windows-relevant security elements, sorted alphabetically
Security (including 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 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 are
available if the menu node doesn’t have a parent, such as Task Panes or
Tools. If the preceding criteria are met, you can present customized
menus automatically in the filter.
If you
set the permission level to Full Control on the parent node key,
security key children, menu items, and tables inherit the same
permissions. However, if you set any other permission level,
permissions are not inherited below the parent menu item. If a
permission level is required for the entire subtree, 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 instruct all group members to restart the
Dynamics AX client so that the permission changes take effect. If a
group member doesn’t restart his or her instance of the client, you
should use the Online Users form, found in the Administration module,
to kill the user’s session. Keep in mind that killing a session through
the Online Users form immediately terminates the session, so if the
user has open transactions, they are rolled back. |
Record Level Security
Within
any enterprise, some users are restricted from working with certain
sensitive data because of 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. The Dynamics AX application runtime automatically applies
these restrictions when the application requests data from the database
table included in the RLS framework. You include the restrictions 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 you chose with
the wizard. 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 Customer table, the user has
access to all customers. |
Use the following 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
kernel automatically invokes the RLS framework when criteria have been
applied to database tables. In certain situations, such as those in the
following list, you might need to do additional work to invoke the RLS
framework:
When using display and edit methods
When using a FormListControl, FormTreeControl, or TableListControl control to show data
When using a temporary table as a data source
Whenever
you use a display or edit method to return a value from another row,
you must evaluate the business impact of displaying the data. To avoid
displaying particular information, you need to perform an explicit
authorization in X++ code to check permissions before calling these
methods. The following code shows an explicit authorization.
if (hasSecurityKeyAccess(securitykeyNum(mySecurityKey), AccessType::View))
{
myMethod();
}
if (hasMenuItemAccess(menuItemDisplayStr(myMenuItem), MenuItemType::Display)))
{
myMethod();
}
DictTable dictTable = new DictTable(tablenum(myTable));
if (dictTable.rights >= AccessType::Insert))
{
myMethod();
}
if (isConfigurationkeyEnabled(configurationkeyNum(myConfigurationKey))
{
myMethod();
}
|
Note
For more security-related information on using display and edit methods, refer to the Microsoft Dynamics AX 2009 SDK. |
If you don’t want to display certain query data that populates a FormListControl, FormTreeControl, or TableListControl control, you must manually activate record level security, as shown here.
public void run
{
CustTable custTable;
super();
// Ensure that record-level security is used.
custTable.recordLevelSecurity(true);
while select custTable
{
listView.add(custTable.name);
}
}
|
When
the form cache is filled with data from a temporary table, you must
ensure that the data conforms to the record level security you’ve set.
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.
public void run
{
CustTable custTable, tmpDatasource;
;
// Ensure that record-level security is used.
custTable.recordLevelSecurity(true);
while select custTable
{
tmpDataSource.data(custTable);
tmpDataSource.insert();
}
formDataSource.setTmp();
formDataSource.checkRecord(false);
formDataSource.setTmpData(tmpDatasource);
super();
}
|
Record level security is not required in the following situations:
