Authentication

QlikView requires that the user is authenticated when establishing a session via QlikView Server (either through a browser or when downloading and opening a document via the QlikView Desktop client). Although the majority of implementations require users to be authenticated, QlikView can also be configured to allow anonymous access

In the QlikView context, the authentication of a user is almost always done against an external entity that is then used to pass the externally authenticated user identity to QlikView Server. In such a scenario, QlikView relies on the authentication to be performed prior to accessing QlikView, and that some token of identity is transmitted to, and trusted by, QlikView.

Authentication when Using QlikView Server in a Windows User Environment

Authentication to a QlikView Server in an environment based on Windows users (for example, incorporating Active Directory) is straightforward. The process is as follows:

 

1. The user credentials are validated when the user logs in to the Windows operating system on the client machine.
2. Later when the user wants to establish a session with a QlikView Server (QVS) (for example, via a browser on the desktop), QVS can use the built-in Integrated Windows Authentication (IWA).
3. The identity of the logged-in user is communicated to QlikView Server using either the Kerberos or the NTLM security solution. This solution provides single sign-on capabilities right out of the box. In case the authentication exchange fails to identify the user, the browser prompts the user for a Windows user account name and password.

The figure below shows the standard authentication flow for IWA:

The figure below shows the authentication flow for the combination of NTLM and alternate login, which differs from the standard flow for IWA:

The authentication process differs based on the environment:

• Local Area Network (LAN): IWA is most common and most suitable for recognizing Windows users on a LAN. The act of authentication is performed when logging in the workstation, and this identity is leveraged by QlikView.
• Multi-domain environment: The internal company network IWA should be avoided in architectures where there is a multi-domain environment with no trust relationship between the domain of the workstation and the domain of the server, or when used across a reverse proxy. In such an environment, configure the QlikView deployment to use either an existing external SSO service or a QlikView custom ticket exchange to expose an authenticated identity to QlikView.

Authentication with a QlikView Server Using an Existing Single Sign-on Software Package

In environments where an SSO infrastructure already exists (for example, CA SiteMinder®, IBM® WebSeal, or Oracle® Oblix), QlikView can use the HTTP header injection method of single sign-on provided by the SSO infrastructure. This means single sign-on is provided right out of the box. The SSO infrastructure software packages can be configured as follows:

• Repeat user get access: The software packages can be configured to protect a resource. When a user requests access to QlikView, the SSO package grants access, if the user has previously signed in to the SSO authentication page.
• New user log in: If the user does not have an existing session with the SSO package, the user is redirected to the SSO package login page. After logging in, the user is redirected to the original URL that the user requested.

In both cases, if the user has properly authenticated to the SSO software, the username is injected into an HTTP header and the value in that header is what the QlikView server accepts as the authenticated identity of the user.

QlikView does not recommend or endorse any specific tool or product for providing identity in HTTP headers. The approach is highly suited to extranet deployments wherein the users may not exist in the internal Active Directory. The act of authentication is performed by the reverse proxy or ISAPI filter that intercepts the attempt of the end user to interact with QlikView content.

Authentication Using neither IWA nor Single Sign-on Software

QlikView provides a third method for single sign-on, Custom Ticket Exchange (CTE), when neither of the methods described above is suitable.

CTE relies on the user having authenticated previously to another system:

1. The third-party system is granted the privilege and responsibility to request an authentication token (called a “ticket” in QlikView) from QVS on behalf of the authenticated user of the third-party system. It is the responsibility of the third-party system to only request tickets for users that have been properly authenticated (for example, QVS has no knowledge of the authentication status of the user).
2. The system then passes the authentication token to the user, who uses it in a request to open a session with QVS.
3. QVS checks that the ticket is valid and then opens a session for the authenticated user.

Ticketed authentication is mainly applicable when embedding QlikView content in third-party applications and portals, and is rarely used for providing general access to QlikView. Typically a small amount of custom development is needed to implement the request and passing of the ticket for the CTE method to work.

QlikView Server Authentication Using Custom Users

The three methods described above all use a single sign-on principle, where the user ID and password are stored externally to QlikView Server and an external entity is responsible for the authentication. Less common, although possible, is the ability to store the user credentials in the QlikView Server environment using the Custom Users functionality in QlikView Publisher. In this case, users and passwords are defined and stored within the QlikView environment and the web tier of the QlikView deployment is responsible for forms authentication. This solution is suitable for smaller, standalone QlikView Server deployments, and must not be used in environments where the user definitions are to be available to multiple systems. In such environments, it is highly recommended to use one of the three single sign-on solutions described above.

Each coexistent form of authentication may require a distinct web server instance. Several web servers can forward user requests to the same QVS instance(s).