Skip to main content

Authentication solutions

Qlik Sense authentication can be managed with any of the following solutions:

  • Ticket solution
  • Session solution
  • Header solution
  • SAML
  • JWT
  • OIDC
  • Anonymous users
  • Configuring single sign-on (SSO) from Microsoft SQL (MSSQL) server

Ticket solution

The ticket solution is similar to a normal ticket. The user receives a ticket after having been verified. The user then brings the ticket to Qlik Sense and, if the ticket is valid, is authenticated. In order to keep the tickets secure, the following restrictions apply:

  • A ticket is only valid for a short period of time.
  • A ticket is only valid once.
  • A ticket is random and therefore hard to guess.

All communication between the authentication module and the Qlik Sense Proxy Service (QPS) uses Transport Layer Security (TLS) and must be authorized using certificates.

The figure below shows a typical flow for authenticating a user with tickets.

1. The user accesses Qlik Sense. 2. Qlik Sense redirects the user to the authentication module. The authentication module verifies the user identity and credentials with an identity provider. 3. Once the credentials have been verified, a ticket is requested from the QPS. Additional properties may be supplied in the request. 4. The authentication module receives a ticket. 5. The user is directed back to the QPS with the ticket. The QPS checks that the ticket is valid and has not timed out. 6. A proxy session is created for the user. 7. The user is now authenticated.

  1. The user accesses Qlik Sense.
  2. Qlik Sense redirects the user to the authentication module. The authentication module verifies the user identity and credentials with an identity provider.
  3. Once the credentials have been verified, a ticket is requested from the QPS. Additional properties may be supplied in the request.
  4. The authentication module receives a ticket.
  5. The user is redirected back to the QPS with the ticket. The QPS checks that the ticket is valid and has not timed out.
  6. A proxy session is created for the user.
  7. The user is now authenticated.

For information about the Authentication (Ticket) API for the Authentication module, see Ticket.

Session solution

The session solution allows the Qlik Sense Proxy Service (QPS) to use a session from an external system to validate who the user is.

All communication between the authentication module and the QPS uses Transport Layer Security (TLS) and must be authorized using certificates.

The figure below shows a typical flow for authenticating a user using a session from an external system.

1. The user accesses the identity provider, which, for example, can be integrated into a portal. The identity provider gets the user identity and credentials and then verifies them. After that, the identity provider creates a new session. 2. The identity provider registers the session token with the Qlik Sense session module. 3. The identity provider sets the session token as a session cookie. 4. The user accesses the QPS to get content (for example, through an iframe in the portal). 5. The QPS validates the session to the session module. 6. If the session is valid and has not yet timed out, the user is authenticated.

  1. The user accesses the identity provider, which, for example, can be integrated into a portal. The identity provider gets the user identity and credentials and then verifies them. After that, the identity provider creates a new session.
  2. The identity provider registers the session token with the Qlik Sense session module.
  3. The identity provider sets the session token as a session cookie.
  4. The user accesses the QPS to get content (for example, through an iframe in the portal).
  5. The QPS validates the session to the session module.
  6. If the session is valid and has not yet timed out, the user is authenticated.
Tip: The name of the session cookie used by the authentication module can be configured in the Qlik Management Console (QMC).

For more information about the session module, see Session module API.

Header solution

Header authentication is often used in conjunction with a Single Sign-On (SSO) system that supplies a reverse proxy or filter for authenticating the user.

The figure below shows a typical flow for authenticating a user using header authentication.

1. The user accesses the system and authenticates to the reverse proxy. 2. The reverse proxy injects the username into a defined HTTP header. The header must be included in every request to the Qlik Sense Proxy Service (QPS). 3. The user is authenticated.

  1. The user accesses the system and authenticates to the reverse proxy.
  2. The reverse proxy injects the username into a defined HTTP header. The header must be included in every request to the Qlik Sense Proxy Service (QPS).
  3. The user is authenticated.
