Wednesday, July 7, 2010

Ax Security (Part 1)

Security has always been and continues to be a bit of a hassle in current Ax versions. In anticipation of the new role/task based security in Ax6, I will talk a bit on how the current security works.


Upto version 2009, Ax' security is based on security keys. Security keys are a hierarchy of nodes in the security tree, as you can see on the user group permissions screen. Objects in the AOT get assigned security keys in their properties, which makes them show up in the hierarchy on the permissions screen. This is where the confusion begins.


Security "inheritance".

Security keys can have a parent security key, which on its turn may have a parent security key, etc. This is what makes the hierarchy. If a parent security key has a certain permission granted, it will trickle down to every security key underneath it, and down to every object at the lowest level. Of course, at any level the permission level may be overridden, which then changes the permissions for the security keys and objects underneath, etc.

So technically, setting permissions on the highest level key will grant that permission implicitly to everything underneath.


Forms (screens)

Forms are usually a bit of a challenge. First of all, although it appears that way, a form does not have security directly attached to it. The security is set on a menu item (an entry in the menu used to open the form) which in its turn links to a form. Technically, you can have multiple menu items linked to the same form, with different security.

Additionally, the access to the form is not only controlled by the access given to the menu item, but also by the security given to the tables used on the form. If security is set on both, the user will experience the lowest security settings (if full control set to menu item and read-only on table, the user will get read-only… the same read-only result when read-only on menu-item and full control on table).

Another issue with forms is the buttons (which technically are menu items) that appear on the screen. They have separate security, which can be set on the form security in the security tree, or on the menu item itself (if you know where it appears in the tree).


Here's the caveat. If you give access to a menu item button on a screen, the user will get access to that menu item from anywhere else it is available (other screens, on the menu, etc).


It is VERY tempting to click the "cascade" button. I've always strongly recommended people never ever to click that button. First of all, you are giving access to all these menu items available on the forms. You will also cascade your security down to the tables. Which means, if you need full control to a table somewhere else, setting view permissions and cascading it down will result in changing your table's security to view everywhere else in the system!

And of course if will also require you to explicitly remove security, to make some of the menu items "inherit" from their parents. If you set no security and cascade that down, you are removing access rather than removing the security. It is very confusing.


Deny permission

Ax does not have a "deny" permission. When users are in multiple groups, they will get the union (maximum) permissions of all the groups they are in. There's no way to have a group that denies permission which overrides any other permissions coming from other groups.


Security is a big topic and there's lots more to talk about. There are some tools one can build and will talk about that in an upcoming post. Missing tools/reports are for example: where's the security in the security setup tree for object X, who has what access to object Y, etc.

To put the above in technical perspective, we need to know how the security is stored. We can build on that to create some tools. Stay tuned.


7 comments:

  1. Hi Joris,

    It is possible setting "No acess" permissions to Cost Price, in entire Ax ?

    Thanks in advance,

    Diogo Monteiro

    ReplyDelete
  2. Diogo,

    you can set security on the cost price field of the table you want. I'm not sure what cost price field you're talking about.

    If you're looking at cost price in for example the inventtablemodule, be aware it's the same table for sales/invent/purchase so you will set security for all three types. You could probably do record level security if you want to get around that, but I'd stay away from that if possible :-)

    ReplyDelete
  3. Hi joris,

    Thank you for quick answer.

    I'm talking about Item cost price, you can see cost price on InventTableModule, but you can see also in other tables, InventSum (through a method) for instance...

    My objective is avoid that one specific user group has permissions to see the cost price,not only in one specific table, but in all Ax. It is possible? I'm afraid not...

    Thanks

    Diogo.

    ReplyDelete
  4. Hi Joris,

    I need help whenever you are free.!!

    How to set field level security in Ax 2012 R2.
    Thanks in advance.

    Regards,
    Ashok

    ReplyDelete
  5. Hi Joris,

    Your post was most helpful to us being on Ax 2009. However, we had some feedbacks that after creating a new Parent Key, the menu items under it became visible on existing User groups. Can you please advise where we could have done it wrong ?

    Thanks

    Didier

    ReplyDelete
  6. I am experiencing the same issue as Didier: from what I can see, it seems that if you create a new top-level security key, the default access for that key for ALL USERS will be full control, which allows all users access to everything under that key.

    Is there a way to change this behavior without manually adjusting EVERY security group?

    ReplyDelete
  7. Didier/KingOfZeal,

    yes when you create a new key it's automatically set to full control. So applying the inheritance rule that means anything using that key will have full control as well.
    Note that you DO NOT get that issue when you move layers. Considering that is the best practice approach to move code into production (over importing XPOs).
    Without going into another rant about moving code using XPOs, let's focus on alternatives to this issue :-) You could write a job/class that adjusts security settings across all security groups.

    ReplyDelete