FrenCo

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.


Recommended reading:
Microsoft Dynamics AX 2012 White Paper: Role-based Security Use Patterns for Developers
Security Development Tool
Install the Security Development Tool

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.