Qlik Community

Qlik Sense Mobile Discussions

Discussion Board for collaboration related to Qlik Sense Mobile.

Seamless Single SignOn (SSSO) into Qlik Sense

Some customers want to be absolutely certain who is accessing their content by enforcing Two Factor Authentication (2FA), requiring users to login using multiple mechanisms sequentially, for example, a Username, Password and a dynamically generated Authentication Token (eg Google Authenticator or RSA SecurID).

Some customers are content with integrating their multiple applications to the same User Repository so that the users use the same credentials for entry to all their secured applications.

Many customers want to simplify the User Experience by performing authentication without any User Interaction. The applications seem to "know" who the user is. This document describes how to leverage Kerberos to perform Windows Integrated Authentication into Qlik Sense from Windows and Mobile browsers.

Some terminology

TermDescription
ADActive Directory. This Microsoft product is widely used by Enterprises and delivers many services such as LDAP, KDC, Domain Controller. Users and Computers are registered into the Active Directory, and many customers want to leverage this single repository of identities for authentication (who are you) and authorization (what are you permitted) within their corporate applications.
LDAP

Lightweight Directory Access Protocol, operates on 389/tcp or the SSL version LDAPS operates on 636/tcp.

Provides a way to validate credentials and lookup user properties such as displayName, emailAddress, group membership.

Qlik will typically be configured to interact with Active Directory's LDAP interface from the User Directory Connector (UDC) component.

FQDNFully Qualified Domain Name. If your machine is called "myserver" then it's FQDN might be "myserver.example.com"
KDCKerberos Distribution Center, accessed using 88/tcp. This is the component that issues tokens to the client for access to various services that require authentication. A Kerberos Realm serves a similar function to a Windows Domain but looks more like an uppercase Email Address
UPNA Kerberos User Principal Name. If your Active Directory domain identity is EXAMPLE\someone then your corresponding UPN is probably someone@EXAMPLE.COM
SPN

Each service that you may authenticate to using Kerberos requires a Service Principal Name associated with it. This is formed from a Service Identifier that is usually uppercase, the fully qualified address of that service and any non-default ports, and optionally the Kerberos Realm, eg

HTTP/sense.example.com

HTTP/sense.example.com:4244@EXAMPLE.COM

Note that the HTTP service applies to both http:// and https:// websites.

See also https://technet.microsoft.com/en-us/library/cc731241(ws.10).aspx

TGTA Kerberos Ticket Granting Ticket is the token of identity that is established in your Kerberos Ticket Cache after successful authentication. This represents your identity and is used when requesting a Service Ticket for any Kerberos-enabled service that you access.

How Kerberos works

When you've logged into your Domain-member laptop, a token of your identity is retained within Windows which local applications can use to determine who you are.  Qlik Sense is accessed using a browser, and the Qlik Sense Hub does not know who you are unless you (explicitly) or your browser (implicitly) tells Qlik Sense who you are.

While logging into Windows, your credentials are validated against the Active Directory, and a Kerberos Ticket Granting Ticket (TGT) is delivered into the Kerberos Ticket Cache on your machine. That TGT will remain valid for approximately 8 hours and may be renewed automatically if you have a long day.  You could also manually establish a TGT using the KINIT.exe command-line tool, which will validate the supplied username and password against the Active Directory (using the ldap/389 or ldaps/636 protocols) before delivering your TGT (kdc/88).

When your Kerberos-enabled browser attempts to connect to a website that expects Kerberos authentication (401 HTTP Response), the browser uses the Kerberos APIs and your TGT to ask the Kerberos Distribution Center (KDC) for a Service Ticket for that website. The Service Ticket will contain your encrypted identity and is stored in your Kerberos Ticket Cache. The browser delivers this to the website in response to its authentication challenge, and the website decrypts the Service Ticket to determine who you are. You're logged in!

sso-kerberos.png

Qlik Authentication in pseudocode

IF (Windows authentication pattern string in the properties of the Virtual Proxy is found in the HTTP User Agent sent by Browser) THEN

We strongly recommend changing the configured value from “Windows” to “Mozilla” as this matches more browsers!

Browser gets redirected to /{virtualProxy}/internal_windows_authentication/


IF (Kerberos is enabled as property of Proxy) THEN

This requires that the browser is Kerberos enabled (yes this IS possible for Safari/iOS)

This also requires that appropriate SPNs have been created in Active Directory

Attempt Kerberos Authentication

END IF

IF (not yet logged in) THEN

This is our First Fallback

Attempt NTLM Authentication

