This is the second part of my article about Security roles and authorization in Dynamics AX. Out of the box AX comes loaded with predefined security roles. Isn’t that great? Welllll….no. I never had much use for them, not even as a starting point for bigger and better things. With the possible exception of the CEO there is no such thing as a standard role in any organization.
It is tempting to simply assign standard roles to users until they have all the authorization they require. This satisfies most auditors, your boss and your users.
It is no big secret that Microsoft’s licensing policy is linked directly to user’s authorization. I must admit that I am not up to speed with the latest licensing strategy, but in AX2012 it used to be an issue that the difference between an enterprise license and a functional license was determined by the access points that a user was authorized to use. Some access points are earmarked as ‘exclusive’ and not accessible without an enterprise license. Most (if not all) of the standard roles shipped with AX have one or more of these exclusive access points in them. I have always suspected Microsoft to purposely and knowingly sneak in some of these moneymakers, but that might just be my paranoia.
Keeping a pennywise eye on the granted access can be a real cost saver. How much of that still applies in the year of our lord 2019, I can’t say.
Role-based security
AX distinguishes between role-based security and record-based security. The first is based on access (i.e. what is a user allowed to open/print/execute?), the second is based on content (i.e. what is a user allowed to see?). Only in cases where sensitive data is mixed with general data does it make sense to use record level security. After all, what you cannot access, you cannot see to begin with. Then there are fields which you might want to shield from modification by unauthorized users. This used to be common practice, but to be honest I have not seen it used in a long, long time.
The general structure of (role based) AX authorization consists of roles, process-cycles, duties and privileges. Microsoft pictures it like this
The idea is that a role corresponds to a function in the company (e.g. CEO, CFO, Customer Service, Accounts Payable, etc.).
A process cycle is a common process that is performed by an employee. A role can have more than one process cycle. An Accounts Payable clerk can for example perform an invoice matching process, an invoice payment process, an invoice rejection process, etc. Depending on the size and structure of the organization a role can consist of less or more processes. Smaller companies can even do without an accounts payable clerk all together and just call it financial administration. The same person who does the accounts receivables will then also do the payables.
Roles vs users
It is important to maintain a high-level view when designing your authorization. I often see authorizations designed on a people-scale, but this will quickly turn into a maintenance nightmare and worse so for the person who will have to take over after authorization maintenance gave you a burnout. No matter how small your organization, the (correct) usage of roles is not optional! This means that if Carla is a customer service representative but also helps out with product management in the engineering department and sits in at Finance when Bill has a day off, she requires three different roles for each of these functions, not one single role that attempts to capture Carla.
Also of importance is the sizing of the roles. Do this according to the Goldilocks principle. Each role should be a perfect fit for the process cycle(s) that it holds. Not too small, but definitely not too big either. You don’t need a single roll to do it all. Every user can have as many roles as required to do the job. Assigning multiple roles to a user is easy, splitting an existing role into multiple other roles is a disaster.
So plan ahead. Take inventory of the processes in your organization. Arrange these processes into roles and don’t even worry about users at this point. Of course company processes should be well documented to begin with, so this step should be an easy one, right? (Yea, right!) Next up, duties.
Duties
The concept of the duty in AX represents a part of a process cycle. Say for example ‘creating a payment journal’. This is part of the accounts payable process, but not a process in itself. It is also not a single privilege, because in order to do so, the person performing the duty requires access to journals, bank information, vendor information, open invoices, etc. etc. and so on.
From a narrow perspective you could say that duties in AX serve one purpose and one purpose only, which is to group privileges. If it wasn’t for duties than processes would just be an unorganized collection of many privileges. Of course we like our system structured and well organized, so we will not skip this step. He who doesn’t structure his authorization has forgotten the face of his father. They also proof quite handy in assembling process cycles.
As shown in the diagram above, privileges are not required to be part of a duty or a process cycle but can be assigned directly to a role. This is useful when a privilege is associated with a single task, which is often the case for customizations. It doesn’t make sense to set up a specific process or duty for a single access point.
Privileges
Entry points are menu items, no more no less. Everything in AX is accessed from a menu, even if this doesn’t appear to be so at first sight. When you open a form, you clicked on a menu item. When you start a process, you clicked on a menu item. Even when you click on an item in a menu….
A privilege contains one or more entry points and an associated authorization level (No access, read, update, correct, create ) for each one. Also in a privilege are specific permissions for tables, forms and server methods. This last one is used to authorize specific class methods. It is for example not possible to grant access to posting without including the appropriate class and method in the server method permissions of the privilege (a common source of headaches to those who first wallow in the mire of AX authorization).
So now we have all the ingredients for assembling a state of the art authorization schema. We have our roles, process cycles, duties, roles and permissions. Most important we have a plan (don’t we?!). The plan might change as we go along, but when this happen we will document this for future reference because he who doesn’t document his changes has forgotten the face of his father.
To be continued…