Authentication is the process of establishing the user’s identity. Microsoft Dynamics AX users can be authenticated in two ways. The first way is through the use of Integrated Windows Authentication to authenticate Active Directory users. This can be accomplished by either making a specific Windows user a Microsoft Dynamics AX user, or by making an entire Active Directory group a user within Microsoft Dynamics AX. After the Active Directory group is added as a user within Microsoft Dynamics AX, any user who belongs to that Active Directory group can access Microsoft Dynamics AX. The ability to add an Active Directory group as a user within Microsoft Dynamics AX is new for Microsoft Dynamics AX 2012.

The second way of authenticating a user is called flexible authentication, which is also new in Microsoft Dynamics AX 2012. With flexible authentication, a user can be authenticated to use the Microsoft Dynamics AX Enterprise Portal web client without requiring Active Directory credentials. Flexible authentication uses claims-based authentication to verify users in Enterprise Portal. For more information, see the white paper “Flexible Authentication in Microsoft Dynamics AX 2012,” at http://www.microsoft.com/en-us/download/details.aspx?id=29050.

After a user connects to Microsoft Dynamics AX, the user’s authorization within the system is determined. Authorization is discussed in the next section.

Authorization, also referred to as access control, determines whether a user is permitted to perform a given action. In the Microsoft Dynamics AX application, security permissions are used to control access to individual elements of the application: menus, menu items, action and command buttons, reports, service operations, web URL menu items, web controls, and fields in both the Microsoft Dynamics AX 2012 Windows client and in Enterprise Portal.

In Microsoft Dynamics AX 2012, the new security model follows the principles of role-based access control. This security model is hierarchical; each element in the hierarchy represents a different level of detail, starting with permissions, which are at the bottom:

Figure 11-2 shows the elements of role-based security and their relationships.

Figure 11-2. Elements of role-based security.

The following sections explain the elements of the security model in more detail.

As mentioned earlier, Microsoft Dynamics AX 2012 introduces a new extensible data security framework (XDS) that you can use to control access to transactional data by assigning data security policies to security roles. Data security policies can restrict access to data, based either on the effective date or on user data, such as the sales territory or the organization that a user is assigned to.

In addition to the XDS, you can use record-level security to limit access to data that is based on a query. However, because the record-level security feature is being deprecated in a future release of Microsoft Dynamics AX, it is recommended that you use the XDS instead.

Additionally, Microsoft Dynamics AX has a table permissions framework to protect data. The table permissions framework allows enforcement of data security for specific tables by the Application Object Server (AOS). Explicit authorization checks are performed when a user tries to access data related to tables protected by the table permissions framework.

You build security from the ground up, beginning at the form level. The first step is to control access to the data in a form. When you save a form in the AOT, Microsoft Dynamics AX automatically discovers all of the tables and other items that the form accesses. This functionality is called auto-inference. Auto-inference simplifies configuring table permissions. Based on tables that are used in the form, create, read, update, and delete (CRUD) permissions are set automatically for that form. The system automatically adds or updates the Read, Update, Create, and Delete nodes in the AOT under AOTForms<FormName>Permissions.

Figure 11-3. Security artifacts in the AOT.

Figure 11-4 illustrates the set of permissions for the AgreementClassification form.

Figure 11-4. Read permissions for the AgreementClassification form.

While auto-inference automatically sets the permissions properties for the data sources, you can also set the permissions for a data source manually.

For example, in the Read permissions shown in Figure 11-4, the properties for the AgreementClassification table are set by auto-inference, as shown in Figure 11-5.

Figure 11-5. AgreementClassification table properties set by auto-inference.

The SystemManaged property is set to Yes. However, you can change the EffectiveAccess property to something other than Read. In that case, the SystemManaged property changes to No. This indicates to the security framework that you have chosen to override manually the value set by auto-inference, as shown in Figure 11-6.

Figure 11-6. AgreementClassification table properties set manually.

