Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
May 11, 2021 9:18:09 AM
Jan 7, 2019 8:08:14 AM
Authentication of end users is, with exception of the built-in Custom Users, handled in the QlikView authentication module. Through this design QlikView doesn’t handle authentication in itself. Instead, it relies on external 3rd party for performing the actual step of validating a user credentials.
This approach to handling credentials also means that QlikView doesn’t have its own way of enforcing a password policy. The authentication method configured will utilize an existing credentials store, which in itself needs to apply the applicable password policy. Additionally, QlikView relies on it for keeping track of failed user login attempts. Should brute force attacks be a genuine concern it is recommended that restrictions on the number of failed logins are implemented in the backend credential checker.
Environment
Log in
The administrator of a QlikView deployment can create and deploy a custom authentication module, tailored to any specific requirements that may be needed. By default, the following are the options that QlikView is offering:
- NTLM authentication
- Anonymous authentication
- Header authentication
When performing a log in, QlikView will not actively show the end-user any information about last successful or last failed login. This is not considered a feature that QlikView should support. The logs will contain traces of which user logs in when, and should be audited by the administrator for suspected behavior. Should a feature of presenting the user with information during login be a requirement, it can always be implemented using a custom authentication module. By building the authentication module from the ground up, any interaction with the user pre/post authentication can be added by the administrator.
Log out
A part of authentication is the ability to not be authenticated anymore, i.e. log out. The user will always have the ability to log out, with one limitation related to the NTLM authentication mode. If that case, the user logs out, and if refreshing the page, the browser will utilize its internally cached session and log the user back in automatically. Although this is something that is out of the direct control of QlikView, the behavior can be mitigated. The administrator would have to configure QlikView through the QMV to use the HTML form login method.
Authentication methods
NTLM
By default, the authentication system used is NTLM based, meaning that the system will ask the user to authenticate through the network Active Directory or local system account.
Web form authentication
In QlikView prior to version 11.20 SR3, the web form login method used HTTP BASIC authentication. In 11.20 SR3 this was upgraded to a more secure method of authenticating the user, which instead was designed to be based on NTLM authentication.
The main reason for this change was that by using NTLM authentication the user credentials would be handled in a more secure way. This is due to the NTLM method sending the credentials by POST, while HTTP BASIC sends them as part of a HTTP BASIC header. Also, web browsers are caching HTTP BASIC information, which meant that users who logged out would be able to log back in automatically without having to specify credentials.
When using “Authentication - Type - Custom User” and “Login Address - Alternate login page (web form)”, the login page “FormLogin.htm” will be applied instead of “login2.htm”. This means that customers using customized login pages built on “login2.htm” have to migrate to customized version of “FormLogin.htm”.
The web form login page has in older versions of QlikView included an autocomplete ability on the input fields. This has subsequently been fixed and should this be a concern, it is recommended that QlikView is upgraded to a later version.
Anonymous authentication
This will allow a user to access information in QlikView without having to authenticate. This is normally something that is enabled on installations that will cater to a large audience of users and only present non-sensitive data.
Header authentication
Header authentication should not be used standalone. Instead it is a way for allowing a reverse proxy to sit between the user and QlikView. The reverse proxy would then be in control of authenticating the user, and when satisfied, inject a specific header to identify the user towards QlikView.
QlikView would in this setup never be reached directly by the end-user.
To enable header authentication, the administrator needs to navigate to the QMC. Under "QlikView Web Servers", the webserver in question should be selected. In the tab "Authentication", choose the option "Header" in the "Type" radio-button choice. Make sure to specify "Header name" and/or "Prefix" in the form input under "Parameters". Note, only a single Prefix value may be specified, so if multiple domains/directories are in use, that will have to be resolved in the front-end SSO solution in these cases, as QVWS settings will only accommodate a single Prefix value. Multiple QVWS resources could be used in this case to solve the issue as well, one for each domain and the front-end would need to resolve which QVWS instance to send the user based upon their domain/directory.
In this example, the header name "ntuserdomainid" has been chosen, but the administrator is free to set this according to needs. Important to note however is that the name must be used consistently throughout the configuration.
The settings made in the QMC will be reflected in the web server configuration file:
The xml configuration "<AuthenticationHeaderDelimiter>:</AuthenticationHeaderDelimiter>" will allow the administrator to specify how the domain and user values are delimited. This is especially important when deploying QlikView behind a SiteMinder reverse proxy. The SiteMinder proxy will use the character ":" instead of the usual "/", which means that the xml setting above is necessary to integrate with SiteMinder.
Configure IIS for header authentication
When deploying through IIS instead of the QlikView Web Server, the following settings are needed.
Make sure that “Authentication” option “Anonymous Authentication” is set to “Enable“ and all other authentication options are set to “Disabled” for:
The files:
AccessPoint.aspx
Authenticate.aspx
QvsViewClient.aspx
The folders:
QvAjaxZfc/
QlikView/
Limitations in the Header Authentication feature
If the Authentication type option is modified in the QMC, the manually configured setting <AuthenticationHeaderDelimiter> will be deleted from the web server configuration file. As a consequence, the setting must be manually re-set again in the configuration file after that the Header authentication type option is re-selected in the QMC.
It is also highly recommended that HEADER authentication is deployed with authorization setting DMS in the QMC, see figure 1. The recommendation is based on possible problems that could be caused by applying NTFS authorization combined with HEADER authentication.
Make sure that the original and unmodified Authenticate.asp(x) is located in %PROGRAMFILES%\QlikView\Server\QlikViewClients\QlikViewAjax
This is an example (default) Authentication.aspx:
<%@ Import Namespace="QlikView.AccessPoint" %>
<%@ Import Namespace="QlikView.AccessPoint.HttpInterfaces" %>
<%@ Import Namespace="QvIISWebServer" %>
<%@ Page Language="C#" AutoEventWireup="true" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e) {
Response.Clear();
Context context = this.GetContext();
context.Response.AddVersionHeader();
PIX.QVWebServer.HeaderAuthentication headerAuthentication = context.Settings.Authentication.HeaderAuthentications.Find(a => a.Url.EndsWith("/QvAJAXZfc/Authenticate.aspx", StringComparison.InvariantCultureIgnoreCase));
if (headerAuthentication != null)
{
QlikView.AccessPoint.User.HeaderAuthentication(context, headerAuthentication.Header, headerAuthentication.Prefix);
return;
}
PIX.QVWebServer.DSCAuthentication customUserAuthentication = context.Settings.Authentication.DSCAuthentications.Find(a => a.Url.EndsWith("/QvAJAXZfc/Authenticate.aspx", StringComparison.InvariantCultureIgnoreCase));
if (customUserAuthentication != null) {
string loginAddress = context.Settings.Authentication.LoginAddress.ToLower();
if (loginAddress == "/qlikview/login.htm" || (loginAddress != "/qlikview/formlogin.htm" && context.Settings.Authentication.BasicAuthenticationForCustomLogin))
{
//either default login page or a custom login page (=not alternate) that use basic authentication
QlikView.AccessPoint.User.ServiceAuthentication(context, customUserAuthentication.Prefix);
}
else
{
QlikView.AccessPoint.User.WebFormAuthentication(context, customUserAuthentication.Prefix);
}
return;
}
if (context.Settings.Authentication.LoginAddress != "/qlikview/login.htm")
{
QlikView.AccessPoint.User.WebFormAuthentication(context);
}
else
{
QlikView.AccessPoint.User.HttpAuthentication(context);
}
}
</script>
Authentication redirect filtering
To protect Authenticate.aspx against unsafe redirect abuses, protection mechanism has been implemented which enables QV administrators to specify a trusted host list, to which the clients are allowed to be redirected. This is based on URLs provided in the try and back arguments.
A redirect abuse issue is a scenario where an attacker utilizes an URL trusted by a victim, but modifies it to redirect the victim to a site controlled by the attacker.
As an example, the following URL has been modified to redirect the user of it to malicioussite.com.
When accessing the link, which visually looks authentic, a redirect to http:// malicioussite.com/loginpage.htm will be made by the QV webserver, because the provided webticket in the URL is invalid. The malicious site now controls the user and can do anything, such as disguising itself as the authentic site to trick the user into typing in valid credentials to the original site.
By default, there is no filtering on the “try” and “back” parameters when accessing Authenticate.aspx. If filtering is deemed necessary, the file “config.xml” located in “%PROGRAMDATA%\QlikTech\WebServer” needs to be updated.
The filtering can be enabled in the config.xml file in two ways; normal and strict filtering.
Normal filtering is enabled using the setting “SafeForwardList” coupled with one or several “TrustedHost” elements. By enabling this, the specified host or domain name IP will be resolved and used when redirecting.
Restrictions and considerations to take into account when configuring filtering:
- QVWS host is always considered as trusted host.
- TrustedHost can be entered as an IP address, domain or hostname.
- Host and domain names are case insensitive.
- Redirects to loopback address is prohibited unless specified in the Settings.
- Only absolute URLs/paths are accepted in the try and back arguments when filtering is enabled.
Strict filtering is a variant of the filtering that takes the specified hosts literally. This mean that while normal filtering will accept any IP that answers to the specified host or domain name, the strict filtering will only redirect to the specified host or domain name. The strict filtering is recommended to be used if the DNS is not trusted or configured to reply with multiple IPs for a specified name.
Filtering examples:
<Authentication>
<SafeForwardList>
<TrustedHost>qlikserver.com</TrustedHost>
<TrustedHost>qliktechserver.com</TrustedHost>
<TrustedHost>10.22.33.44</TrustedHost>
</SafeForwardList>
</Authentication>This setting will make sure to only redirect to hosts qlikserver.com, qliktechserver.com and IP “10.22.33.44”. The IP’s that the hostnames resolve to will also be allowed.
<Authentication>
<SafeForwardList>
<TrustedHost> qlikserver.com</TrustedHost>
</SafeForwardList>
</Authentication>This will allow the hostname qlikserver.com and any IP that it resolves to.
<Authentication>
<StrictSafeForwardList>
<TrustedHost>qlikserver.com</TrustedHost>
</StrictSafeForwardList>
</Authentication>This will only allow redirects to the hostname qlikserver.com, regardless of the IP(s) it resolves to.
