Dynamics 365 integration with mTLS

Data Actions
1

According to the release notes of the integration, mTLS should be available for the data actions as of October 30th, 2019 (see Release notes for the Microsoft Dynamics 365 data actions integration - Genesys Cloud Resource Center (mypurecloud.com)

Has anyone been able to set this up successfully? We're integrating with Azure but can't seem to get this working - the request is always successful even if we put a self-signed certificate into Azure. This makes me think it either isn't supported or we're doing the wrong thing in Azure.

2

We definitely have customers using this successfully in general, however I don't know if anyone is using this with Azure today. Can you point me to the documentation you are trying to follow?

--Jason

3

We haven't found any specific documentation for Azure, unfortunately. We set up the App Registration as detailed here: Register the integration in Microsoft Entra ID - Genesys Cloud Resource Center (mypurecloud.com)

Once created, there's an option in Azure for Certificates and Secrets. When we added a self-signed certificate here, it didn't prevent the data action from running. I'm not sure how to get it working
When you say customers are using it, is that mTLS with the Dynamics 365 data actions? Or mTLS with generic web services?

Thank you for the response, Jason. Much appreciated.

4

Hey David,

I am not aware of any of our customers using mTLS with Dynamics.

I did a bit of searching, and I have not found any documentation for Dynamics supporting mTLS in the sense of the server asking for the client's certificate during the TLS handshake.

I'm guessing the certificate configuration you found is what is described in these articles:

In this case the certificate is used to generate an assertion used to authenticate with, instead of a client ID and client secret.

We currently do not have direct support for this type of authentication. You could request it at our ideas site:
https://genesyscloud.ideas.aha.io/ideas

If implementing this is required soon, you could do it in an AWS Lambda, Google Function, or with our now-in-beta Functions feature:

--Jason

5

Thanks Jason! We've largely followed intuition on setting mTLS up. I've applied for the beta for Functions, will see if we can manage it with that.

We just had a call with our customer and Microsoft attendees. Microsoft have asked the following regarding the Dynamics 365 integration:

  • Is there a reason that the integration uses a username and password, rather than service principal accounts? Setting up a user also incurs the customer a licence which is not ideal.

  • Is there a reason the integration doesn’t use client credentials as its authentication method?

  • Is the User Defined OAuth able to be used within the Dynamics 365 integration? If no, is there a specific limitation that prevents this?

They seemed surprised that the integration is still using the username/password approach, rather than more modern authentication methods.

6

Hey David,

The reason for using the older authentication style is that was what we could use successfully at the time we implemented Dynamics authentication, and we haven't revisited it since then.

You are welcome to try authenticating with the User Defined OAuth integration. We recently deprecated our Adobe integration as you can now use OAuth instead of Adobe's flavor of JWT. It would be great if we could also move future Dynamics usage to normal OAuth.

Please post your feedback to https://genesyscloud.ideas.aha.io/ and I will also pass this post to the Product Manager.

--Jason

7

Thanks Jason, much appreciated. I've raised it on the Ideas Lab and will keep an eye on its progress

Thanks for your help!

8

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.