I’m sure a lot of people will agree that setting up AX and its
security is no easy task. Therefore I’ve put together a guide to the
information that you need to consider when working with AX 2012
security.
In this first part we will discuss and explain the concept of Role-based security within AX.
1 – Role-based security
At a high level Role-based security works to limit the areas/functions within AX to which a user has the ability to access/Run.
Essentially think of AX as a long corridor with doors on either side, AX security will dictate which doors the user can open and which actions they can take on contents of the that room (AX – records in a table).
These levels can be defined as follows:
Figure 1
Figure 2
2 – Example
The way I like to think of this is that Microsoft have put together a ‘Library’ of ‘Duties’ which can then be selected and placed into the appropriate roles. This is best explained using an example, take the example of the Buying agent whose role is defined as ‘Documents purchase events and responds to purchase inquiries’. If we find this role within AX we can see that the user is made up of the following:
Figure 3
We can see that Microsoft have used the concept of building a ‘Library of Duty’, we can see this if we investigate the duty Inquire into import letter of credit which can also be found in the following roles:
In this first part we will discuss and explain the concept of Role-based security within AX.
1 – Role-based security
At a high level Role-based security works to limit the areas/functions within AX to which a user has the ability to access/Run.
Essentially think of AX as a long corridor with doors on either side, AX security will dictate which doors the user can open and which actions they can take on contents of the that room (AX – records in a table).
These levels can be defined as follows:
|
Level
|
Definitions
|
|
Entry points
|
Entry points define the individual sections of code access. |
|
Privileges
|
Privilege’s define the first level of grouping of entry points and should be used to define an individual tasks. Note – The privilege also dictates the level access available to that privilege. See fig 2. |
|
Duty
|
A Duty combines multiple privileges in order to provide a user with the appropriate access to perform a specific process within AX. |
|
Roles
|
Roles combine multiple Duties in order to allow a user to perform the multiple process necessary to perform their specified day job. |
Figure 1
| AOT Name | Label | Description |
| No Access | No Access | Does not provide any access to data. |
| Read | View | An end-user can view data. |
| Update | Edit | An end-user can view and edit data. |
| Create | Create | An end-user can view, edit and create new data. |
| Correct | Correction | An end-user can view, edit, create new and correct date-effective record without creating new records. |
| Delete | Full control | An end-user can view, edit, create new and delete data. |
2 – Example
The way I like to think of this is that Microsoft have put together a ‘Library’ of ‘Duties’ which can then be selected and placed into the appropriate roles. This is best explained using an example, take the example of the Buying agent whose role is defined as ‘Documents purchase events and responds to purchase inquiries’. If we find this role within AX we can see that the user is made up of the following:
Figure 3
We can see that Microsoft have used the concept of building a ‘Library of Duty’, we can see this if we investigate the duty Inquire into import letter of credit which can also be found in the following roles:
- Accounting manager
- Accounts payable manager
- Accounts payable payments clerk
- Buying agent
- Chief financial officer
- Financial controller
- Purchasing manager
- Treasurer
No comments:
Post a Comment