So far, this section has discussed individual permissions under the Tables node. However, you can also set permissions for additional nodes, such as Controls, Server Methods, and Associated Forms.

An associated form comes into play when the parent form—in this example, the AgreementClassification form—contains a button that opens another form. In such cases, you should add permissions so that the associated form is accessible to users of the parent form. You can accomplish this by referencing the associated form under the Associated Forms node.

When a user has access to a form, by default, the user has access to all of the controls on the form. You can override the default settings by adding permissions nodes for individual controls. You can do this by using the Controls node.

If a server method is tagged with the attribute SysEntryPointAttribute, users must have explicit access to that method. If such a server method is invoked through a form, you can control access by adding the method to the Server Methods node and explicitly setting the permission to invoke. Any role that provides access to that form through the appropriate permission—in this example, read—also grants permission to the server method.

When you develop a form, Microsoft Dynamics AX provides the ability to add controls to the form as securable objects. These can either be data-bound to the form or unbound. All data-bound controls are configured automatically with security, whereas unbound controls can be managed through code. Security in an unbound control, such as a menu function button, is linked to the referenced object and visibility is controlled through permissions on the referenced object.

After you specify permissions, the next step is to create privileges. As mentioned earlier, a privilege is a set of permissions that provides access to securable objects. By using auto-inferred table permissions and securing menu items with privileges, you control access to the data in a form. The following example (Figure 11-7) links the entry point to the form with the associated permissions.

Figure 11-7. Linking a form with permissions.

In this example, the privilege AccountDistCustFreeInvoiceMaintain contains an entry point, AccountingDistCustFreeInvoice. This is a menu item that, in turn, points to a form. Note that in the properties, AccessLevel is set to Delete. This implies that when a user accesses the form through this particular menu item, the Microsoft Dynamics AX security framework will look under the PermissionsDelete node for that form and grant access to the tables that are listed under that node. This example illustrates how the system ties together the privileges, entry points, and permissions and determines the access that the user should have if he or she has access to that privilege through a security role.

A menu item provides an entry point for opening a form. Security properties on the menu item control which sets of form permissions are available to select when privileges are assigned to the menu item.

Each menu item has the following security properties:

These properties refer to the nodes under AOTForms<FormName>Permissions. For example, the UpdatePermissions property refers to the node AOTForms<FormName>PermissionsUpdate.

Table 11-1 describes the values for these permission properties.

For example, if the ReadPermisssions property on a menu item is set to No, the menu item will not pick up the ReadPermissions property from the form that the menu item references. You can use this method to add a permission to a menu item without affecting the permissions to securable objects that are available through that menu item. This helps restrict the permissions that a system administrator can issue for the menu item when assigning it to a privilege.

In some situations, a menu item points to a class or a service operation directly. In this case, you would need to link to a class, which itself is not associated with any permissions. In such cases, you need to use a code permission. A code permission is a group of permissions that are associated with a menu item or a service operation. If you want to run code directly through a menu item, you must set a code permission for it. Code permissions are also represented as a node within the AOT. When a security role grants access to a menu item, the role also has access to other AOT items that are listed within the code permission for the menu item. The access level is controlled by the permissions that are set under the Code Permissions node.

Microsoft Dynamics AX uses the concept of a permission union. If multiple permissions are specified for the same object through multiple privileges and roles, the access on the object is the result of the union of those permissions. For example, if one privilege provides read access to a table and another privilege provides delete access to the same table, and both of them belong to a security role, a user who is assigned to the security role will get delete access to the table.

After you generate permissions for the various securable objects, you grant access to those securable objects through security roles. The first step is to create privileges, as described in the previous section. You can then either incorporate these privileges into duties or directly assign them to security roles.

In Figure 11-8, the privilege AccountingDisCustFreeInvoiceMaintain contains the entry point AccountingDisCustFreeInvoiceMaintain.

Figure 11-8. A privilege containing an entry point.

The entry point is associated with an access level that is specified in the properties (Figure 11-9). Note that in this case, the access level is set to Delete. This implies that when the user accesses the entry point, the system will look in the PermissionsDelete node for the form that the entry point launches.