END IF

END IF

IF (not yet logged in) THEN

This is our Second Fallback

Browser gets redirected to /{virtualProxy}/internal_forms_authentication/

Perform Forms Authentication

END IF


Qlik Requirements

Enabling Kerberos Authentication into Qlik Sense requires that Kerberos Service Principal Names have been created that associate the Qlik Authentication URL with the domain service account that the Qlik Sense Proxy (QPS) service is running as. If you access Qlik Sense at https://sense.example.com and your QPS is running as EXAMPLE\qlik then you need to create these SPNs:

Create Service Principal Names

SETSPN.exe  -U  -S  HTTP/sense.example.com      EXAMPLE\qlik

SETSPN.exe  -U  -S  HTTP/sense.example.com:4244  EXAMPLE\qlik

SETSPN.exe  -U  -S  HTTP/sense.example.com:4248  EXAMPLE\qlik

The table below lists the HTTP User Agent for several browsers on Windows, iOS, and Android. Kerberos (or NTLM) Single SignOn will only be attempted if the User Agent that the browser presents (invisible to the user) contains the string shown in the Windows authentication pattern property of the Virtual Proxy.

Browser/PlatformHTTP User Agent
Chrome/WindowsMozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Firefox/WindowsMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
IE11/WindowsMozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Safari/iOSMozilla/5.0 (iPad; CPU OS_11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1
Chrome/iOSMozilla/5.0 (iPad; CPU OS_11_3 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/65.0.3325.152 Mobile/15E5216a Safari/604.1
BlackBerry Access/iOSMozilla/5.0 (iPad; CPU OS_11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E5216a Safari/605.1.15 GoodAccess/2.9.0.1170
Qlik Sense Mobile/iOSMozilla/5.0 (iPad; CPU OS 11_3 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Mobile/15C114
Chrome/AndroidMozilla/5.0 (Linux; Android 8.0.0; SM-G950F Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.109 Mobile Safari/537.36
BlackBerry Access/AndroidMozilla/5.0 (Linux; Android 8.0.0; SM-G950F Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3025.4 Mobile Safari/537.36 GoodAccess/2.9.0.1340

The default value Windows matches only a subset of the possible browsers that may access Qlik Sense so many would not be able to achieve Kerberos Single SignOn even if they are capable of it. Qlik suggests modifying this to Mozilla, but also recommends first creating an additional Virtual Proxy which accepts Forms authentication (Windows authentication pattern = Forms) as an alternate/fallback way to access the Qlik Management Console.


Here, rather than modifying the Default Virtual Proxy, we've created a Virtual Proxy specifically for testing this integration:

sso-mozilla.png


Then enable Kerberos authentication in the properties of the Proxy.

sso-proxy.png


iOS Device

It may surprise, but yes even though your iPad is not a member of your Windows Domain, it can be configured to perform Kerberos authentication.  You'd be periodically asked to enter your Domain Password to reestablish a TGT, but a list of Apps can be configured to use your TGT to request a Service Ticket for a collection of URLs and perform Kerberos Authentication into those sites without any further User Interaction.

Inspect kerberos.mobileconfig XML file below.  This can be delivered to an iOS device as an Email Attachment, and when opened, it will configure the device to enable Kerberos Authentication from specific applications to specific websites. The example below is configured to support Safari, Chrome and experimentally a few other applications.

When you open this as an attachment in the iOS Mail client, you’re prompted to install it, and eventually asked for your Principal Name. Enter only your Domain UserID. This is combined with the Realm to form the identity that will be used for all subsequent Kerberos interactions, and corresponds with the userPrincipalName in Active Directory. If you want to view or delete this profile from iOS, you’ll find it at the bottom of the General section of the Settings application.

kerberos.mobileconfig

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>PayloadContent</key>

  <array>

    <dict>

      <key>PayloadType</key>          <string>com.apple.sso</string>

      <key>PayloadVersion</key>      <integer>1</integer>

      <key>PayloadIdentifier</key>    <string>com.example.sso.test.kerberos</string>        <!-- Change This -->

      <key>PayloadUUID</key>          <string>d86b6548-5300-460e-89e1-31e19034982d</string>  <!-- Change This -->


      <!-- See https://www.guidgenerator.com/online-guid-generator.aspx -->


      <key>PayloadDisplayName</key>  <string>SSO profile for yourCompany</string>    <!-- Change This -->

      <key>PayloadDescription</key>  <string>Configures Kerberos Single Sign On</string>

      <key>PayloadOrganization</key>  <string></string>

      <key>Name</key>                <string>Kerberos Config</string>

      <key>Kerberos</key>

        <dict>

          <key>Realm</key>            <string>EXAMPLE.COM</string>      <!-- Change This -->

          <key>URLPrefixMatches</key>

            <array>

              <string>https://portal.example.com/</string>


              <string>https://sense.example.com</string>

              <string>https://sense.example.com:4244</string>

              <string>http://sense.example.com</string>

              <string>http://sense.example.com:4248</string>

            </array>

          <key>AppIdentifierMatches</key>

            <array>

              <string>com.apple.mobilesafari</string>          <!-- Safari                -->

              <string>com.google.chrome.ios</string>          <!-- Chrome                -->

              <string>com.opera.OperaMini</string>            <!-- Opera Mini            -->

              <string>com.dolphin.browser.iphone</string>      <!-- Dolphin                -->

              <string>com.initlabs.webview</string>            <!-- WebView                -->

              <string>com.microsoft.msedge</string>            <!-- Microsoft Edge Browser -->


              <string>com.airwatch.secure.browser</string>    <!-- VMware Browser        -->

              <string>com.mobileiron.securebrowser</string>    <!-- MobileIron web@work    -->

              <string>com.good.gdgma</string>                  <!-- BlackBerry Access      -->


              <string>com.qlikview.QlikView</string>          <!-- QlikView Mobile        -->

              <string>com.qlikview.gd.qlikview</string>        <!-- QlikView for Good      -->

              <string>com.qlik.qliksense.mobile</string>      <!-- Qlik Sense Mobile      -->

            </array>

          </dict>

      </dict>

  </array>

  <key>PayloadDescription</key>          <string>Sets up Safari and other Apps to use Kerberos SSO for certain URLs</string>

  <key>PayloadDisplayName</key>          <string>KerberosConfigProfile</string>

  <key>PayloadIdentifier</key>            <string>com.example.ssoconfig</string>  <!-- Change This -->

  <key>PayloadOrganization</key>          <string>yourCompany</string>            <!-- Change This -->

  <key>PayloadRemovalDisallowed</key>    <false/>

  <key>PayloadType</key>                  <string>Configuration</string>

  <key>PayloadUUID</key>                  <string>30EA9E5A-E570-462F-8027-75D1BC136ADA</string> <!-- Change This -->

  <key>PayloadVersion</key>              <integer>1</integer>

</dict>

</plist>

Customers who choose to follow this approach should modify the Kerberos Realm, update the list of Kerberos-enabled URLs, and should really update several of the Payload properties and UUIDs. This approach and guidance is supported by Apple, not Qlik!

Kerberos Constrained Delegation

The approach described above is applicable only to iOS devices, requires the user to occasionally re-enter their password (to refresh the TGT) and requires traffic (88/tcp) between the mobile device and the Kerberos Distribution Center, and manages the Kerberos Ticket Cache on the device itself.

An alternative is available which enables more device types, does not require the user to enter any credentials, eliminates client traffic to the KDC, and manages the Kerberos Ticket Cache on a "man in the middle". This is called Kerberos Constrained Delegation and is available with many VPN products.

sso-kcd.png

An SSL Client Certificate would be deployed to the mobile device using an Enterprise Mobility Management tool and used for Device Authentication from the VPN Client to the VPN Gateway. The VPN Gateway can determine the User's Identity from the SSL Client Certificate, and (with elevated rights in Active Directory) request Kerberos Service Tickets on the user's behalf. The Kerberos Ticket Cache is managed on/near the VPN Gateway server.

The VPN Gateway is probably running on a Linux host without a Domain relationship with the Active Directory. It will operate using a Kerberos KeyTab that represents an identity in the Active Directory, and THAT identity must be granted Constrained Delegation Rights (permission) to request Service Tickets for specific destinations (Service Principal Names) on behalf of the end users.

The Qlik requirements for this approach remain the same as above. The integration is performed within the EMM-managed VPN/Connectivity product, and customers are advised to seek guidance from their EMM vendor.

WebClips

A WebClip is the Mobile version of placing a shortcut on your Windows Desktop.

In combination with Kerberos Single SignOn it's a very appealing way for online users to navigate directly to a Qlik Sense Dashboard without any further User Interaction.

A WebClip is normally created using the EMM Suite, contains a URL, an Icon, and optional properties such as whether the user can delete it themselves, and if the URL should be opened in FullScreen/Kiosk mode.

This is further described at Configure a shortcut to a specific Dashboard

Tags (1)
Community Browser