Adding CRM 4.0 to your own win app with web form authentication
Last year I wrote small article Adding MS CRM to your own windows forms applications that demonstrates the usage of CRM in your own custom windows forms applications. In CRM 4.0 the story is pretty much the same but there’re few things that you need to take into account so that everything works as you expect. One thing is multi-tenancy and another one is different authentication mechanisms. CRM 4.0 introduces new authentication mechanism called Service Provider License Agreement / SPLA / IFD / Internet Facing Deployment (it has sooo many names :-). Basicly it just means that you login to CRM using web form so it isn’t anything fancier. And that authentication is of course cookie based so if you use Fiddler you’ll see something like this (Note: image is clipped):
So there is MSCRMSession ticket that authenticates the user to the system. Okay fine… but what if I want to spawn CRM session whenever I like and still provide “auto login” for my end users (and of course you’re not using windows authentication a.k.a. On Premise authentication)? Let’s first use Fiddler to determine what’s happening under covers in IFD (and compare it to win auth):
Here’s screenshot of Fiddler when user logs on (see highlighted username and password). So the login is just normal HTTP POST.
If we compare that to win auth then we’ll see that there’s that normal authorization headers that makes the magic happen:
You have probably noticed the other difference... which is status code 401. In win auth the system returns 401 which starts the authentication routine. In IFD you’ll save time because you don’t do those 401 round-trips.
But okay.. now we need to achieve “auto login" and for that we’ll need little bit of code. Example code has been taken from How To Use the PostData Parameter in WebBrowser Control and it has been modified for this case. And here we go:
That code clips uses System.Windows.Forms.WebBrowser component to POST the login information to CRM so that end user won’t notice the logon event at all. In this example the user will be redirected into the main CRM page (as defined at line 2) but you can of course use any page under CRM if you need to.
Obviously this approach poses some security threats since you need to store username and especially password in memory. But you can make this thing better by storing the confidential values at System.Security.SecureString (more info can be found in MSDN). SecureString is designed for storing confidential text. And of course you should use HTTPS so that you don’t pass on the information plain text.
Anyways... Happy hacking!