Figure 11-9. Properties for an entry point.

While it is not mandatory that a privilege be assigned to a security role through a duty, doing so lets the system administrator maintain the privileges through a higher level of abstraction and also lets the system administrator use segregation of duties to meet segregation of duties requirements.

In Figure 11-10, the CustInvoiceCustomerInvoiceTransMaintain duty contains the AccountingDisCustFreeInvoiceMaintain privilege.

Figure 11-10. A duty that contains privileges.

Continuing with the example, notice how the CustInvoiceCustomerInvoiceTransMaintain duty is present within the CustInvoiceAccountsReceivableClerk role in Figure 11-11.

Figure 11-11. Duties within a security role.

A valid time state table helps you simplify the maintenance of data for which changes must be tracked at different points in time. For example, the interest rate on a loan might be 5 percent for the first year, and 6 percent for the second year. During the second year, you still want to know that the rate was 5 percent during the previous year.

You can set the ValidTimeStateFieldType property on a table in the AOT to make the table a valid time state table. Setting this property causes the system to automatically add ValidFrom and ValidTo columns, which track a date range in each row. The system guarantees that the values in these date or date-time fields remain valid by automatically preventing overlap among date ranges. Data tracked by this type of table is referred to as date effective.

Properties on security roles control access to date-effective tables. In the AOT, you can set the properties PastDataAccess, CurrentDataAccess, and FutureDataAccess. By default, these properties are set to Delete, which, in effect, means that the tables are not date effective. However, if one of these properties is set to a value other than Delete, the property specifies the level of data access for the tables with date-effective fields that are secured by the security role. For example, if a table normally has edit access within the security role and you set the PastDataAccess property to View, the user can edit current and future data but can only view past data.

Microsoft Dynamics AX users are either internal employees of your organization or external customers and vendors who require access to Microsoft Dynamics AX for their jobs. Any individual who must access Microsoft Dynamics AX must be added to the list of Microsoft Dynamics AX users in the Users form (System Administration > Common > Users > Users).

Among other options on the form, there is a field called Account Type. You must select whether the user or group is authenticated by Active Directory or by a claims-based authentication provider. For Active Directory, the choices are between adding an individual Active Directory user or an Active Directory group as a user.

After you create a user within the system, you can assign the user to a security role, either manually or automatically.

You can set up rules for automatic role assignment to guarantee that role membership is based on current business data. If you use automatic role assignment, permissions are updated automatically when people change jobs in an organization. Rules for automatic role assignment run at a fixed interval by using the batch framework. As part of setting up the rule, you specify a query from the list of queries in the AOT to use as a basis for the rule. For more information, see Chapter 18.

You can assign roles manually when role membership cannot be based on data in Microsoft Dynamics AX. For example, you can assign roles manually if an employee goes on vacation and another employee must perform that employee’s duties temporarily. Users who are assigned to security roles manually must also be removed manually by the system administrator. These users are not removed from roles by rules for automatic role assignment.

As mentioned earlier, security or policies might require that specific tasks be performed by different users.

In Microsoft Dynamics AX, when two duties in the same role conflict, or when a user is assigned to two roles that contain conflicting duties, the conflict is logged. You must approve or reject each assignment that causes a conflict. For more information, see “Identify and resolve conflicts in segregation of duties,” at http://technet.microsoft.com/en-us/library/hh556858.aspx.

Before developing a data security policy, you need to become familiar with several concepts, such as constrained tables, primary tables, policy queries, and context. This section outlines these concepts. Subsequent sections use these concepts to illustrate how they work together to provide a rich policy framework.

Developing an extensible data security policy involves the following steps:

Figure 11-12 shows how the VendProfileAccount policy is represented within the AOT. Security policies appear under the SecurityPolicies node.

Figure 11-12. Security policy in the AOT.

Figure 11-13 shows the properties for this policy.

