The QlikView authentication API is designed to be used by the Authenticate.aspx web page. The web page can be customized using IIS to handle all three steps of sending, validating, and transferring a user’s credentials to the QlikView web session.
This is typically necessary when there is an existing user repository (for example, LDAP or a database), but no existing web‑based authentication server that can be used to integrate with it. In this case, the web‑based authentication system has to be created and it may be simpler to create it as part of the QV web tier, as opposed to making a separate authentication system.
This solution is also suitable in integrations with cloud-based authentication systems, where it is not possible to configure the authentication system to call the QlikView platform in a custom way (that is, using headers or WebTicket). In this scenario, the QlikView web tier has to be adapted to the requirements of the cloud system. A good example of this is salesforce.com.
The development environment for Authenticate.aspx is supplied in .NET languages.
The procedure for logging in is as follows:
- The user logs in to IIS using any authentication system. This typically means that the user ID and password are sent to IIS, but it may also mean that the user’s fingerprint or a one‑time token from a cloud authentication provider is sent.
- The customized Authenticate.aspx checks the details towards an external security system (for example, an LDAP server, an SAML identity provider, or salesforce.com).
- If successful, Authenticate.aspx transfers the user information (potentially including groups) to the QVS.
Attached below is an example of a custom login form leveraging on a modified Authenticate.aspx page to perform a user authentication against LDAP.
The DSC should be configured in QlikView Management Console to perform authorization of the user once passed to AccessPoint.
The DSC should also be able to handle the group resolution (although the Authentication API allows passing of groups to QlikView from LDAP). Do take note when using the example to ensure all the LDAP syntax is correct. The main things to look for there is having the correct connection string (easy to validate via QMC or using LDAP Administrator) and the correct search filter to find your user.
Note: If all your users are in the same OU you can hardcode that part and just use the username from the login form, essentially skipping the user search and just try to log in directly to the LDAP server with the user provided credentials to test the authentication. If you have users spread over OUs you'll need to look up the user to build the correct username for testing the user authentication.
I've commented up the code in the attached example for easy understanding.