Phase I. Initialization. Research. Code Review. Troubleshooting. Login.aspx. M3THOD, LLC Project Documentation

Transcription

1 Client: J.H. Cohn Project: QlikView Login & Deployment Date: May 16, 2011 Phase I Initialization Research Obtained credentials for connecting to the DMZ server. Successfully connected and located the file paths for the various website running on the localhost. Specifically orientate structure of QlikView, QvAjaxZfc, and the root path. Troubleshooting IIS Manager Configuration Under Web Site Properties, confirm that the Directory Security allows for Integrated Windows Authentication for child applications Web Configuration In the web.config file, assert that the authentication tags allow for Windows and Forms mode. Internet Browser Settings Code Review Login.aspx The ability to pass Windows credentials between websites is typically a function of the web browser itself; subsequently Internet Explorer is the only officially supported browser to achieve hand off of authenticated Windows users. At this, it is only possible when both websites exist on the same Intranet, and the security zone settings for IE must be set to Automatic logon only in Intranet zone to behave correctly. (Tools- >Internet Options->Security Tab->Local intranet->custom level scroll down to the bottom and select this option in User Authentication ) Basic server postback to an event handler on click. P a g e 1

2 Login.aspx.cs Enumerated system libraries available, tested the following methods for creating Windows credentials and passing authenticated Windows users between multiple websites on a single Intranet \qlickview\index.htm Tracing the scripting login that successfully creates session authentication for QlikView on the Access Point login page exposed several ancillary javascript libraries that expose a QlikView API client object, specifically qva. \htc\ The Access Point control references AJAX libraries that exist in the \htc\ directory. Tracing the login logic through these files drilled down to a TryLogin function that contained the QlikView logic for authentication which was being called by the Access Point login protocol. Solution Development QlikView Access Point Implementation After reviewing the login processes that occurs when a user arrives at we identified several QlikView javascript library functions that were being used to properly authenticate and log the session validity of the user. Login.aspx Incorporating references to these QlikView libraries so the client-side objects and functions were available, we exposed the same functionality used by the access point (qlikview/index.htm). Basic modifications to identifiers, html mark-up, and white space were also completed. Similarly to the QlikView login protocol, we added a JavaScript function to be called when a user clicks the login button which operates using the information provide in the subsequent username and password fields legacy to the login screen. This script posts by default to the QlikView authentication service running at /QvAJAXZfc/Authenticate.aspx which properly validates the user session and returns a successful state. Once a successful state is received on callback, the user is redirected to the post-authentication URL with an established QlikView session. P a g e 2

