New security model in Dynamics AX 2012
In Dynamics AX 2012, one of the key area that has gone a total overhaul is Security. In Dynamics AX 4.0 and Dynamics AX 2009, the security model was module based. Users were assigned to user groups which grouped permissions to the various objects. These permissions were controlled by security keys. The biggest drawback of this model was that you could not have the same security user group apply across multiple companies. You still had to create the same user group across different groups.
With Dynamics AX 2012, all this has changed. The security model in Dynamics AX 2012 is role based. This means that you can relate the day to day business processes to roles. Users are assigned to roles. Roles contain a group of duties or privileges. It is logically very easy now to configure security in Dynamics AX 2012.
The Security keys in the AOT are now obsolete in Dynamics AX 2012. It is present for backward compatibility. If you right click on the Security keys node, you dont have an option to create a new security key.
Instead, in the AOT, you will find a new node - Security. This further has sub nodes - Privileges, Duties and Roles. Let us better understand these by relating to a real world example.
Let us take an example of a school. A school needs to do a lot of day to day activities like teaching students, conducting exams, counselling, issuing books, buying new books etc. All these are privileges. These privileges can be group as duties. So teaching students and conducting exams can be grouped under one duty of learning enablement. At the same time issuing books and buying new books can be grouped under the book management duty. Now not everyone can perform these duties. These duties have to be assigned to some role. In some cases, multiple duties can be assigned to a single role.
Take a look at the below image to better understand this.
In my opinion, the new role based security model is very logical and aimed at enabling business analysts to configure security. Of course, a developer's help may still be required but once the privileges are created, it is just a matter of group them under duties and assinging the right duties to the correct roles.
The new security model is strictly enforced in Dynamics AX 2012. There are a bunch of best practice errors around this. Let us look at these.
Every new menu item should be added as an entry point in a privilege. If this is not the case, the following best practice error is thrown.
Entry point is not in any privilege
In case, you create a new privilege and add your menu item to it, and forget to add the privilege to a duty, you get the following best practice error.
Privilege is not in any duty
And finally, if you created a new duty and didnt add it to any role, you will get these best practice error.
All duties should be part of a role
All duties should be part of a process cycle
So, there are four best practice errors coaxing the user to complete the security modelling. In a way, this is a good thing as this ensures that there are no orphan or unused objects existing in the AOT.
When configuring security, ensure that you analyze the out of the box duties and roles present in Dynamics AX 2012. Often, your new entry points should be easily sit in one of these. If they dont, then you can go ahead and create your own duties or roles.
I'll encourage you to further go and read more about the new Security model in Dynamics AX 2012 on the What's New: Security [AX 2012] page on MSDN.
Also, take a look at this nice post by Brandon - AX 2012 and the impact on Design with the new Security Model
That is all for today. In future posts, I'll cover some more topics on Security. Check back soon for more.
With Dynamics AX 2012, all this has changed. The security model in Dynamics AX 2012 is role based. This means that you can relate the day to day business processes to roles. Users are assigned to roles. Roles contain a group of duties or privileges. It is logically very easy now to configure security in Dynamics AX 2012.
The Security keys in the AOT are now obsolete in Dynamics AX 2012. It is present for backward compatibility. If you right click on the Security keys node, you dont have an option to create a new security key.
Instead, in the AOT, you will find a new node - Security. This further has sub nodes - Privileges, Duties and Roles. Let us better understand these by relating to a real world example.
Let us take an example of a school. A school needs to do a lot of day to day activities like teaching students, conducting exams, counselling, issuing books, buying new books etc. All these are privileges. These privileges can be group as duties. So teaching students and conducting exams can be grouped under one duty of learning enablement. At the same time issuing books and buying new books can be grouped under the book management duty. Now not everyone can perform these duties. These duties have to be assigned to some role. In some cases, multiple duties can be assigned to a single role.
Take a look at the below image to better understand this.
The new security model is strictly enforced in Dynamics AX 2012. There are a bunch of best practice errors around this. Let us look at these.
Every new menu item should be added as an entry point in a privilege. If this is not the case, the following best practice error is thrown.
Entry point is not in any privilege
In case, you create a new privilege and add your menu item to it, and forget to add the privilege to a duty, you get the following best practice error.
Privilege is not in any duty
And finally, if you created a new duty and didnt add it to any role, you will get these best practice error.
All duties should be part of a role
All duties should be part of a process cycle
So, there are four best practice errors coaxing the user to complete the security modelling. In a way, this is a good thing as this ensures that there are no orphan or unused objects existing in the AOT.
When configuring security, ensure that you analyze the out of the box duties and roles present in Dynamics AX 2012. Often, your new entry points should be easily sit in one of these. If they dont, then you can go ahead and create your own duties or roles.
I'll encourage you to further go and read more about the new Security model in Dynamics AX 2012 on the What's New: Security [AX 2012] page on MSDN.
Also, take a look at this nice post by Brandon - AX 2012 and the impact on Design with the new Security Model
That is all for today. In future posts, I'll cover some more topics on Security. Check back soon for more.
Comments