Category Archives: Security

Security Role Design Principles in AX 2012 R2

Several common design principles are used when creating the base 80+ security roles included in AX 2012.
These design principles include the following:
• Roles represent the common access rights that are required for the job positions within an organization.
• Roles account for the organization size, culture and industry focus.
• Users are assigned to one or more roles according to their job.
Role types.

  1. Functional role: for example: Warehouse worker.
  2. Organization role: for example: Employee.
  3. Application role: for example: System User.

• Role segregation categories: Functional roles are designed to accommodate segregation of duties. Different categories of roles exist that each focus on their type responsibilities.

  1. Validation: Clerks focus on recording transactions.
  2. Verification: Verifies validate the correctness of recorded transactions.
  3. Authorization: Supervisors authorize processing of the transactions.
  4. Management: Managers review transactions periodically and apply changes to the process as appropriate.

Conclusion of Security in AX 2012

security architecture diagram

1- You can add users to Microsoft Dynamics AX as the following:

– add Active Directory users.

– Add Active Directory groups.

– Add external users (Claim users): Pluggable authentication is used to allow access to Enterprise Portal to users who are not part of Active Directory, Pluggable authentication provides an administrator three additional forms of authentication in addition to Active Directory:  Active Directory Federated Services, Windows Live IDs, or an External

– Both of Active Directory groups and Claim users are new authentication types added to Microsoft Dynamics AX 2012

2- Process Cycle is a group of duties which can be optionally used when assigning duties to roles.

3- Roles is a group of duties for a job function.

4- Duties is a responsibility to perform one or more tasks or services for a job.

5- Privilege is group of related entry points with associated access levels.

6- Permission is a group of base objects and required permissions For example: Form permissions .

7- Each user must be assigned to at least one role in order to access the system. The security model is a hierarchy, with each element representing a different level of detail. At the top of the hierarchy are process cycles. Process cycles are composed of duties, and they represent business processes, such as the expenditure process. Duties are composed of privileges, and they represent parts of a business process, such as maintaining bank transactions. Privileges are composed of permissions, and they represent access to tasks, such as canceling
payments or processing deposits. Permissions grant access to application elements, such as forms and menu items.

8- Both duties and privileges can be assigned to roles to grant access to the application.

9- Process cycles are used only to organize duties and privileges. If a duty or privilege is not assigned to a process cycle, that duty or privilege is not available in the Security privileges form. To work with duties and privileges that do not appear in the form, you must use application Object Tree (AOT).

10- Because the record-level security feature because will be deprecated in a future release of
Microsoft Dynamics AX, it is recommend using data security policies instead

11- Table Permission framework (TPF ) was limited to denying users access to full records in AX 4 and AX 2009, but could not restrict individual fields from being visible. In Microsoft Dynamics AX 2012 TPF is extended so that it can also work on fields. This shifts more of the security load to the server. This helps to increase the consistency of security between client types.

12- Reusable Permissions: In Microsoft Dynamics AX 2012, a single set of roles applies across all companies and organizations. The administrator no longer has to create and
maintain separate user groups for each company, as was the case in earlier versions. Even though roles themselves are not specific to a company or organization, the administrator can still specify a company or organization context for a particular user in a role.

13- Extensible data security policies, when deployed, are enforced, regardless of whether data is being accessed through the Microsoft Dynamics AX rich client forms, Enterprise Portal web pages, SQL Server Reporting Services (SSRS) reports, or .NET Services.

Procedure: Add Security Role in AX 2012

To create a new role, follow these steps:
1. Open System administration > Setup > Security > Security roles.
2. To create a new role, click New.
3. If you are creating a new role, enter the name that you want to appear for the role in the Application Object Tree (AOT) in the AOT name field.

4. Select the check box next to each desired duty, privilege, or sub-role and then click Close.
5. To remove a duty, privilege, or sub-role from the role, select the duty, privilege, or sub-role, and then click Remove.
6. To change the role’s permission level on securable objects such as controls, tables, fields, and server methods click Override permissions.

NOTE: AOT names must contain only alphanumeric or underscore characters. AOT names cannot begin with a number, and they cannot contain special characters or spaces.

8. To include all of the permissions from another role, open the Security roles form, and drag the role that has the permissions that you want to the role that you are modifying. By dragging one role to another, you create a hierarchical relationship, where the main role contains all of the permissions of the sub-role. If you change the
permissions of a sub-role, the changes also apply to the main role.
A role cannot contain duties that conflict according to the rules for the segregation of duties.

TIP: Security is organized hierarchically. Permissions on specific application elements are combined into privileges, privileges are combined into duties, and duties are grouped into process cycles. You can assign either duties or privileges to roles.

Developing an Extensible Data Security Policy

Developing an extensible data security policy involves the following steps:
1. Modeling the query on the primary table.
2. Creating the policy.
3. Adding the constrained tables and views.
4. Setting the context.
However, before you start developing a policy, you must understand the underlying requirements. You should identify the set of constrained tables and analyze the relationships that these tables have with the primary table. You should also analyze the data access patterns of the constrained tables, the table sizes, and existing indexes on both the primary and constrained tables. All of these aspects influence the impact that a policy will have on the performance of the application.

NOTE: For more information about developing an extensible data security policy, click here to download Developer Documentation

Data Security Policy Concepts

When developing a data security policy, you need to become familiar with several concepts, such as constrained tables, primary tables, policy queries, and context. This section outlines these concepts.

Constrained table: A constrained table is the table or tables in a given security policy from which data is filtered or secured, based on the associated policy query. For example, in a policy that secures all sales orders based on the customer group, the SalesOrder table would be the constrained table. Constrained tables are always explicitly related to the primary table in the policy.

Primary table: A primary table is used to secure the content of the related constrained table. For example, in a policy that secures all sales orders based on the customer group, the Customer table would be the primary table.

Policy query: A policy query is used to secure the constrained tables specified in a given extensible data security policy. This query will return data from a primary table that is then used to secure the contents of the constrained table.

Context: A policy context is a piece of information that controls the circumstances under which a given policy is considered to be applicable. If this context is not set, then the policy, even if enabled, is not enforced. Contexts can be of two types:

o A role context enables policy application based on the role or roles to which the user has been assigned.

o An application context enables policy application based on information set by the application.


Get every new post on this blog delivered to your Inbox.

Join other followers:

error: Content is protected !!