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

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
Database.

- 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.

Grant users access to reports [AX 2012]

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This topic explains how to give users access to reports. Two procedures are described in this topic. The procedure that you should use depends on whether you are running Microsoft SQL Server Reporting Services in native mode or SharePoint integrated mode.

Note

SharePoint integrated mode is supported if you are using Microsoft Dynamics AX 2012 R2.

Assign users to the DynamicsAXBrowser role on the Report Manager site

If you are running Reporting Services in native mode, you must assign users or groups to the DynamicsAXBrowser role on the Report Manager site. The following procedure explains how to complete this task.

1. Open the Report Manager website for the Reporting Services instance. By default, the URL is http://[SSRSServerName]:80/Reports.

2. Click the DynamicsAX folder.

3. Click Folder Settings.

4. Click Security.

5. Click New Role Assignment.

6. Enter the Active Directory user name or group to assign to the DynamicsAXBrowser role.

7. Select the DynamicsAXBrowser role.

8. Click OK.

Grant users permission to view reports in SharePoint

If you are running Reporting Services in SharePoint integrated mode, you must grant users permission to view reports in SharePoint. To grant this permission, grant users Read permission to the document library that stores the reports. Alternatively, if the document library inherits permissions from the site, you can grant users Read permission to the site. The following procedure describes how to grant users Readpermission to the site.

Important

If the SharePoint site is configured for claims-based authentication, you must also grant the following accounts Read permission to the document library or site:

• The account that is used as the Business Connector proxy

• The account that is used to run the Microsoft Dynamics AX Application Object Server (AOS) service.

1. Open your browser and navigate to the SharePoint site that contains the document library that stores the reports.

2. Click Site Actions > Site Permissions.

3. Click Grant Permissions. The Grant Permissions window is displayed.

4. In the Users/Groups field, enter the Active Directory names of the users or groups that you want to view reports.

5. In the Grant Permissions area, select the Grant users permission directly option.

6. Select the Read check box.

   Note

   If you want users of Enterprise Portal for Microsoft Dynamics AX to be able to filter reports by using a custom parameter value, select the Design check box. For more information about the permissions that are required to use Enterprise Portal, see Enable users to access Enterprise Portal.

7. Click OK.

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.

Security Roles - Ax 2012

All users must be assigned to at least one security role in order to have access to Microsoft Dynamics AX. The security roles that are assigned to a user determine the duties that the user can perform and the parts of the user interface that the user can view.

Administrators can apply data security policies to limit the data that the users in a role have access to. For example, a user in a role may have access to data only from a single organization. The administrator can also specify the level of access that the users in a role have to current, past, and future records. For example, users in a role can be assigned privileges that allow them to view records for all periods, but that allow them to modify records only for the current period.

By managing access through security roles, administrators save time because they do not have to manage access separately for each user. Security roles are defined one time for all organizations. In addition, users can be automatically assigned to roles based on business data. For example, the administrator can set up a rule that associates a Human resources position with a security role. Any time that users are assigned to that position, those users are automatically added to the appropriate security roles. Users can also be automatically added to or removed from roles based on the Active Directory groups that they belong to.

Security roles can be organized into a hierarchy. A role hierarchy enables roles to be defined as combinations of other roles. For example, the sales manager role can be defined as a combination of the manager role and the salesperson role.

In the security model for Microsoft Dynamics AX, duties and privileges are used to grant access to the program. For example, the sales manager role can be assigned the Maintain revenue policies and Review sales orders duties.
By default, sample security roles are provided. All functionality in Microsoft Dynamics AX is associated with at least one of the sample security roles. The administrator can assign users to the sample security roles, modify the sample security roles to fit the needs of the business, or create new security roles. By default, the sample roles are not arranged in a hierarchy.

NOTE: The sample security roles do not correspond to Role Centers.

Security Roles

All users must be assigned to at least one security role in order to have access to Microsoft Dynamics AX. The security roles that are assigned to a user determine the duties that the user can perform and the parts of the user interface that the user can view.

Administrators can apply data security policies to limit the data that the users in a role have access to. For example, a user in a role may have access to data only from a single organization. The administrator can also specify the level of access that the users in a role have to current, past, and future records. For example, users in a role can be assigned privileges that allow them to view records for all periods, but that allow them to modify records only for the current period.

By managing access through security roles, administrators save time because they do not have to manage access separately for each user. Security roles are defined one time for all organizations. In addition, users can be automatically assigned to roles based on business data. For example, the administrator can set up a rule that associates a Human resources position with a security role. Any time that users are assigned to that position, those users are automatically added to the appropriate security roles. Users can also be automatically added to or removed from roles based on the Active Directory groups that they belong to.

Security roles can be organized into a hierarchy. A role hierarchy enables roles to be defined as combinations of other roles. For example, the sales manager role can be defined as a combination of the manager role and the salesperson role.

In the security model for Microsoft Dynamics AX, duties and privileges are used to grant access to the program. For example, the sales manager role can be assigned the Maintain revenue policies and Review sales orders duties.
By default, sample security roles are provided. All functionality in Microsoft Dynamics AX is associated with at least one of the sample security roles. The administrator can assign users to the sample security roles, modify the sample security roles to fit the needs of the business, or create new security roles. By default, the sample roles are not arranged in a hierarchy.

NOTE: The sample security roles do not correspond to Role Centers.

Security architecture of the Microsoft Dynamics AX application [AX 2012]

When you understand the security architecture of Microsoft Dynamics AX, you can more easily customize security to fit the needs of your business. The following diagram provides a high-level overview of the security architecture of Microsoft Dynamics AX.

Authentication

By default, only authenticated users who have user rights in Microsoft Dynamics AX can establish a connection.

The Microsoft Dynamics AX client uses integrated Windows authentication to authenticate Active Directory users.

Enterprise Portal supports flexible authentication, which allows you to use authentication providers other than Active Directory. If you configure Enterprise Portal to use a different authentication provider, users are authenticated by that provider.

After a user connects to the client or Enterprise Portal, access is determined by the duties and privileges that are assigned to the security roles that the user belongs to.

Authorization

Authorization is the control of access to the Microsoft Dynamics AX application. Security permissions are used to control access to individual elements of the application: menus, menu items, action and command buttons, reports, service operations, web URL menu items, web controls, and fields in the Microsoft Dynamics AX client and Enterprise Portal for Microsoft Dynamics AX.

In Microsoft Dynamics AX, individual security permissions are combined into privileges, and privileges are combined into duties. The administrator grants security roles access to the application by assigning duties and privileges to the roles.

For more information about role-based security in Microsoft Dynamics AX, see Role-based security in Microsoft Dynamics AX.

Data security

Authorization is used to grant access to elements of the application. By contrast, data security is used to deny access to tables, fields, and rows in the database.

Use the extensible data security framework to control access to transactional data by assigning data security policies to security roles. Data security policies can restrict access to data, based on the effective date or based on user data, such as the sales territory or organization. For more information about how to use data security policies in Microsoft Dynamics AX, see Overview of Security Policies for Table Records.

In addition to the extensible data security framework, record-level security can be used to limit access to data that is based on a query. However, because the record-level security feature is becoming obsolete in a future release of Microsoft Dynamics AX, we recommend that you use data security policies, instead.

Additionally, the Table Permissions Framework helps protect some data. Data security for specific tables is enforced by Application Object Server (AOS). For more information about the Table Permissions Framework, seeManage data access by using the Table Permissions Framework.