ax2012 enus wn dev 07

Chapter 7: Security

CHAPTER 7: SECURITY Objectives

The objectives are:

Provide an overview for the improvements made to the security framework and explain Role-based Security.

Discuss the benefits of the Role-based Security framework. Describe the extensible data security framework.

Introduction Administration and authorization in Microsoft Dynamics AX 2009 are based on a concept of user groups, domains, and access rights. The security framework in Microsoft Dynamics AX 2012 is updated significantly to help simplify security setup and maintenance.

Instead of user groups, domains and security keys, Microsoft Dynamics AX 2012 now implements Role-based Security which takes advantage of several concepts such as roles, duties, privileges and permissions. These concepts help hide the complexity of managing low-level permissions from the administrator. Administrators maintain the security of their Microsoft Dynamics AX 2012 deployment based on constructs that closely represent the business processes.

The developer creates permissions and privileges. In addition he or she may also create duties and roles. The administrator creates or customizes roles by including more or less duties in these roles. Role-based Security allows for segregation of duties which help to ensure companies can add validation checks in their system. These tools help the administrators to validate that their systems are not only secured but also well audited.

This chapter outlines the key changes to these areas and provides an overview of how to take advantage of these improvements to maximize the security experience from a developers perspective.

Server Enforcement of Security

In earlier releases, authorization is performed primarily on the client. In Microsoft Dynamics AX 2012, the Table Permissions Framework (TPF) is extended so that it can also work on fields. This improvement shifts the security load to the server, regardless of the type of client that is used to access the data.

Custom Authentication

Since the Microsoft Dynamics AX 4.0 release, user authentication is based on Active Directory. In Microsoft Dynamics AX 2012, users can be authenticated by using identity providers other than Active Directory. This means external

7-1

Microsoft Official Training Materials for Microsoft Dynamics

Your use of this content is subject to your current services agreement

What's New - Technical in Microsoft Dynamics AX 2012 for Development

users will no longer require domain accounts to access Microsoft Dynamics AX. Instead, you can use Forms-based Authentication stores or work with external partners using Active Directory Federation Services (ADFS).

Role-based Security Overview Microsoft Dynamics AX 2012 introduces a hierarchy of security concepts to simplify the creation and administration of security.

FIGURE 7.1 SECURITY STRUCTURE

Roles, Process Cycles, and Duties

Security roles, Process cycles, and Duties are the primary security concepts used by an administrator to control security in Microsoft Dynamics AX 2012.

Security roles represent a behavior or group of duties for a job function. They include a defined set of application access privileges and users are assigned to one or more security roles.

Process cycles organize duties and access privileges according to high level processing. For example: Revenue cycle.

Duties are a responsibility to perform one or more tasks or services for a job. In the security model a duty is a set of application access privileges required for a user to perform specific tasks. Duties are designed according to a specific business objective.

7-2



Chapter 7: Security

Privileges, Entry Points, and Permissions

Privileges, Entry points, and Permissions are primarily used by a developer to control security in Microsoft Dynamics AX 2012.

Privileges group together related Microsoft Dynamics AX artifacts from a security perspective. For example: Menu items for forms and related Fact Boxes.

Permissions group together Microsoft Dynamics AX base objects and permissions that are required for them. Entry points link to Permissions. For example: Form permissions, Report permissions.

Scenario: Assign Permission

Isaac, the Developer, is developing a new client form and menu item. He must define the permissions that are required to access the menu item to expose the functionality. Isaac is required to configure Permissions for the new form and link it to the menu item. The Permissions should allow for "Read" access when a user wants to access the form from the menu item.

Procedure: Assign Permission

To create Permissions for a new form and link to the menu item, follow these steps:

1. Start the AX client and open the AOT. 2. Create a new form and select the Permissions node. 3. Make sure that the CreatePermissions , UpdatePermissions,

ReadPermissions, and DeletePermissions property is set to the default value of "Yes."

4. Make sure that the CorrectPermissions property is set to the default value of "No."

