4 mins read

Dynamics AX 2012: Role based security framework

In addition to many new frameworks that are introduced in the current release of Microsoft Dynamics AX (a leading ERP of Microsoft Business Solution suite), role based authorization framework is one of the key elements that would make the life of AX 2012 customers and vendors easier. Though the security rights and user access management has been an integral part of all enterprise level software systems, it becomes more significant when it comes to business applications. A substantial change was needed to make the security management of Dynamics AX much more aligned with organizational needs and easy maintenance for the customers.

A little background: Some pain points

Administration of user based authorization to different modules in previous versions of AX is based on the concept of user groups and domains. Users are added to user groups and companies are added to domains. Then permission to different forms and data are set for a combination of User group and domain.

The main issue with the old system is that permissions in AX are defined at the table/field/Menu Item/controls level. Moreover, the security management UI doesn’t help the administrators easily identify the tables requiring access in order to perform an operation on a form. Customers have to spend a very long time trying to figure out what underlying tables require what access level in order to enable a user to perform a particular operation.

Furthermore, following key issues are also tamping the customers/vendors.

  • The user groups are not reusable. If the two users exist in different companies and need access to a single set of operations, two user groups need to be created.
  • The security administration is different for heterogeneous client types. For instance, rich clients and web users are granted access using the AX administration form while reports, cubes and services, security needs to be managed separately.
  • Functional consultants and administrators needs to have database-centric knowledge and hence to be more technical about the system in order to setup authorization. Need extra effort to either train them or assign a separate technical resource. Not cost effective.

Fundamentals of the new role-based security model in 2012

The new role based security framework in AX 2012 is designed with two goals in mind.

  • Make the security administration easier for the customer and align to the business needs
  • Make the product more secure.

Based on the facts described above, a significant change was needed to revamp the whole authorization concept in AX. Most businesses would like the security management in their companies to align with how their businesses are structured. They would like it to be set up for users based on the roles the various users are playing in respect to the organization. Instead of creating arbitrary groups of users and granting them permissions, the access grant based on the role and job functions and being able to control what users are allowed to see or do based on business processes makes much more sense. The following diagram helps to comprehend the real world scenario.

In the figure above, the job function can be described as the most granular level task which is termed as privilege. Those privileges define the access levels that are exposed to user through roles and duties. A duty can be defined as an extra layer b/w roles and privileges to group together job functions. For example, AR clerk may have multiple duties and each duty comprises of multitude of tasks or privileges.

In addition to simplifying security setup greatly, using role based security also allows setting up other rules such as segregation of Duties Analysis (SoDA) which ensures that companies can place checks and balances in their system. This ensures that their systems are not only secured but also well audited and that a user cannot bypass the processes that they have in place.