Skip to main content
Woohoo! Qlik Community has won “Best in Class Community” in the 2024 Khoros Kudos awards!
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
MichaelRobertshaw
Former Employee
Former Employee

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

Term Description
AD Active 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.

FQDN Fully Qualified Domain Name. If your machine is called "myserver" then it's FQDN might be "myserver.example.com"
KDC Kerberos 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
UPN A 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

TGT A 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/Platform HTTP User Agent
Chrome/Windows Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Firefox/Windows Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
IE11/Windows Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Safari/iOS Mozilla/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/iOS Mozilla/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/iOS Mozilla/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/iOS Mozilla/5.0 (iPad; CPU OS 11_3 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Mobile/15C114
Chrome/Android Mozilla/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/Android Mozilla/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
QSM4BBD/iOS Mozilla/5.0 (iPad; CPU OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15G77

 

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

3 Replies
JackyNikson
Contributor
Contributor

Wow! Great! Thank you for sharing this information with us!

Finish it finally. And you feel peace.
Whidegroup - https://whidegroup.com/services/
mk_kmx
Partner - Contributor III
Partner - Contributor III

@MichaelRobertshaw  Could you maybe please elaborate on the "Qlik Authentication in pseudocode" part? How is the NTLM fallback part working?

 

The reason why I'm asking - after enabling Kerberos, several things stopped working, even if they were working fine with NTLM. To be specific:

  1. Monitoring Apps (and all other Qlik REST Connector-based apps when querying QRS with Kerberos enabled)
  2. Even my REST client (I'm using Insomnia because of some issues with Postman).

Issue is, that when I select NTLM as authentication schema on a Client side (those apps do not have an option to select Kerberos), server returns WWW-Authenticate: Negotiate, which is a Kerberos-related request.

I get it, I've enabled Kerberos, so it's used (surprise! 🙂 ). 

Is there maybe a way to tell Qlik Sense, that Client wants to use NTLM instead of Kerberos? Or is there some standard way to just tell a client to proceed to a first fallback option = NTLM?

 

Many thanks.

 

@Sonja_Bauernfeind Michael hasn't logged in to community for a year. Could you maybe forward us to someone else who could help? Many thanks.

kateroshh
Partner - Contributor
Partner - Contributor

Hello! 

Please tell me in more detail what I will need to do in qmc to work links qliksenselinks://.......

I have read your comment:

https://community.qlik.com/t5/Mobile/URL-to-open-a-mashup-using-Qlik-Sense-Mobile/td-p/1702203

But I couldn't figure out what exactly to do.