5. Expand the Permissions node . 6. Change the DeletePermission to "No". 7. Verify that the Delete node is removed from the Permissions node. 8. Change the DeletePermission to "Yes". 9. Verify that the Delete node is added under the Permissions node. 10. Expand the Permissions node and review the permissions available

for the datasource tables of the form. 11. Close the AOT.

7-3




Lab 7.1 - Assign Permission This lab will demonstrate how to assign security permissions by using the new Role-based Security framework.

Scenario

Isaac, the Developer, is developing a new customer inquiry form and menu item. He must define the permissions that are required to access the menu item to expose the functionality. Isaac is required to configure Permissions for the new form and link it to the menu item. The Permissions should allow for "Read" access when a user wants to access the form from the menu item.

Challenge Yourself!

Use the information that is provided to add a new client form and menu item. Make sure that you define the permissions that are required to access the menu item to expose the functionality. The Permissions should allow for "Read" and "Update" access on the form and only "Read" access when a user wants to access the form from the menu item.

Need a Little Help?

1. Start the Microsoft Dynamics AX client and create a new form and menu item by using the CustTable as the DataSource.

2. Select the Permissions node under the form and set the correct parameters.

3. Review the access level properties on the form and menu item. 4. Set the correct parameters on the menu item.

Step by Step

To create Permissions for a new form and link to the menu item, follow these steps:

1. Start the Microsoft Dynamics AX client and open the AOT. 2. Create a new form and call the form PermissionDemo. 3. Add the CustTable as a new datasource. 4. Select the Permissions node. 5. Make sure that the CreatePermissions , UpdatePermissions,

ReadPermissions, and DeletePermissions property is set to the default value of "Yes."

6. Make sure that the CorrectPermissions property is set to the default value of "No."

7. Expand the Permissions node and review the permissions available for the CustTable.

8. Select the Menu Items node in the AOT.

7-4



Chapter 7: Security

9. Right-click Display and select New to create a Display menu item. 10. Right-click the new Menu item and type PermissionDemo into the

Name property. 11. Make sure that the Access level properties are set to "Auto." Because

the menu item points to the form, the system automatically interprets the Auto value to be the same value as the form.

12. Change the values for UpdatePermissions to "No." 13. Save the menu item. 14. Close the AOT.

7-5




Role-based Security Benefits Microsoft Dynamics AX 2012 introduces Role-based Security. This makes application security easier to manage by providing the following benefits:

Application security aligned with your business Reusable permissions Compliance, auditing, and reports Default and sample security settings

Application Security Aligned With Your Business

In earlier releases, Microsoft Dynamics AX administrators created their own user groups and manually assigned users to those groups. In Microsoft Dynamics AX 2012, security is role-based, and by default, many security roles are provided. Using role-based security, users are assigned to roles, based on their responsibilities in the organization and their participation in business processes. Instead of identifying and granting access to application elements, the administrator assigns duties.

Because rules can be set up for automatic role assignment, the administrator does not have to be involved every time that a user's responsibilities change. After security roles and rules are set up, role assignments are updated based on changes in business data.

Reusable Permissions

In earlier releases, user groups could not span multiple companies. 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.

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.

Compliance, Auditing, and Reports

Auditing for compliance is a manual task for administrators in earlier releases. There are no built-in features to help prevent fraud and guarantee compliance.

It is now possible to setup a segregation of duties rules to make sure a user does not have access to conflicting duties. For example, a rule can be set up specifying one person should not be granted access to both create and release a purchase order. In another example, a rule specifies one person cannot both acknowledge the receipt of goods and pay the vendor.

7-6



Chapter 7: Security

In addition to helping you enforce compliance, Microsoft Dynamics AX 2012 includes better security audit trails and new security reports. Because administrators and auditors can more easily obtain information about each user's permissions, they can also easily determine whether adjustments to security must be made.

Default and Sample Security Settings

In Microsoft Dynamics AX 2012, permissions for all application elements are grouped into default privileges and duties. In earlier releases, no security settings are provided. Administrators created their own user groups and granted those groups access to application elements.

NOTE: The default security roles have application access. By default, data restrictions are not applied.