Note: For this solution to be secure, the end-user must not be able to communicate directly with the QPS but instead be forced to go through the reverse proxy/filter.
Note: The reverse proxy/filter must be configured to preserve the host name, that is, the host header from the client must not be modified by the reverse proxy/filter.
Tip: The name of the HTTP header used for the user can be configured in the Qlik Management Console (QMC).

SAML

Security Assertion Markup Language (SAML) is an XML-based, open-standard data format for exchanging authentication and authorization data between parties (for example, between an identity provider and a service provider). SAML is typically used for web browser single sign-on (SSO).

How SAML works

The SAML specification defines three roles:

  • Principal: Typically a user
  • IdP: The identity provider
  • SP: The service provider

The principal requests a service from the SP, which requests and obtains an identity assertion from the IdP. Based on the assertion, the SP decides whether or not to perform the service requested by the principal.

SAML in Qlik Sense

Qlik Sense supports SAML V2.0 by:

  • Implementing an SP that can integrate with external IdPs
  • Supporting HTTP Redirect Binding for SAML requests

  • Supporting HTTP Redirect Binding and HTTP POST Binding for SAML responses

  • Supporting SAML properties for access control of resources and data

Limitations:

  • Qlik Sense does not support SAML message signature validation.

JSON Web Token (JWT)

JSON Web Token (JWT) is an open standard for secure transmission of information between two parties as a JavaScript Object Notation (JSON) object. JWT is used for authentication and authorization. Because JWT enables single sign-on (SSO), it minimizes the number of times a user has to log on to cloud applications and websites.

How JWT works

A JWT consists of three parts: a header, a payload, and a signature.

  • The header usually consists of two parts: type (typ) and algorithm (alg). The algorithm is used to generate the signature.

  • The payload is a JSON object that consists of the claims that you want to make. Claims are statements about an entity (usually the user) and additional metadata.

  • The signature is used to verify the identity of the JWT sender and to ensure that the message has not been tampered with.

Authentication is performed by verifying the signature. If the signature is valid, access is granted to Qlik Sense.

Limitations

The following limitations exist:

  • Encrypted JWTs are not supported.

    Note: When using HTTPS, all traffic, including JWTs, are encrypted during transport.
  • Only the following signing algorithms are supported:

    • RS256 - RSA signature with SHA256

    • RS384 - RSA signature with SHA384

    • RS512 - RSA signature with SHA512

OpenID Connect

OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. OIDC enables single sign-on (SSO) to reduce the number of times a user has to log on to access websites and applications. OIDC can be configured for authentication with third-party products.

How OIDC works

OIDC is an open standard that uses JSON format authentication. OIDC uses the same components and architecture as OAuth, but to authenticate. Applications that use OIDC work with any identity provider that supports the authentication protocol. The protocol supports identity verification when a user tries to access a protected endpoint.

Workflow

  1. A user accesses an application and is redirected to the OIDC identity provider for authentication and authorization.

  2. The user logs in with the OIDC identity provider.

  3. The OIDC identity provider sends a response to the application that a user has been authenticated and authorized.

  4. The application requests user information from the OIDC identity provider.

  5. The OIDC identity provider responds with the required user information.

Anonymous users

If anonymous use of Qlik Sense is allowed, users who are not authenticated are not automatically redirected to an authentication module. Instead, the user first gets anonymous access and is then, if the user chooses to sign in, redirected to the authentication module to supply user identity and credentials.

Configuring single sign-on (SSO) for Microsoft SQL (MS SQL) Server

If your database files access data from MS SQL Server, you can configure the host server to enable SSO. ODBC data source single sign-on permits clients to use one Windows authenticated login to access data in shared files.

To configure SSO for MS SQL Server, a Windows domain administrator must do the following:

  • Create service principal names (SPN) in Active Directory
  • Configure delegation for the Qlik Sense services administrator account
  • Configure the Qlik Sense server for SSO
  • Configure the MS SQL Server for SSO
Warning: The Microsoft SQL Server Connector in the Qlik ODBC Connector Package also supports SSO. If you are using the connector in the ODBC Connector Package, use the following configuration instructions: Configuring SSO for the Microsoft SQL Server connector.
Warning: The same Qlik Sense services administrator account used during the Qlik Sense (central node) installation must be used. If a different account is used, the Qlik Sense services administrator account must own the HTTP service principal. For more information, see User accounts.