Figure 11-13. Properties for a security policy.

Note how the following properties are set on the policy in Figure 11-13:

Complex and normalized data models can lead to queries with a large number of joins, which can affect performance. However, in many cases, a significant portion of the policy query retrieves static data, such as the legal entities for the user and the departments to which the user belongs. The XDS provides a way by which this static data can be retrieved less frequently (ranging from once each time the table is accessed to once for each client session) and then reused in subsequent policy applications. This mechanism is called extensible data security constructs.

Extensible data security constructs are tables of type TempDB that are populated according to the RefreshFrequency system enumeration value of that table (PerSession or PerInvocation). They exist in the AOT under the Data DictionaryTables node.

Figure 11-14 shows an example of an extensible data security construct.

Figure 11-14. An extensible data security construct.

The temporary table that is used for the extensible data security construct is written by using a table method named XDS. You can use this method to write X++ logic to populate the temporary table. In Figure 11-14, MyLegalEntitiesForRole is the extensible data construct that is populated by using the XDS method. The logic within the method populates the table with the legal entities that a given user has access to in the context of a role. The HcmXdsApplicantLegalEntity query is an example of a policy query that uses the MyLegalEntitiesForRole construct. The HcmXdsApplicantLegalEntity query involves joins among four data sources. The fourth data source is the MyLegalEntitiesforRole construct, which encapsulates several joins. If this XDS method sets the frequency to PerSession, this TempDB table will be populated the first time this table is referenced in any query at run time. If an extensible data security construct were not used, this query would have involved joins across four more tables on every policy application—a significant performance overhead.

In this scenario, using an extensible data security construct converts a policy query with seven or more joins into a policy query with four joins—a significant performance gain.

One of the common issues reported when a customer deploys a new extensible data security policy is that an unexpected number of rows are returned from a constrained table.

The XDS provides a method for debugging problems such as this. The X++ select query has been extended with the generateonly command, which instructs the underlying data access framework to generate the SQL query without actually executing it. You can retrieve the generated query by using simple method calls.

The following job runs a select query on the SalesTable table with a generateonly command. It then calls the getSQLStatement method on the SalesTable table and generates the output by using the info method.

static void VerifySalesQuery(Args _args)
{
SalesTable salesTable;
XDSServices xdsServices = new XDSServices();
xdsServices.setXDSContext(1, ''),
//Only generate SQL statement for custGroup table
select generateonly forceLiterals CustAccount, DeliveryDate from salesTable;
//Print SQL statement to infolog
info(salesTable.getSQLStatement());
xdsServices.setXDSContext(2, ''),
}

The XDS further eases the process of advanced debugging by storing the query in a human-readable form. This query and others on a constrained table in a policy can be retrieved by using the following Transact-SQL (T-SQL) query on the database in the development environment (AXBDEV in this example):

SELECT [PRIMARYTABLEAOTNAME], [QUERYOBJECTAOTNAME],
[CONSTRAINEDTABLE], [MODELEDQUERYDEBUGINFO],
[CONTEXTTYPE],[CONTEXTSTRING],
[ISENABLED], [ISMODELED]
FROM [AXDBDEV].[dbo].[ModelSecPolRuntimeEx]

The query results are shown in Figure 11-15.

Figure 11-15. Results from a query on a constrained table.

As you can see in Figure 11-15, the query that will be appended to the WHERE clause of any query to the AssetBook table is available for debugging. Other metadata, such as LayerId, is also available if needed.

When developing policies, keep the following principles in mind:

Note that when multiple policies apply to a table, the results of the policies are concatenated with AND operators.

The table permissions framework provides security for tables that are located in the database and available through the AOT. The AOSAuthorization property on a table (Figure 11-16) specifies the operations that must undergo authorization checks when a given user accesses the table.

Figure 11-16. The property sheet for a table.

The AOSAuthorization property is an enumeration. Table 11-2 lists its possible values.

In addition to the AOSAuthorization property, you can add additional rules for validation by using the following table methods:

