Using CRM from an external website – part 7: Back to the drawing board

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:

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 web browser loads the web page, and  executes the javascript containing the viewmodel in order to load or to process the data.
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…