Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

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

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