Authentication in Dynamicweb

Generally, there are two ways of working with authentications in Dynamicweb:

Endpoint authentications are managed in Settings > Integration > Endpoint Management.

They can be of any supported type and can be tied to one or more endpoints with the Endpoint authentication dropdown.  

Figure 2.1 Add authentication screen in Dynamicweb

The Dynamicweb Connector Service is a tool which functions as the bridge between the Dynamicweb solution and the ERP system. It is typically installed on the DMZ/Perimeter network of your environment, and handles data encryption and decryption. It can also function as an extensibility point when developing custom integrations.

The connector is supplemented by the Dynamicweb Connector TestTool, which is used to test connectivity between the components of an integration and to test requests/responses from remote systems.

The suitable type of authentication for you integration project depends on the remote system you wish to integrate with and whether it is cloud-hosted or local.

An integration with a cloud hosted ERP system will most likely require authorization through the OAuth 2.0 protocol. Communicating with local hosted solutions on the other hand, can most likely make do with a simpler method of authentication such as Basic, ntlm or WSAK.

There are two distinct ways of working with OAuth 2.0. The recommended way is to use Service-to-Service authorization (S2S), where your Dynamicweb solution is authorized access directly to the remote system (the client).

The differences between S2S and user impersonation OAuth is outlined further in this Microsoft learn article.

Service-to-service OAuth takes a ClientID, a TenantID and a client secret of an Azure Active Directory app registration and exchanges access tokens in the background and independently of user credentials. Check out our S2S guide to learn more about adding such as an authentication for Dynamics 365 Business Central, CRM or F&O:

Just like an S2S OAuth, a User impersonation setup requires a TenantID, a Client ID and a ClientSecret from Azure Active Directory, but in addition to these, an access token is required to authorize access to the remote system. Access tokens are obtained via the credentials of a user in the remote system and the authorization will thus mirror the permissions tied to that exact user. 

You can read more about how to establish OAuth for the systems currently supported in Dynamicweb here:

Endpoints exposed from an on-prem solution via the Dynamicweb connector service or the Dynamicweb Connector TestTool can be accessed with authentications such as these:

  • Basic: Authentication with a username and a password
  • WebServiceAccessKey: Business Central can assign web access keys to users. These keys can be valid from one date and be invalid after a certain date. These keys are auto-generated and is used instead of a password. WebServiceAccessKeys can be used for on premise solutions as well as cloud-hosted test enviroments. 
  • Ntlm: NTLM is an authentication protocol used in windows networks. It allows you to provide a domain and windows user to access endpoints within the same network as the Dynamics ERP system. This is useful in development and on premise scenarios.

 

Figure 10.1 Adding an authentication in Dynamicweb endpoint management