The new design is role-based and has been created with the organization's roles in mind, making it a much more natural fit. We can even automate the assignment of security roles based on the user's position in the organization, so by promoting a user to a production manager in human resources, we automatically assign them the appropriate role in the security model.
The security system in AX operates by controlling access to menu items. Much of the security architecture is based on this. When we added form parts, you may have wondered why we don't just drag the part onto the form. It is because we control access to the form part through the menu item, wherever it may appear. This is also why every button we add is linked to a menu item.
Dynamics AX is shipped with many roles controlling access to the standard features, and when we write a new module, we should do the same so that users can simply be assigned a security role. When extending an existing module, we will also need to adjust the security of the standard role to include the new feature(s) so that we can control who has what access, and at what level.
The security model in AX 2012 is broken down into the following structure:
- Process cycles
- Roles
- Duties
- Privileges
- Policies
- Code permissions
The primary structure of the security model includes process cycles, roles, duties, and privileges. We will explore these first, before taking a look at policies and code permissions.
Process cycles contain duties, and each duty belongs to a process cycle. They have no security function, but instead provide a logical grouping for the security administrator that reflects the business process that its duties are part of. If you are to create a new duty, it must be created within a process cycle.
The remaining parts are structured as follows:
- Roles: These contain duties, privileges, permissions, and subroles
- Duties: These contain privileges
- Privileges: These contain entry points and permissions
So, assigning a role effectively boils down to the assignment of privileges, and with them, their entry points and permissions.
Entry points define the access level of entry to AX functionality granted to methods, such as menu items, and services.
Permissions define access to tables, fields, server methods (code that runs on the server tier), and form controls (buttons, fields, or other controls placed on a form).
As part of the solution design, business processes are analyzed along with the roles that perform them. The business processes will then be mapped to AX's system processes. This is used for many purposes, including gap fit level, training plans, testing plans, and so on. This method of analyzing roles and processes also fits nicely into the AX security model, allowing the security model to be designed based on it.
The security model that we design and implement should always be simple to use, following the pattern of the standard roles provided by Microsoft. An important design principle is to think of the users' roles, and not of specific users, which should result in the following outcomes:
- Reduced number of roles
- Less complicated assignment of users to roles
- Roles are easier to maintain, with reduced risk of errors, such as unintended assignment of a privilege to a user
AX is licensed based on named users of a certain type (enterprise, functional, task, and self-service). Based on your organization's requirements, a mix of client access license (CAL) types can be bought.
The user's CAL type is determined by the entry points (effectively, the menu items) to which they have read access or higher. For each menu item, we have two properties that control which license type will be required:
ViewUserLicense: When a user is given read access to this menu itemMaintainUserLicense: When the user is givenUpdateor higher access to this menu item
The CAL type is determined by the highest user license type to which the user is assigned. We are not forced to enter values in these menu item properties, but it would be a breach of the license agreement to create a menu item to open a standard form if we don't match the user license type of the original menu item. Microsoft reserves the right, at their expense, to inspect the system.
For more information, from a system administrator's perspective, please see the book Microsoft Dynamics AX 2012 R2 Administration Cookbook, Packt Publishing.
The first part of the design is to determine the roles and duties of the users who will use our Fleet Management System.
As part of the analysis, the system will be used by the following roles:
- Fleet management supervisor: This is responsible for the vehicle and associated service data, and has full access to fleet management data.
- Fleet management clerk: This is responsible for checking vehicle and service data. It can fully maintain vehicle service records and edit the basic vehicle data. It must not be able to change the vehicle group or status.
- Fleet management service clerk: This is responsible for updating service data. It can create new service records but cannot delete existing records. It can also view vehicle data.
This description gives us the roles and duties, and from these, we can add the necessary privileges to the appropriate duty.
Adding roles is typical when we are extending the reach of Dynamics AX into new areas of our organization. If we are providing new functionality for existing roles within the organization, we may just create duties and privileges and leave it to the security administrator to add the new duties to the appropriate security role.
This goes for privileges too. If we are merely adding a new feature to a form that is part of an existing role's duty, we would just create a privilege for that menu item and add it to the existing duty. The roles that have that duty would automatically get the new privilege.
In our case, we are replacing a paper-based system, so the roles, duties, and privileges are all new. The statement of the roles earlier implied that the roles have certain duties—what they are responsible for. From each role, the duties will be mapped as follows:
|
Role |
Responsible for / duties |
|---|---|
|
Fleet management supervisor |
Maintaining vehicle information Maintaining vehicle service records Maintaining fleet management setup Maintaining vehicle status Maintaining vehicle group |
|
Fleet management clerk |
Updating vehicle information Maintaining vehicle service records |
|
Fleet management service clerk |
Creating and updating vehicle service records Viewing vehicle records |
The requirement of the Maintain vehicle status and Maintain vehicle group duties is implied in the role's description, as it is stated that the fleet management clerk should not have access to these features.
The design of the duties should be granular enough to be able to define the roles' permissions, while limiting the number of duties so that it is easy to maintain. We can add a privilege directly to a role, but this should only be done when absolutely necessary, as it increases the work required to maintain role permissions.
Privileges are related to one or more menu items, and each menu item must be in at least one privilege in order to be accessible to users. This is except for those in the system administrator role, who have full access to the entire system.
As the privilege determines the access level, we will often create at least two privileges for each set of menu items—one for view and one for maintain. The actual levels available are listed here in ascending order:
NoAccess: The menu item will not display on the form.Read: The data opened from the menu item will be read-only.Update: The associated data can be edited, but the user will not be able to create new records.Create: This allows records to be created in the form opened via this menu item.Correct: This allows us to correct time-valid state records. This allows a user to correct time-sensitive data, such as employee information, where a change would normally create a new time-valid record. This is covered in the Exception handling section in Chapter 10, Advanced Development Techniques.Delete: This provides full access and allows us to perform all functions from read to delete to forms opened by this menu item.
When we add menu items to a form, there is a property on the button control called NeededPermission. If the access level on the privilege is less than the NeededPermission property, the button will not appear to the user.
We define a set as the menu items that make up the privilege. Since this is the most granular level, it is common to have privileges with just one menu item. Again, we want to keep this manageable, so if two menu items always have the same permission, they should be in the same privilege.
For further reading on role-based security in AX 2012, visit http://msdn.microsoft.com/en-us/library/gg847971.aspx.