Microsoft Dynamics AX 2012 also introduces a new class for authorization checks. Use the SysEntryPointAttribute class to indicate which authorization checks are performed for a method that is called on the server. When you use this attribute to decorate a method, an authorization check occurs when the class method executes on the server tier.

Additionally, you can add further checking on the basis of the value used in the constructor of the SysEntryPointAttribute class, as described in Table 11-3.

Microsoft Dynamics AX 2012 also provides the capability to do server-side trimming. On tables whose AOSAuthorization property is set to CreateReadUpdateDelete, the AOSAuthorization property on individual fields can be set to Yes or No. The default value of this property is No. A value of Yes indicates that authorization checks are performed on read and write operations on the field.

If the AOSAuthorization property is set to Yes for a field and the user does not have access to the field, the value of the field is not returned to the user. This enforces server-side trimming of the data.

The code access security (CAS) framework provides methods that can secure application programming interfaces (APIs) against invocation attempts by untrusted code (code that doesn’t originate in the AOT). You can make an API more secure by extending the CodeAccessPermission class. A class that is derived from the CodeAccessPermission class determines whether code accessing an API is trusted by checking for the appropriate permission.

To secure a class that executes on the server tier, follow these steps:

When you secure an API by using this procedure, you must call the assert method in the derived class prior to invoking the API. Otherwise, the exception::CodeAccessSecurity exception is thrown.

The Best Practices tool can help you validate your application logic and ensure that it complies with the Trustworthy Computing initiatives. The rules that apply to Trustworthy Computing are grouped under General ChecksTrustworthy Computing in the Best Practice Parameters dialog box, as shown in Figure 11-17. The Best Practice Parameters dialog box is accessible from the Development Workspace: On the Tools menu, point to Options > Development, and then click Best Practices.

Figure 11-17. Best Practice Parameters dialog box with Trustworthy Computing rules.

For more information about the Best Practices tool, see Chapter 2.

To assist with debugging security constructs, shortcut menus are available in the AOT on some security nodes to help you find objects and roles that are related to a particular security construct. Depending upon where you are looking in the security hierarchy (Figure 11-2), you have the option to view items up or down the hierarchy. For example, for a given duty, you can see all of the roles that the duty belongs to and all of the related privileges and other security objects that are contained within the duty. You can use this information to debug issues related to access levels of various securable objects.

Here is an example of how you can use this feature for a duty:

Figure 11-18. Security objects for a role.

Note that when you view the related security objects for a role, you also have the option to view the effective access (as highlighted in Figure 11-18) that the role provides to the objects that the role is securing. For example, if the role grants read access to a table through one privilege and delete access through another, the effective access on the table is delete. Therefore, the View Effective Access Results would list that table with delete permissions.

Table 11-4 lists the menu options that are available for various AOT artifacts. The left column of the table lists the nodes that appear in the AOT. The other columns list the menu options.

SecurityUtil::sysAdminMode(true);

License codes are at the top of the configuration hierarchy, which is the entry point for working with the configuration system that surrounds all of the application modules and system elements that are available within Microsoft Dynamics AX. The configuration system is based on approximately 300 configuration keys that enable and disable functionality in the application for the entire deployment. Each configuration key controls access to a specific set of functions; when a configuration key is disabled, its functionality is removed automatically from the user interface (note that the database schema is not modified, unlike in Microsoft Dynamics AX 2009). The Microsoft Dynamics AX run time renders presentation controls only for items that are associated with the active configuration key or items that are not associated with any configuration key.

The relationship between license codes, configuration keys, and feature sets is hierarchical. An individual license code not only enables a variety of configuration keys, but it also hides configuration keys and their functions throughout the entire system if the associated license code is not valid or not provided. Hiding configuration keys with unavailable license codes reduces the configuration complexity. For example, if a license code is not entered or not valid in the License Information form, the Configuration form hides configuration keys associated with it and displays only the valid license codes and the configuration keys that depend on them. Figure 11-20 shows a typical configuration hierarchy for implementations.

