Authentication Overview Authentication Using Forms Basic Authentication Windows NT Authentication Overview There are several ways to authenticate users on a web site. The most common method is to present the user with a form containing a username and password. When the user submits the username and password, these are passed to the back-end via an HTTP post, and the user is either presented with an error message, or accepted into the site. If the site is a sensitive one, the web page containing the login form can be encrypted using SSL, i.e. making the reference to the page contain "https", so that the resulting FORM POST containing the username and password will be encrypted. On almost all application servers and back end code, however, the method of authentication is separate from that of session tracking, which is the method of telling one user from another. This separation is maintained so that a user's path through a site can be tracked before they are authenticated. Web Performance TrainerTM supports only cookie-based session tracking, which is the default for modern application servers. From a programming perspective, using the built-in session tracking mechanisms in JSP, servlets, ASP, or other propietary systems is the easiest. The following links show references to a couple of differencent automatic session tracking mechanisms: Servlet/JSP ASP PHP Apache Web Performance TrainerTM supports cookie-based session tracking through its virtual browers. Each virtual browser behaves like a real browser, replacing the cookies in HTTP requests with the unique cookie assigned for each virtual user during a playback test. From the web server's perspective there is no difference between live people using browsers, and the virtual browsers. If your web-based application does not use cookies for session tracking, instead using a proprietary system or URL rewriting, then the session simulation features of Web Performance TrainerTM will not work. It may be possible to reconfigure your web server to use cookie-based session tracking for the performance test, and then switch back before rollowing out the live site. Authentication using Forms The most common technique for authentication is to present the user with an HTTP form asking for a username and password. When the user submits the form, a back-end process is queried to authenticate that username/password combination. This process is captured by Web Performance TrainerTM so that you can control the replacement of the original username and password, and have each virtual user login using a different username. This process is enabled using form data replacement features which you may want to review before proceeding. The first step is to create a series of login names that will be used by the virtual users. This is unique to your how you keep track of usernames in your application; however, you should create at least as many usernames as the number of virtual users you wish to simulate. For ease of testing, it is most convenient to simply make the passwords for all of the test users the same. Once the passwords are created, you need to create a text file containing each username, one name to a line. This file can then be imported into Web Performance TrainerTM so it can be used to replace the original recorded password at playback time. The following image shows the file usernames.txt being imported into the series name "usernames", which will be used later. The next step is to examine the recorded business case and find the HTTP POST where the authentication form was submitted, because this is where the username and password were transferred from the browser to the web server. The following screenshot shows an example recording that resulted from logging into the New York Times web site. Click on the image to view a full-sized image so you can see the details: The URL containing the username and password is http://www.nytimes/auth/chk_login. Notice that the HTTP Request header shows that this is a POST, which indicates this event was sending data back to the web site. The name of the URL is very descriptive, and confirms that this is the username/password page. Also notice that the HTTP Reply has a "SET-COOKIE" directive for the cookie named "NYT". This cookie is the cookie used to track sessions, and every subsequent request contains that cookie. To configure the replacement of the username at runtime, double click on the URL, and select the header field named "Content-Type". The following image shows the names and values of the parameters being sent to the web site. Notice that there are parameters named "USERID" and "PASSWORD": To configure the login to automatically have each virtual user log in with a different username, double click on the row containing "USERID", and configure the parameter replacement to use the imported usernames. Note that Global Sequential Access is checked to make sure that each virtual user gets a unique login name value. Basic Authentication Basic authentication is described by RFC2617, and was part of the original Mosaic browser. When a user tries to access a web page controlled by basic authentication, a dialog is presented where the user types in a username and password. The username and password are then sent along from the browser to the web server in each HTTP request, which is captured by Web Performance TrainerTM. If you want to have each virtual user that is authenticated using Basic Authentication to have a different login name, you have to examine the HTTP requests that contain the username and password, and configure that HTTP Header field Authorization for Data Replacement. The following image shows a recording of an HTTP Request from a business case that used basic authentication: Note the header field "Authorization" that contains the username/password pair. The format of the username and password for basic authentication is "username:password" which means this is the format to use when importing the usernames and passwords into Web Performance TrainerTM. You need to create a text file containing: username1:password1 username2:password2 username3:password3 and import the file into a data series. The next step is to configure that header field for data replacement, as shown in the image below: Note that the usernames and passwords shown are just examples; you have to actually create those usernames and passwords on your web server. This procedure is different on each type of web server, and you need to consult your web server documentation for details. There is a tutorial available for Apache, and MSDN Page available for IIS. Microsoft NT Authentication This type of authentication is available when using the Internet Explorer browser from a Windows computer to connect to the IIS web server. When a user tries to access a protected web page for the first time, they are presented with a dialog, and asked to give a username and password for a Windows account on the web server. Because this protocol is proprietary, we are unable to support this type of authentication.

Search