Extensible Data Security Framework The Extensible Data Security Framework lets an administrator create data security policies that determine what data a user can access. This provides a state where the security is automatically enforced based on business data. The data security setup is performed in two steps:

1. Developers identify the tables that need to be secured and create a policy based on specific data security requirements.

2. The IT system administrators decide which policies to enable or disable.

The extensible data security framework provides the following benefits to the system administrator who is securing data in Microsoft Dynamics AX 2012:

Data security filters Data security based on the organization hierarchy Data security based on effective date

Data Security Filters

In earlier releases, the record-level security (RLS) feature is used to help secure the data. The filters used for record-level security are based on fields in the same table that is being secured. In addition, by default, record-level security is enforced on the client.

In Microsoft Dynamics AX 2012, the Extensible Data Security Framework can be used to help secure the data. The new framework lets administrators create data security policies based on data that may be contained in a different set of tables. Data security policies are enforced on the server side, regardless of the type of client that is used to access the data. In addition, policies can consider security privileges. For example, the administrator can grant view access to one subset of sales orders and edit access to a different subset of sales orders.

7-7




CAUTION: The record-level security feature is still supported in Microsoft Dynamics AX 2012 and if previously implemented, they will continue to be used. However, it is recommended to setup new data filter utilizing the extensible data security framework.

Data Security Based on the Organization Hierarchy

In earlier releases, the company context (represented by the DataAreaId column in tables) is always applied. This means that tasks in Microsoft Dynamics AX can be performed only in the context of a company. In addition, users can access tables without a DataAreaId column only when they are logged on to a company where they are granted access to those tables. If a user needed to perform an action or access a table in a different company, the user is required to log on to that different company.

In Microsoft Dynamics AX 2012, users can view or edit data in different organizational structures, instead of the company they are logged on to. For example, a user might enter records in Human Capital Management by using a human resources organization hierarchy and enter financial transactions by using a legal entity organization hierarchy. Data security filters take the hierarchical structure into consideration. For example, filter can be setup that applies to the current organization and any organizations under it in the hierarchy.

NOTE: Some tables in Microsoft Dynamics AX 2012 still contain a DataAreaId column. To help secure data in these tables, the administrator can specify a company context for a particular user in a role.

Data Security Based on Effective Date

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 date. For example, a user might have access to view past records, and have access to create and edit present records.

Scenario: Develop Extensible Data Security Policy

Isaac, the Developer, wants to create a security policy that will be included with Microsoft Dynamics AX 2012. He wants to make sure the administrator can apply the policy to control the data that is visible to users in the customer role.

Procedure: Develop Extensible Data Security Policies

To develop extensible data security policies, follow these steps:

1. Start the Microsoft Dynamics AX client and open the AOT. 2. Expand the Security node. 3. Right-click the Policy node. 4. Select New Security Policy.

7-8



Chapter 7: Security

5. Type a Name for the security policy. 6. Select a table such as CustTable in the Table property. 7. Select or type a Query name such as CustTable in the Query

property. 8. Expand the security policy created. 9. Right-click the constraints sub-node. 10. Select New > Add Table. 11. Select the table from which to select the constraints, for example,

SalesTable. 12. Select the TableRelation. 13. Expand the Table node, right-click the Related Tables node and

select New > Add Table. 14. Repeat the process for each constraint to add to the policy. 15. Click Save. 16. Close the AOT.

Summary The security framework in Microsoft Dynamics AX 2012 is improved to help simplify security setup. Instead of user groups, domains and security keys, the new security system uses the concepts of role and task to structure the permissions for reading and writing to tables. The developer creates permissions and tasks while the administrator customizes roles by including more or less duties in these roles.

The biggest areas of change to Microsoft Dynamics AX 2012 security include the following:

Role-based security Default and sample security settings.

o 81 out of the box roles are provided o 700 out of the box duties are provided

Server enforcement of security Ability to add Active Directory groups and Claims users in addition

to Active Directory users Additional reports and compliance tools Improved framework for securing data

7-9




Test Your Knowledge 1. Match the following Microsoft Dynamics AX 2012 security concept names

with their descriptions.