Figure 11-20. Configuration hierarchy.

The application modules and the underlying business logic that license codes and configuration keys enable are available when Microsoft Dynamics AX is deployed. By default, all license codes are enabled; however, only minimal sets of configuration keys are enabled. During setup, system administrators should enable additional configuration keys as required. Within the product, everything from forms, reports, and menus to the Data Dictionary are always present, existing in a temporary state until those feature sets are enabled.

When you enable a configuration key, the feature set associated with that configuration key is enabled. This means that appropriate menu items, submenu items, tables, buttons, and fields are enabled when the configuration key is enabled. A user has access only to those areas that the system administrator has granted access to through security roles and that has been enabled by the configuration key. The parent configuration keys shown in Figure 11-20 are associated with a license code. Removing the license code disables those parent and child configuration keys. If the license code is not disabled, system administrators can enable or disable child configuration keys, thus enabling or disabling the feature sets that they represent.

Figure 11-21. Configuration form.

As a more detailed example, consider a company that wants most of the functionality in the Trade feature set, but it doesn’t do business with other countries/regions. The company, therefore, chooses to not enable the Foreign Trade configuration key, which is a child of the Trade configuration key.

By using the configuration key flowchart shown in Figure 11-22, a system administrator can determine whether a configuration key is enabled, and if not, what it would take to enable it, which depends on the configuration key’s parent.

Figure 11-22. Configuration key flowchart.

An important part of the application development process is mapping extensions to configuration keys that integrate the extensions into the complete solution. Correctly using configuration keys throughout the system can make enterprise-wide deployments flexible and economical, with divisions, regions, or sites all using the same deployment platform and customizing local deployments by using configuration keys rather than by developing specific customizations for each installation. You can’t entirely avoid individualized development, however, because of the nature of businesses and their development needs.

Configuration keys affect the Data Dictionary, the presentation, and the navigation infrastructure directly, meaning that you can reference a configuration key property on all relevant elements. Table 11-5 lists the elements that can be directly affected by configuration keys.

The new licensing model, Named User license, provides customers with the ability to use all of the feature sets but provides pricing that is based on the number of users who are using a particular feature instead of pricing that is based on whether a particular module is enabled. In this licensing model, there are four tiers of CALs. Customers are required to comply with Microsoft’s licensing terms based on the access rights granted to each user. The following four tiers (user types) are available, listed from highest to lowest level of access (with sample activities):

All predefined security roles that are included with Microsoft Dynamics AX 2012 belong to one of these four user types, thus giving you the flexibility to license users based on how they are likely to use and derive value from the solution.

The CAL (or user type)-to-security-role mapping is accomplished by first setting the menu item properties ViewUserLicense and MaintainUserLicense with appropriate user type enumeration. Then, through the security hierarchy, the highest level of user type is evaluated, which essentially becomes the effective user type for the role, as shown in Figure 11-23.

Figure 11-23. Security hierarchy and user types.

As shown in Figure 11-23, Microsoft Dynamics AX 2012 maps a set of menu items to predefined roles by using the security hierarchy. The properties of those menu items are also set with one of the four user-type values. Each user-type value provides the rights to perform actions that only that user type can do. The user type that is required for a given user is determined by the highest level of types among menu items to which that individual has access. For example, to add new workers (access the HcmWorkerNewWorker menu item), the Functional user license is required. Thus, the privilege HCMWorkerEdit has an effective user type of Functional, even though it contains the menu item HcmWorker, which is of type Task. Similarly, the highest level of user type flows through the security hierarchy and eventually becomes the effective user type for the role. In this example, the Functional user type is the highest type within the Human Resource Assistant role, so the user assigned to the role requires a Functional user license. That user also has license rights to perform actions that are designated to lower user types (such as Task or Self-serve).

Given that Microsoft Dynamics AX 2012 uses a security hierarchy and menu items to determine licensing requirements, there are several situations in which customization might affect these requirements.