Security 101 in Dynamics AX 2012
Security was a topic that I became well versed in during my years on the Microsoft Dynamics AX support team and as a Partner Technical Consultant for Dynamics AX. Therefore, I wanted to do a series of blog articles covering some things that I have learned. I decided to start by covering the basics of security in Dynamics AX 2012.
Security was completely re-designed in Dynamics AX 2012. This resulted in some benefits such as having out of the box roles to assign users to, but it meant that there was a learning curve to setup security. Another large change to security in Dynamics AX 2012 was the development aspect that was added. While you can maintain security and do some setup of security in the Dynamics AX client, most of the work to create security objects is done in the AOT. So let us look at the nodes under Security in the AOT.
Roles – These are the security roles that you create to assign to users. These are typically going to be created around jobs/positions that exist within the organization. An example of this is the Accounts Payable clerk role.
Duties – I like to think of duties as tasks, specifically the tasks that you would need to do as part of your job/position which are considered roles in Dynamics AX. An example of this would be ‘Maintain vendor invoices’ which is assigned to the Accounts Payable Clerk role.
Privileges – These are the specific forms, reports, etc that a user needs to perform a task and the level of access that is required. Permissions are made up of entry points and the level of access. Entry points are menu items (forms, reports, actions), web, services. An example would be the ‘VendTransMaintain’ privilege that is part of the ‘Maintain vendor invoices’ duty.
Code Permissions – These are used when you have a menu item that is running a method of a class. Code Permissions allow you to specify access levels to forms, tables, web controls, and reports that are related. On example of this would be the VendEditInvoice code permission which deals with the executeTransfer method of the subledgerJournalTransferOperation class. It also involves permissions to the VendEditInvoice form.
Process Cycles – These are used to group duties together so that it is easier to find them when searching in the Dynamics AX client to create or modify a role. For example, let’s say you are trying to add the Approve Vendor Invoices duty to the Accounts Payable Clerk role. It is easy to use process cycles because the find feature is available, as opposed to if you try to use the Duty/privilege view by option as the find is greyed out.
Policies – These are used to restrict what data a user is able to see in a form or report. This is the new method in Dynamics AX 2012 to limit data similar to what you have with record level security. With this feature you create a query with restrictions. Then, you create a security policy that can be applied to a security role. For example, if you wanted to limit your account payable clerks from seeing retail vendors, you could create a query on the vendor group table with a range that limits the retail vendors. You would then create a policy that includes this query and security role.
Now that you have a brief explanation of the security nodes in the AOT you are ready for my next blog articles that cover how to remove a field from a form for certain users.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.