Integrating some QlikView screens into Salesforce, and using Salesforce to authenticate your users is actually very simple. Joe Bickley from Qlik wrote about setting up Salesforce SSO back in 2012 - and I thought I'd have a go.

The only road block encountered along the way was Salesforce's decision to disable TLS 1.0. They have a number of very good reasons, including the famous Poodle vulnerability. It meant I experienced the error below:

UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https.

on

AppExchangeAPI.GetUserInfoResult userInfoResult = binding.getUserInfo();

This isn't yet a mandatory change for production organisations, but it will be by 22/07/2017. Any development organisation will have it enabled by default, without any method for disabling. Other services do not have a disable date at the time of writing this post.

Uh oh, things aren't well with SFDCLogin.aspx

System and configuration requirements

There are some basic requirements that we need to fulfil:

1. We need to have an OS which supports TLS 1.1 or greater. Anything from Windows Server 2008 R2 or Windows 7 up will support TLS 1.1 and TLS 1.2 (see more details at MSDN). Unfortunately it's not a case of the latest and greatest being enabled automatically - see more.

2. Our .NET version ideally needs to at least 4.0. It is possible to enable TLS 1.2 on 3.5 as well by way of a patch, but if you've got no other .NET apps running it'd benefit you to jump straight to 4.6.1 (where the latest standards are enabled by default).

3. IIS needs to be configured to run the correct version of the .NET framework. Although it may only list major releases, as long as you've got a point release installed it'll run just fine.

IIS won't list point releases - just use 4.0 and you should be fine

Enabling TLS 1.1 or greater

Assuming we've met the criteria above, we have numerous ways to achieve our goal. Given I'm creating one file which I want to be portable, I've opted to set the protocol in my application, but there are many ways to achieve this globally on a system (there are a number of good stackoverflow discussions about this that are worth skimming through - link 1, link 2, link 3, link 4).

Sforceservice builds on the SoapHttpClientProtocol Class

In our case, the SFDC-SSO solution available from the Qlik article uses the SoapHttpClientProtocol class. We simply need to:

Update the .NET version. I'm running 4.6.1, hence can specify TLS 1.2 outright in the next step.

Specifying the 4.6.1 .NET framework

Specify the security protocol we want to use, in the SforceService class (around line 128):

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Specify System.Net.ServicePointManager.SecurityProtocol

And add the relevant references as required.

Add the System.Net reference

Then rebuild SFDC-SSO and you're good to go.

Voila. QV working with SalesForce

My copy of SFDC-SSO.dll

You're welcome to try out my compiled copy, it was built using the changes above and works on a new implementation running .NET 4.6.1, Windows Server 2008 R2, QlikView 12.1 SR3 and a Salesforce developer setup.

Download SFDC-SSO.dll

All credit, of course, goes to Joe Bickley at Qlik for the original post, I've simply hacked it a bit. Note that there are newer versions of the Salesforce WSDL that can be used, and are accessible via Setup > APIs in your Salesforce control panel.