Using CRM from an external website – part 8: Custom Authentication Service

In this series of articles I’m trying to find multiple ways to connect to Dynamics CRM from an external website. A scenario that I could implement succesfully was the Web API scenario which was based entirely on Microsoft infrastructure.
Then I tried to connect to the CRM webservices using javascript REST calls, that is where to problems arose. It turns out that CRM is really picky about authentication.

In order to authenticate, you have to build the authentication mechanism yourself. I’m afraid my javascript skills are lacking in that field. So I had to come up with plan B.


In my previous article I described the direction I was thinking of; building a custom authentication service. The idea behind the custom authentication service is to act as a sort of gateway that will take my call, transform it and pass it to Dynamics CRM.

In this article I’ll go in depth and design a prototype for that service.



The idea is to have a generic website based on HTML and Javascript. Instead of making direct calls to CRM (and having to handle the authentication yourself), a REST call is made to a separate server on which a custom authentication webservice is running.
The custom authentication service can be implemented as a windows service, a (linux) deamon, or as a webservice on a webserver. In fact this doesn’t really matter, as long as the authentication service is running on either .Net or Mono.
The reason the authentication service has to run on .Net/Mono is that we then can rely on the authentication mechanisms the .Net framework is offering.

How does it work?


From our HTML website we make a REST call to the authentication service. In the REST call we make, we pass the REST call we actually want to make to Dynamics CRM. Once the authentication service receives the REST call, the actual REST call is taken from the incoming call.

The next step prepares a new REST call that has to be sent to Dynamics CRM. We add the credentials Dynamics CRM is expecting and we execute the REST call to CRM.
A little while after the REST call has be sent to CRM, the CRM server responds to our REST call and sends back a JSON response.

In the service we collect the JSON response, pass it through as is and send it back to the HTML website.

Proof of concept

So far for the theory, time to find out if this concept can work. For the first test I built a windows console application that functions as an HttpListener. The goal of the HttpListener is to capture the incoming REST call.
Once the call has been received the results are passed as a JSON result. For this test I took a little shortcut, I just want to test if I can capture the call and return a result that can be processed in my webpage.

The first tests are very promising.

From my web page, I’m able to send a REST call using the Javascript viewmodel to my C# custom service. What I do in the request is that I use a POST instead of a GET method. Using the POST allows me to send the original query as a parameter in the send() method.


As soon as I call the load() function, the custom Authentication server picks up the request and decodes the query that has been sent.


Once the call has been received, I assemble a new object in which I put some contact data. I respond to the incoming call and pass the JSON back to the Javascript client.


Running the Visual studio debugger I see the breakpoint kicking I put in the Javascript…


I’m able to receive the JSON data created by the custom service.

Ok, looks cool! Where to go from now?

At this moment I’ve taken the biggest hurdle. I mastered the concept of passing REST/JSON data back and forth, connecting the external website with a custom server. The next step I have to take, is to take the incoming CRM request and pass it with valid credentials to our CRM server.

Furthermore I’ve to make the code more robust. Once I finished that I’ll post a final article in this series, containing the source code for your convenience.