AX 2012 Security Unwrapped Series - Implementation Approach

This post will discuss a implementation methodology approach to use for implementing AX 2012 security.

Dynamics AX 2012 security requires you to assign roles to users for their access to Dynamics AX 2012.  Microsoft has created standard roles which are comprised of duties and privileges.  These standard roles are the various functions within an organization and includes all the AX functions that are needed to perform the responsibilities of their job role.

Treat these standard roles as your templates or building blocks to create the security model for your specific organization.  To refresh yourself please read my entry in the unwrapped Security series, AX 2012 Security Unwrapped Series - Understanding Role Based Security.

Dissect your company and break it down into functional areas or responsibilities.  Then using the standard roles that Microsoft has provided in Dynamics AX, build your custom roles.  Here are some rules to follow:

• You may find that the standard role is a subset of what is needed for a role you want to build.  In this case, embed the standard role into your custom role.  
• If you find that the standard role has a few duties or privileges that you don't want to include, then I would recommend cloning the standard role and remove the few items that should not be included.  Then embed this cloned/modified role.  Name this cloned role so that you remember and reference it back to the standard role.
• If none of the standard roles suits your need, then create a custom role and add the duty and privileges manually that are needed.

Traversing through the Security menu and how to use the functions is discussed in detail in the 2nd entry in the unwrapped Security series, AX 2012 Security Unwrapped Series - Explaining Security Menu.  This will allow you to create roles using the user interface.  A note of warning, roles are AOT security objects and will create an object in the AOT.  So depending on the layer you've logged into, will define what layer in the AOT the object will reside.  Generally, users log into the USR layer.  However IT individuals, particularly developers have access to the CUS layer.  Check out my blog post titled "Whose code prevails...peeling the onion!" to understand the code layers.  If you choose to make this a developer task, they can create and maintain the custom roles in the AOT.  However instead of referring to the objects by their Name, you will need to know the AOT name.  The steps are very similar.  Embedding roles is done by adding a subrole.  You can add permissions via the AOT, something that you can't do directly in the standard user interface.

Creating your security model should be an integral part of your AX 2012 implementation project.  Below a high level summary of an implementation project and where developing of your security model should be interleaved.  The approach is a progressive methodology approach.  Treat your roles as any other development, logging issues during testing and solving them by updating your roles.

The Security Development tool will help you research what access is allowed by role, duty, or privilege.  Review my post, AX 2012 Security Unwrapped Series - Security Development Tool, for a detailed description how this tool works.  If you have access to the AOT review the post, AX 2012 Security Unwrapped Series - Security Add-In Features, can offer you some additional tools to determine security objects  you need.