I ended my previous article with the conclusion that history was repeating itself. For some reasons I don’t understand, Microsoft is making it very hard for developers to integrate Microsoft products with non Microsoft technologies.
I did some thorough investigation and stumbled on the following articles:
This article gives a high level overview on how to use OAuth with the CRM service.
This article comes with a demo on using node.js to authenticate to Dynamics CRM.
Jason Lattimer has a number of code snippets on using OAuth with the CRM service in various languages. *Recommended*
No matter what I do, I keep on running into a massive wall. The only thing I can think is.. .Why? What have these guys must be smoking? I thought SharePoint could be harsh… I just discovered CRM can be harsh as well.
Enough complaining… time to repack.
As it looks at this moment, the combined authentication / Knockout route is a bridge too far. I have to invest too much time, time that I don’t have.
Therefor I have to go back to the drawing board to figure out how I can connect from my external website to Dynamics CRM.
I started this series of articles with a scenario that depended completely on Microsoft technologies in which I used a Web API controller developed in C#.
As an alternative I will proceed the knockout route, in which I can host my website on a completely different environment. For authentication I have to rely on a new component. This component is the custom authentication service.
The idea is to use the custom authentication service as a bridge between the external website and Dynamics CRM. The website is communicating with the custom authentication service, the custom authentication service passes the requests to CRM and will route the response from CRM back to the external website.
Schematically this would look like this:
The view model connects to a custom authentication service in which it delivers the web request it wants to make.
The custom authentication service connects to Dynamics CRM and executes the request.
The results from CRM are passed back to the Knockout view model for further processing and will result in a response in the browser.
In order to make the connection secure between the custom authentication service and the client’s browser, we have to rely on mechanisms like SSL (certificates). This requires some additional effort.
By setting up the custom authentication service in a generic way, the service can be used simultaneously for multiple CRM environments.
The disadvantage of this scenario is that we have to use an additional server. On the other hand, this server does not have to be a server running IIS on a Windows Server. Any server will do, as long as it is capable of running either a Mono or a .NET assembly.
A scenario worth investigating…