_____ 1. Roles _____ 2. Process _____ 3. Duties _____ 4. Privileges _____ 5. Entry Points _____ 6. Permissions

a. Group of duties which can be optionally used when assigning duties to roles

b. Group of related entry points with associated access levels

c. Group of base objects and required permissions, for example: Form permissions

d. Providing user 'entry' into application, for example: menu items

e. Group of related entry points with associated access levels

f. Group of duties for a job function

2. Who is responsible for selecting the policies that will be associated with a role and defining additional record level security?

( ) IT system administrator ( ) Developer ( ) Database administrator

3. Which of the following are advantages of Microsoft Dynamics AX 2012 role based security? (Select all that apply)

( ) In Microsoft Dynamics AX 2012, security is role-based, and many security roles are provided by default.

( ) In Microsoft Dynamics AX 2012, a single set of roles applies across all companies and organizations.

( ) Microsoft Dynamics AX 2012 includes better security audit trails and new security reports.

( ) In Microsoft Dynamics AX 2012, permissions for all application elements are grouped into default, task-based privileges and duties.

4. Which of the following are advantages of Microsoft Dynamics AX 2012 extensible data security framework? (Select all that apply)

( ) You can view or edit data in different organizational structures, depending on the business process that you are working in, instead of the company that you are logged on

( ) You can specify whether the users in a role have access to past, present, or future records.

( ) The new framework enables you to create data security policies based on data that is contained in a different table.

( ) The IT system administrators create the policies and determine which tables the policy will affect.

7-10



Chapter 7: Security

Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter

1.

2.

3.

7-11




Solutions Test Your Knowledge

1. Match the following Microsoft Dynamics AX 2012 security concept names with their descriptions.

f 1. Roles a 2. Process e 3. Duties b 4. Privileges d 5. Entry Points c 6. Permissions

a. Group of duties which can be optionally used when assigning duties to roles

b. Group of related entry points with associated access levels

c. Group of base objects and required permissions, for example: Form permissions

d. Providing user 'entry' into application, for example: menu items

e. Group of related entry points with associated access levels

f. Group of duties for a job function

2. Who is responsible for selecting the policies that will be associated with a role and defining additional record level security?

() IT system administrator ( ) Developer ( ) Database administrator

3. Which of the following are advantages of Microsoft Dynamics AX 2012 role based security? (Select all that apply)

() In Microsoft Dynamics AX 2012, security is role-based, and many security roles are provided by default.

() In Microsoft Dynamics AX 2012, a single set of roles applies across all companies and organizations.

() Microsoft Dynamics AX 2012 includes better security audit trails and new security reports.

() In Microsoft Dynamics AX 2012, permissions for all application elements are grouped into default, task-based privileges and duties.

7-12



Chapter 7: Security

4. Which of the following are advantages of Microsoft Dynamics AX 2012 extensible data security framework? (Select all that apply)

() You can view or edit data in different organizational structures, depending on the business process that you are working in, instead of the company that you are logged on

() You can specify whether the users in a role have access to past, present, or future records.

() The new framework enables you to create data security policies based on data that is contained in a different table.

( ) The IT system administrators create the policies and determine which tables the policy will affect.

7-13




7-14



Chapter 7: SECURITYObjectivesIntroductionServer Enforcement of SecurityCustom Authentication

Role-based Security OverviewRoles, Process Cycles, and DutiesPrivileges, Entry Points, and PermissionsScenario: Assign PermissionProcedure: Assign Permission

Lab 7.1 - Assign PermissionScenarioChallenge Yourself!Need a Little Help?Step by Step

Role-based Security BenefitsApplication Security Aligned With Your BusinessReusable PermissionsCompliance, Auditing, and ReportsDefault and Sample Security Settings

Extensible Data Security FrameworkData Security FiltersData Security Based on the Organization HierarchyData Security Based on Effective DateScenario: Develop Extensible Data Security PolicyProcedure: Develop Extensible Data Security Policies

SummaryTest Your KnowledgeQuick Interaction: Lessons LearnedSolutions

ax2012 enus wn dev 07

Documents