Tag Archives: Security

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.

Extensible Data Security Framework – AX 2012

The extensible data security framework is a new feature in Microsoft Dynamics AX 2012 that enables developers and administrators to secure data in shared tables such that users have access to only the part of the table that is allowed by the enforced policy. This feature can be used in conjunction with role-based security (also supported in Microsoft Dynamics AX 2012) to provide more comprehensive security than was possible in the past.

Extensible data security is an evolution of the record-level security (RLS) that was available in earlier versions of Microsoft Dynamics AX.

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.
The extensible data security framework provides the following benefits to the system administrator who helps secure data in Microsoft Dynamics AX 2012:

Improved filters for data security
In previous releases, the record-level security feature was used to help secure the data. The filters that were used for record-level security could not be based on fields that were contained in a separate table from the data that was being filtered. For example, to filter sales lines, you could not use the customer location, because the customer location field is not contained in the sales line table. In addition, record-level security was enforced only through the client interface.

In Microsoft Dynamics AX 2012, the extensible data security framework can be used to help secure the data. By using the new framework, you can create data security policies that are based on data that is contained in a different table. Data security policies are enforced at the server, regardless of the type of client that is used to access the data. In addition, policies can take security privileges into account. For example, the administrator can grant View access to one subset of
sales orders and Edit access to another subset of sales orders.

CAUTION: The record-level security feature is still available in Microsoft Dynamics AX 2012, but it will become obsolete in a future release. Filters that you previously set up for record-level security can still be used. If you set up new filters, we recommend that you create data security policies by using the extensible data security framework.

Data security that is based on effective dates
In Microsoft Dynamics AX 2012, you can specify whether the users in a role have access to past, present, or future records. A user can also have different levels of access based on effective dates.

For example, a user can have access to view past records, and access to create and edit present records.


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

Join other followers:

error: Content is protected !!