4

We have an existing single sign on (SSO) implementation where we redirect users using My Domain to an ADFS server through a mediation layer. In short, the SSO dance looks like this:

<redacted>.my.salesforce.com
salesforce.<redacted> *
adfs.<redacted> *
login.salesforce.com/?saml=<redacted>

* These servers are internal to our network, sit behind our firewall, and exist only in our DNS.

This works well on our desktops browsers (best on Internet Explorer, of course), but we've also set up a VPN connection that works with mobile devices. In this case, we connect through the VPN service using a secure token, then we try to authenticate with Salesforce1 by entering our custom My Domain.

We've had several obstacles around this, including the need to place a publicly trusted SSL certificate onto the private internal server, but our latest attempt is the most baffling of all.

Our network guru can see the client connecting to the ADFS (Active Directory Federated Services) server, but it never progresses beyond that. On the client itself (e.g. iPad), we get a spinning circle icon that never goes away. The request never times out, displays an error message, etc. In short, we have no idea why it's not working.

This same SSO dance works on our mobile browser, such as Safari, although it does make us authenticate with ADFS first using our username/password from Active Directory. This is an acceptable flow, since we plan on letting devices stay authorized indefinitely (needing only a mobile pin).

Is there some special configuration we need to have to make ADFS work with the Salesforce1 mobile app with SSO? Are there certain restrictions on what type of servers can be used with the SAML flow? Nothing in the documentation suggests that there are limitations of this nature, so I thought I'd ask the community to see if anyone has successfully implemented ADFS SSO and what special considerations were required to make it work through a VPN.

2

Salesforce1 does not support NTLM authentication. To use SSO with Salesforce1, you must use Forms Authentication. If your AD FS server is Internet-facing (not recommended), you can set external connections to Forms Authentication and internal connections to Windows Authentication, which will allow Salesforce1 to SSO correctly if you're not using a VPN.

Since we are using a VPN as a security requirement, we were forced to disable Windows Authentication on all devices to save the hassle of setting up two servers. Some blogs on the Internet suggest setting up two AD FS servers, setting the SSO login URL to a script that reads the Client header, then redirecting to one of two servers with a 302 redirect depending on Windows Authentication support.

Using this method, you can utilize automatic login when available, and Forms Authentication otherwise, although we chose not to go this route. So, in summary, do not attempt to use NTLM authentication on Salesforce1, because it will never successfully complete the login handshake.

1

Single Sign-On with Force.com and Microsoft Active Directory Federation Services gives this advice:

When configuring ADFSv2 for use with Salesforce, it's recommended that you select the new "HTTP Redirect" option available in the Salesforce Single Sign-On settings under "Service Provider Initiated Request Binding". This will improve interoperability with iOS based devices.

Have you tried the HTTP Redirect option? I think you're seeing the same interop problems.

  • 1
    It's been a while, but we got SSO working on our mobile devices, finally. While this wasn't the answer to this question, this piece of data was required for a successful implementation, which I'll be detailing in another question I have open. – sfdcfox Nov 14 '14 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.