About role-based security in services and AIF

Important

This content is archived and is not being updated. For the latest documentation, see Microsoft Dynamics 365 product documentation. For the latest release plans, see Dynamics 365 and Microsoft Power Platform release plans.

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

Security for Microsoft Dynamics AX services and Application Integration Framework (AIF) is based on the role-based security that is used in Microsoft Dynamics AX. For an overview of role-based security in Microsoft Dynamics AX, see Role-based security in Microsoft Dynamics AX. This topic describes how services and AIF help enforce security requirements through users, roles, duties, and privileges.

AIF users

The following types of user can work with services and AIF.

Submitting user

The submitting user submits the message to Microsoft Dynamics AX. The submitting user must be an authenticated Microsoft Dynamics AX user.

The following table explains the process that AIF uses to determine the submitting user.

Data exchange method	Submitting user
File system adapter	The submitting user is the owner of the message request file as returned by the Windows GetFileSecurity (OWNER_SECURITY_INFORMATION) function. You can specify a default message owner that AIF uses when file ownership cannot be resolved deterministically. See Configure addresses for enhanced integration ports.
MSMQ adapter	The submitting user is the sender of the message as set on the SenderId property of the message.
Web services	The submitting user is the Windows identity of the caller.

Authorized port user

When you configure an integration port, you can restrict access to the port to a list of authorized users. For information about how to restrict users to authorized users, see Configure security for integration ports.

Claims user

A claims user is a type of Microsoft Dynamics AX user. Claims users are authenticated by an external system, not by Application Object Server (AOS). To gain authorization to access services, a claims user must be authenticated, and then impersonated by a trusted intermediary user. See the next section.

Trusted intermediary user

Trusted intermediaries are typically used for business-to-business data exchanges. A trusted intermediary is a type of submitting user that can act on behalf of another user, such as a claims user. A trusted intermediary is not a type of Microsoft Dynamics AX user. Instead, trusted intermediaries are typically middleware applications, such as Microsoft BizTalk Server or Electronic Data Interchange (EDI) services. These applications are represented by Microsoft Dynamics AX users or user groups that are authorized to submit inbound requests to an integration port. By using trusted intermediaries, you can delegate authentication to a trusted source, whereas authorization continues to be managed by Microsoft Dynamics AX through the role-based security framework.

Trusted intermediaries are associated with integration ports. You can define custom intermediaries when you configure an integration port. For information about how to configure integration ports to use trusted intermediaries, see Configure security for integration ports.

A trusted intermediary must always be an Active Directory user, never a claims user. A trusted intermediary can impersonate any other Microsoft Dynamics AX user, even a claims user. When the submitting user is a trusted intermediary, AIF provides authorization to the user that is defined in the message header by the <LogonAsUser> element. Otherwise, this element is ignored.

Important

When you use a trusted intermediary, make sure that the trusted intermediary represents a known, valid partner or a trusted system.

Proxy user

If a proxy is used, .NET Business Connector can connect on behalf of Microsoft Dynamics AX users when authentication is performed by an AOS instance. For more information, see Specify the .NET Business Connector proxy account.

Roles, duties, and privileges

Users who have the roles that are described in the following table can configure integration port settings for services and AIF.

Role	AOT name	Description
Information technology manager	SysServerITManager	This role has the following two duties that are related to services and AIF: AifIntegrationMaintain, which provides the privileges that are required for typical AIF tasks, such as configuring integration ports, viewing the message queue, and reviewing history information. AifSyncConfigure, which provides the privileges that are required to configure document filters.
System administrator	-SYSADMIN-	A user who has this role is a super user, and therefore has full permission for every operation in Microsoft Dynamics AX.

Every service operation is associated with an entry point privilege. This privilege provides permissions for the tables that the service reads or modifies. For example, the SalesSalesOrderServiceCreate service operation is associated with the SalesSalesOrderServiceCreate privilege. The ServiceOperation duty provides privileges for all service operations. Other duties provide privileges for specific service operations, depending on the responsibilities of the duty and its associated roles. For example, among the privileges that the DOCommerceOnlineSalesOrderMaintain duty provides is the SalesSalesOrderServiceCreate privilege.

To understand the relationships between roles, duties, privileges, and permissions, see the Security node of the Application Object Tree (AOT).

Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.