In this chapter, we will cover the following topics:
- Assigning users to roles manually
- Dynamically assigning users to roles
- Creating a model for security
- Creating a new security role
- Adding duties and privileges to a role
- Overriding role permissions
- Setting up record-level security
- Maintaining date-effective policies
- Segregation of duties and mitigating risk
The security system in AX operates by controlling access to menu items (which also includes buttons on forms), data, and business logic. This is greatly simplified by the way security is structured in AX 2012; and many prebaked roles are created so that the users can simply be assigned to a security role.
The security model in AX 2012 is broken down into the following structure:
- Process cycles
- Roles
- Duties
- Privileges
- Policies
- Code permissions
In this chapter, we are concerned with process cycles, roles, duties, and privileges.
They are structured as follows:
So assigning a role effectively boils down to the assignment of privileges.
Process cycles contain duties, and each duty belongs to a process cycle. The process cycle is a logical grouping that helps to organize 1103 duties and 7634 privileges into 10 process cycles. If you are to create a new duty, it must be created within a process cycle.
Entry points are methods to access the AX functionality. Some examples include a link that opens a form from the menu, a button on a form, a service reference, and web links. For each entry point the developer will have assigned the access level.
Permissions define access to tables and fields, server methods (code that runs on the server tier), and form controls (buttons, fields, or other controls placed on a form).
Most of the security design is a development task, and is only covered in so much as to explain what is happening behind the scenes. As administrators we are primarily concerned with assigning roles, duties, and privileges to users.
As part of the implementation, business processes were analyzed along with the roles that perform them. The business processes will then be mapped to AX system processes, which 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 this.
The security model that you design and implement should always be simple to use, using standard roles where possible. You are free to design your own roles if your processes do not align with AX's. An important design principle is to think of the users' roles, and not think 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, unintended assignment of a privilege to a user
As discussed in Chapter 2, Working with Licensing in AX 2012, AX is licensed based on the 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 was bought.
The user's CAL type is determined by the entry points (effectively menu items) to which they have view access or higher access. Therefore, view access to a set up form might require a functional client access license, but edit or higher access may require an enterprise client access license.
Note
The default access levels of a role are published by Microsoft. Please refer to Appendix, Further Reading for further information.
It is surprising to know that the system doesn't stop you from assigning more users than you have purchased to any given type of CAL. But remember that Microsoft can request access to the system to check this, and your license terms state that you must submit the named user report to Microsoft upon request.