An end-user is given one or more security roles. A security role represents a
behavior pattern that a person in the organization can play. An example is the
Accounts receivable manager. A security role includes one or more duties.
A duty is a responsibility to perform one or more tasks. Examples of the
Accounts receivable manager's duties are to maintain the customer master and
inquire into the chart of accounts. A duty includes one or more privilegesPrivileges specify the access that is required to perform a duty. For example, the
duty of maintaining the customer master requires privileges to maintain
customers and maintain customer bank accounts. A privilege includes one or
more permissions.Permissions include the access level to one or more securable objects that are
required to perform the function associated with an entry point. For example, the
privilege of maintaining customers requires permissions that give full control to
the customer form accessed through the entry point of a display menu item. It
also requires full control to create a new address accessed through the entry point
of an action menu item.
Entry PointsAn entry point is the element that is triggered by a user action to start a particular
function. There are three different categories of entry points in Microsoft
Dynamics AX:• Menu items point to forms, reports and classes that an end-user can
access from the rich client.• Web content items point to URLs and actions that an end-user can
access from the Enterprise Portal.• Service operations are used in document service classes in the
Application Integration Framework (AIF). AIF exchanges data with
external systems by sending and receiving XML documents.PermissionsPermissions refer to the access levels that can be applied to the securable
objects. This could include any tables, fields, forms, reports or server side
methods that are accessible through an entry point.
Permissions are maintained by a developer in the Application Object Tree
(AOT).
Access levels available are:
| 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 | Correcti on | An end-user can view, edit, create new and correct date-effective records without creating new records. |
| Delete | Full control | An end-user can view, edit, create new and delete data. |
Permissions that give access to reports or classes need only to have access or not
have access. By convention, reports are typically given read access and classes
are typically given delete access.
Permissions that give access to tables or fields can make use of all access levels.
Possible permission levels are defined on the entry point target. For example, a
form might allow permission levels to read, update, create or delete. The level to
be granted to an end-user is defined on the permission.
PrivilegesA Privilege is a group of related permissions that are required to perform a duty.
Privileges can be assigned directly to roles. However, for easier administrative
maintenance and to use the Segregation of Duties feature, it is recommended to
group privileges into duties and assign duties to roles.
Privileges are typically maintained by a developer in the AOT however they can
also be maintained by a system administrator in the rich client.
A best practice is for privileges to be maintained in the AOT and to assign
privileges to duties.
DutiesDuties are a group of related privileges required to perform a task.
Duties are grouped into the following six Process Cycles.• Conversion cycle• Cost accounting cycle• Expenditure cycle• Human capital management cycle• Information technology cycle• Revenue cycle
Process cycles are used in the rich client to make it easier for a system
administrator to view and find related duties when setting up security.RolesRoles are a group of duties that are required by an end-user to do his or her job
based on the end-user's role in the organization.
Roles can be organized into a role hierarchy. Roles can contain sub-roles and
inherit the permissions from the sub-role. For example, the accounting manager
role could be defined as a combination of the manager role and the accountant
role. A role hierarchy reduces the need for duplicating security access that makes
access change management simpler.
No comments:
Post a Comment