3 function TryLogin(url, username, password) { username = username document.getelementbyid("userid").value; password = password document.getelementbyid("password").value; url = url "/QvAJAXZfc/Authenticate.aspx" var xmlhttp; if (window.xmlhttprequest) { xmlhttp = new XMLHttpRequest() else { xmlhttp = new ActiveXObject("MSXML2.XMLHTTP"); xmlhttp.onreadystatechange = function() { //this will be called when the xml request returns if (xmlhttp.readystate == 4) { var ok = (200 <= xmlhttp.status && xmlhttp.status < 300) xmlhttp.status == 1223; // status 204 -> 1223 in IE if (ok) { window.document.location = any desired post-authentication url; else { document.getelementbyid("header").innertext = "Login Failed"; //this can be any msg element Show(); ; xmlhttp.open("get", url, true, username, password); try { xmlhttp.send(); catch (e) { callback(null); function TryLogin(url, username, password) Parameters: url The URL of the authentication target web service. Username The local Windows Network username of the logging in user Password The local Windows Network password of the logging in user P a g e 3

4 Pre: Post: N/A If the XMLHTTP request constructed with the given information is successful, the user should be redirected to the post-authentication target properly authenticated. Results The previous solution was tested and verified to meet the following user requirements given the following parameters and assumptions on March 31 st Assumptions Both the website where the login screen (login.aspx/login.aspx.cs) and the post-authentication target are running on the same server. User has valid Windows credentials for the local Intranet where the applications are running. The QlikView authentication service (/QvAJAXZfc/Authenticate.aspx) is running and properly functioning Parameters Windows Credentials (test credentials provided were used for QA) (in code: Post-Authentication URL Target) Requirements A user can navigate to an independent login screen located at and provide their Windows Credentials which are valid on the local network. Once a user clicks Login they should be properly authenticated with the QlikView application and redirected to a post-authentication target URL without being prompted with a credential dialog. The additional step of clicking through the Access Point located at should be eliminated. Phase II Initialization The second phase of this project included developing the functionality to allow users to change their Windows Network password for use with the QlikView system. In addition, this phase addresses P a g e 4

5 the security hole that allows non-authenticated users to view QlikView PDF files if provided the static URL to the file. Solution Development Openpdf.htm In addition to the login functionality required, we also discovered that PDF documents themselves (reports available via QlikView) were not properly secured behind the user authentication protocol. To secure these documents we created an indirect file load procedure similar to the functionality of the existing opendoc.htm page. In this way, openpdf.htm verifies that a valid authentication token is present, then allows the user to access the PDF file such that the direct URL provided cannot be distributed and grant access to these files. Login.aspx.cs Using the native.net libraries of System.DirectoryServices and System.Security we created an event handler routine to handle the impersonation of an administrative user, and given the reset credentials provided via the windows password reset dialog set the user s password. Results All objectives were successfully obtained, the PDF files that are accessed from QlikView are served in a secure manner barring any unauthorized direct URL access and a modal dialog was added to provide interface support for changing a user Windows password. Appropriate validation messaging is displayed if an error with resetting the password occurs. Phase III Deployment Login Website All the files to be located in the root directory of the website created to house the login functionality on the development server should be moved to the destination server. The target server page currently for login is /QlikView/Login.aspx This server page satisfies all Phase I Features, and Phase II Feature: Windows Password Changing Evaluate existing code, QlikView API, and authentication protocols Eliminate redundant collection of user credentials between Login.aspx and a loaded QlikView document. Login screen redesign, html clean-up, and styling P a g e 5

6 Local Windows network password resetting dialog and event handler(s) The following system.dlls are required for proper build. They are standard Windows authentication and logon libraries that should be located at C:\WINDOWS\system32\advapi32.dll C:\WINDOWS\system32\kernel32.dll Depending on the version of Windows these files live different places. Their references can be updated in the code to reflect other locations (Logon.aspx.cs ln 76 & ln 80 respectively) or copied to the above locations. The administrative user that has the permissions to set a user s password used in the impersonation process (for the Windows password changing functionality) is specific to the individual network, to install on other systems update these credentials in the respective function in Login.aspx.cs The login process depends on the local Windows Network to validate any given user. Update the reference to the userpath variable in Login.aspx.cs (ln 28 and 38 respectively) to modify the windows server that the Directory Services use to instantiate the given user s DirectoryEntry. Secure PDF Viewer The file located at /openpdf.htm should be added to C:\ProgramFiles\QlikView\Server\QlikViewClients\QlikViewAjax and will serve the PDF files located in C:\Program Files\QlikView\Server\QlikViewClients\QlikViewAjax\PDFs\ The base URL pointer within QlikView should be updated to supply the proper URL query string along with the target URL such as This page satisfies Phase II Feature: Secure PDF Viewer Website Setup Once the new site is setup, under Properties->Directory Security->Authentication and access control, click 'Edit' Ensure that Anonymous Access is enabled, and Integrated Windows authentication is selected Modify the relevant Application Pool so that it is using Classic Managed Pipeline Mode. QlikView Setup P a g e 6

7 There is a virtual directory that exists on the development server (bf-dmz) which is either redirected to or referenced by the login process. The entity QvAjaxZfc should be recreated in IIS and pointed to the installed QlikView access similarly. The URL slug that is used by QlikView to properly point pdf anchor links to their respective files should be updated accordingly to reflect the addition of openpdf.htm P a g e 7