Developers: Prepare for More Security Work When Upgrading to Microsoft Dynamics AX 2012
published November 10, 2011
In a special AXUG Summit breakout session on security, FastPath's Mike Cassady and Arbela Tech's Carsten Glem tackled the thorny issue of maintaining security for Microsoft Dynamics AX. Users and developers in the audience drove the conversation, asking questions about and sharing solutions for problems such as restricting security at the record level, generating comprehensible security reports and testing changes in security profiles.
The most timely part of the discussion honed in on the transition from previous and current versions of AX to 2012. One audience member who plans to upgrade to 2012 asked, "Will security not come up automatically?"
...
Requires FREE Membership to View
Login
Become a Member
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also receive periodic email newsletters with the latest relevant articles and content updates.
This is not good
I'm a little shocked that this is being reported as such, and that the response to customer was what is stated in this article. This is very much a great improvement and not a heavier load on the developer. This is a Fnctional design point, and should be viewed as such.
Follow up coverage
Take a look at our follow up piece on this topic:
http://msdynamicsworld.com/story/microsoft-offers-industry-analysts-new-...
Where we look at Brandon's full response to the topic of designing security policy into the implementation of Microsoft Dynamics AX 2012.
Surprised
I'm surprised how this is being portrayed in this article. Yes, the upgrade path for security is not great, but from where I am standing as a technical implementation consultant, my clients would be happy to throw out their existing setup for something more structured and robust.
Yes, it will take a bit of figuring out how to fit into the existing roles. But even if you need to create new roles, you can pick and choose high-level duties from a list and not fiddle with a mess of security keys and implied inheritance structures.
For upgraded custom code you will need to add security. If your custom code is that heavy that you have a ton of work on security, you will have a tough time upgrading the code itself to 2012 already, and should probably re-evaluate the whole modification anyway, security being a minor detail.
As for new customizations, any good design specifies the restrictions of the modification. There is now a NEED rather than a best practice to specify the security implications of a modification. This is part of a good design, and is an extra step for the analyst writing an FDD. The impact on a developer is minor. If the developer is having to come up with the security model for his modifications, you're on the wrong path.