XenMobile: SAML SSO fails for Secure Browse MDX Apps

I had a call with a customer who complained that SAML SSO does not work for ShareFile MDX as soon as the MDX Policy Network Access is set to „Tunnel to the internal network“ using Secure Browse.

Secure Browse is required as soon as there are ShareFile Connectors (CIFS or SP) and you want to provide your employees a single sign-on to them.

Checking the logs of the ShareFile MDX App, we found the following error:

2017-04-05T18:22:47.368+0200 | Default | E | [SDK ERROR]: : Domain:SFAWebAuthenticationError Type:1001 code:401 Mesage:Authentication failed with status code: 401 : Authentication failed with status code: 401 WWW-Authenticate Header:Bearer Request URL:https://<privacy rulez! :)>.sf-api.eu/sf/v3/Sessions/Login?{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}24expand=Principal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FHomeFolder{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FPreferences{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FProductDefaults{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FMobileSecuritySettings{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FPlanTrack{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FAccount{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FIsFreeTrial{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2CPrincipal{654d3c287e59941232f6496818383c1e86d565334b6a1d66b931cb1ee7dd052b}2FRoles&authcomparison=&authmethod=

We were not able to figure out what exactly caused the issue, but it seemed that NetScaler is corrupting the traffic for some reason.

This was confirmed by a forum post at citrix discussions

Workaround

As a workaround, we enabled SplitVPN so that the login to ShareFile using SAML is working and SSO to the SZC Connectors is working.

In the meanwile a support case was opened.

Resolution

According to Citrix, newer Versions of the NetScaler nows recognise the Bearer header and removes it as it caused issues when new MS Clients talk to legacy SharePoint Servers.

Too bad for ShareFile, isn’t it?

Create the following traffic policy and actions to your NetScaler Gateway configuration and your issues are gone! 🙂

add vpn trafficAction bearer_sso_off_profile http -SSO OFF

add vpn trafficPolicy bearer_sso_off_policy "REQ.HTTP.HEADER Authorization CONTAINS Bearer" bearer_sso_off_profile