Security roles and authorization in Dynamics AX (Part 3)

Continued from part 2

In theory there is no difference between theory and practice. In practice there is.
No matter how well you plan your authorization, you will run into ad-hoc issues requiring ad-hoc remedies. In part 3 of the series on authorization I’ll share some tips and tricks that might come in handy.

The AX2012 Security Development Tool

Saying that the authorization framework in AX is not very user-friendly is an understatement. The good people in Redmond recognized this fact and built a wonderful tool that makes life a lot easier for us mortals tasked with authorization. In fact, it is so good that Microsoft decided not to make it a part of standard AX2012 (after all, that would make sense).

The tool can be found in the download section of lifecycle services and the documentation mostly consists of liability statements and ‘use at own risk’ signs. There is also a warning that says to not install the tool in your production environment because of performance risks.

Speaking from personal experience, I installed this tool in every AX2012 production environment I worked with (including R3, although Microsoft insists it only applies to AX2012 FP). I never had the slightest problem with it. AX2012 performance is easily crippled, but not by this lifesaver. Of course I have to cover my own ass and tell you that my results are no guarantee. So whatever you do, you do it at your own risk *wink, wink*.

Some of the wonderful things the SDT allows you to do…

Record roles

Click record and let your key-user do his thing. Then click stop and you will receive a list of every access point the user has touched in the process. Can I get a hallelujah!?

Test roles

Yes, you can test roles and you can do so in a virtual environment. How awesome is that? Yes sir, it’s that awesome.
The only downside is that you can only test one role at a time. You cannot see the effect that roles have on each other. Still, its awesomeness rates high in the F-category.

See licensing consequences

Immediately (well immediately…, it’s what the ‘load meta data’ option does and it takes some time) see what the impact of your role is on your licensing. This saves a lot of unpleasant surprises when it is time to run your monthly licensing status. Oh, it also tells you exactly which privileges will cause you to acquire another enterprise license. Maybe that is the main reason that Microsoft never wanted it as part of the standard? Nahhh…

Discover ‘hidden’ entry points

The tool allows you to open all entry points on a specific form. This saves you the (big) trouble of identifying and evaluating every single menu item found on a form. From there you can easily grant or deny access. Incredibly practical for modifying privileges on the fly.

Downsides

There is only one downside to the tool. It makes it really easy to destroy your carefully designed structure (as discussed in part 2). So remember that great responsibility comes with great power. Think carefully and thoroughly about what you are doing.

When things just won’t work…

Every now and then you run into a situation where authorizing an entry point is not enough. Generating documents for example. You can give full authorization to every entry point in the process and still your privilege will not allow your user to generate an invoice.

This caveat is something everyone working with AX authorization runs into and many ~~spend~~ waste quite a bit of time desperately seeking guidance from all-knowing Google. Unfortunately the communities are full of desinformation on this topic.

The reason is that some processes in AX are performed through services. Unlike “normal” functionality, a service doesn’t have anything that resembles an entry point.

To fix the issue you will have to go into the AOT, find the role you mean to grant access and then add the required class and method to the server methods on the permissions node.
Privileges also have a server methods node, but standard security invariably assigns server methods to a role rather than to a privilege. It is therefore safe to assume that Microsoft considers this best practice.

4 thoughts on “Security roles and authorization in Dynamics AX (Part 3)”

Prashant says:

14-09-2020 at 17:02

Hi,

Thank for the information.

But the SDT will not provide the details of external users, who area accessing AX indirectly and are not registered as users in AX, right?

1. Francesco says:
  
  14-09-2020 at 23:34
  
  Hi Prashant,
  
  The SDT deals with roles, not with users. You can create a security role that restricts users from entering certain sensitive areas and assign this role to third party users.
  Of course third party users are often consultants and developers who require an access all areas pass, in which case you may as well hand them an administrator role and rely on their professional discretion.
  
  1. Prashant says:
    
    15-09-2020 at 06:13
    
    Hi Francesco,
    
    Thanks for clearing my doubt.
    
    With all the feature mentioned above SDT does seem to be quite a useful tool but consider the below mentioned scenario and please let me know if SDT can still capture the access points and license requirement.
    
    ‘External users using 3rd party application are using AX, they have access to custom created menu items which have View and Maintain user license assigned as None. By using SDT can we find out which license (CAL) will be required for such users.’
    
    If not, is there any way to do that?
    
    Thanks for all the help
    
    1. Francesco says:
      
      15-09-2020 at 11:10
      
      The SDT shows the license requirement in the role’s metadata. However, I am not quite up to speed with the latest in AX licensing and neither is the SDT. It distinguishes between enterprise users, functional users and task users, and it’s a great help in finding out why a role (!) is responsible for bumping up the licensing requirements for a user.
      
      License requirements in AX2012 are (or were) taken from the entry point, so if you use custom entry points with licensing set to none, that is what you get and I believe these will show up as task users in your license count report. Bear in mind that a role license is determined by its highest valued entry point, so a single entry point might bump up the license requirement from task to enterprise. Same with users, the license is determined by their highest valued role if they have multiple roles assigned.
      
      I recall that MS put an end to that method for obvious reasons and drastically changed the licensing scheme for AX2012 to no longer make the functional/enterprise distinction, but I’m not sure there.