Creating service principal names (SPN) in Active Directory

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used during authentication to associate a service instance with a service logon account. This allows a client application to request that a service authenticate an account even if the client does not have the account name. A SPN always includes the name of the host computer on which the service instance is running, so a service instance might register a SPN for each name or alias of its host.

Before the authentication service can use a SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the account of a service instance changes, the SPNs must be re-registered under the new account.

When a client connects to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate.

To set up SSO for MS SQL server, you must create SPNs for the Qlik Sense services administrator account.

  1. Log on as a domain administrator.
  2. Open an elevated command prompt.
  3. Enter the following to create a SPN for the Qlik Sense services administrator:

    setspn -A HTTP/<Qlik_Sense_server>:<port> <domain>\<Qlik_Sense_services_administrator>

    Note: The <Qlik_Sense_server> must be entered as the fully qualified domain name of the server.
    Note: The <Qlik_Sense_server> is the central node where the Qlik Sense is running.
  4. Enter the following to create a SPN for the MS SQL Server services administrator:

    setspn -A MSSQLSvc/<server_name>:<port> <domain>\<services_administrator>

    Note: The <server_name> must be entered as the fully qualified domain name of the server.
  5. Enter the following commands to verify the result of your SPN setup:
    1. setspn -L <domain>\<Qlik_Sense_services_administrator> to verify the Qlik Sense services administrator.
    2. setspn -L <domain>\<MS_Sql _server_services_administrator> to verify the MS SQL Server services administrator.

Configuring delegation for the Qlik Sense services administrator account

Delegation allows a front-end service to forward client requests to a back-end service so that the back-end service can also impersonate the client. Impersonation is used to check whether a client is authorized to perform a particular action, while delegation is a way of flowing impersonation capabilities, along with the client’s identity, to a back-end service.

To configure SSO for MS SQL Server, you must set up delegation rights to the MS SQL Server service for the Qlik Sense services administrator.

A Windows domain administrator can change the delegation tab on the Qlik Sense services administrator account properties page.

  1. Log on as a Windows domain administrator.
  2. Right click on your Qlik Sense services administrator account and click Properties.
  3. Go to the Delegation tab, and select Trust this user for delegation to specified services only, then select Use any authentication protocol.
  4. Click Add....
  5. On the Add Services window, click Users or Computers....
  6. On the Select Users or Computers window, enter the domain and user name of the Microsoft SQL Server services administrator and click OK.
  7. On the Add Services window, select the MS SQL Server service and click OK.

You can verify your delegation configuration on the Delegation tab. The MS SQL Server service should now be set as the service to which the Qlik Sense services administrator can present delegation credentials.

Configuring the Qlik Sense server for SSO

To configure the Qlik Sense server for SSO with MS SQL Server, you must:

  • Add the Qlik Sense services administrator to the Administrator group on the Qlik Sense server if it's not already part of that group.
  • Add Qlik Sense services administrator as part of the Act as part of the operating system role in the Local Security Policy.
  1. Log on to the Qlik Sense server as an administrator.
  2. Open Local Security Policy, and go to Security Settings > Local Policies > User Rights Assignment.
  3. Under Policy, right click on Act as part of the operating system and select Properties.
  4. On the Local Security Setting tab, click Add User or Group....
  5. Add the Qlik Sense services administrator account, and click OK.

Configuring MS SQL Server

To configure the MS SQL Server for SSO, you must ensure that the MS SQL Server service runs as the MS SQL Server services administrator.

  1. Log on to the MS SQL Server as an administrator.
  2. Open the Sql Server Configuration Manager.
  3. Select SQL Server Services.
  4. Select SQL Server in the right pane and verify that the Log On As column is populated with your MS SQL Server services administrator account.
Note: You must reboot after making changes to remove the SQL self registration of the SPN under machine account and register the SPN manually on the domain account.