User Session Tracking
You can configure WTA to track individual users and the page views for each user. To set up user tracking, you need to create a User Session Tracking definition for each web application of interest. Each definition specifies a set of related web pages and the key strings that the web client and web server use to track individual sessions.
This section discusses the following:
Important Notes
Note the following:
◼ WTA assumes that usernames and session IDs are embedded in the web traffic as key-value pairs separated by the ‘=’ character (for example, username=jsmith and sessionID=1131).
If a web application uses different conventions for transferring usernames and session ID strings, you must define the keys using regular expressions as described in
Defining Keys Using Regular Expressions. To use this method, you must have a working knowledge of regular expressions and the data formats used by the web application of interest.
◼ Do not use any of the following characters in a User Session Tracking definition, unless you are defining a regular expression as described in Defining Keys Using Regular Expressions:
. (period)
+ (plus sign)
* (asterisk)
? (question mark)
( ) (parentheses)
{ } (brackets)
[ ] (square brackets)
^ (caret)
$ (dollar sign)
\ (backslash)
*
◼ Collecting user data can be highly resource-intensive, especially on large networks with a lot of web traffic. Therefore, it is good practice to collect user data only for Page Families of interest.
Use the Session Tag for User Name if User Name Not Found
A User Session Tracking Definition contains a check box to enable using the session ID if a User ID is not found. When enabled, a hash of the retrieved session ID is used for the user name by default. To use the raw session ID for the user name the session Prefix must be specified as [raw].
To use a raw session ID as the user name, do the following:
1. Go to Administration > Web Transaction Analysis: User Session Tracking.
2. Click Add or hover over an existing User Session Tracking Definition’s description and click the pencil icon on the right to edit the definition.
3. Select Active for the definition Status.
4. Enter the User key and the Session Key.
5. Select Cookie under Search Locations for both User Key and Session Key.
6. Select Use session IDs as User IDs if User ID is not found.
7. Enter [raw] as the Prefix.
8. Enter Server Port(s).
9. Enter Server IP(s).
10. Click Save to make your changes or Revert to dismiss them. If Save is not active, check that there are valid entries for each field.
Discover User Tracking Information from a Packet Trace File
1. Capture a login of the web application in a packet trace file:
◼ If the application login exchanges passwords or other sensitive information, verify that is configured to mask out this information.
For more information, see XREF.
◼ If the application login is SSL-encrypted, set up SSL Decoding_XREF.
For more information, see Enable SSL Decoding.
◼ Using tcpdump or Transaction Analyzer, capture the login sequence as follows:
Go to the login page for the web application.
Start the capture.
Enter the username/password and log in.
Wait until the "login-succeeded" page downloads completely.
If the web application uses separate servers for logins and for content, download a few more pages so that you can capture data for the different servers used by the application.
Stop the capture.
2. Open the resulting packet trace file in the Transaction Analyzer Transaction Analyzer or Wireshark.
3. You can find the correct information for the definition by analyzing the decoded HTTP trace data in Wireshark or Transaction Analyzer. The following sections describe how to determine the correct settings for
Login Page Ports and IP addresses
Examine the POST message for the client login.
◼ The port number is in the TCP header > destination port.
◼ The IP address is in the IP header > destination IP.
If the web application uses multiple login servers, you might need to specify multiple server IPs.
Examine the POST message for the client login. Look for the string in the URL path that is unique to the login-submitted page—that is, the page that indicates to the user that the login was successful. A useful technique is to compare the “pre-login” and “post-login” URLs to determine the string that is unique to the latter. For example, suppose a web application uses the following pre- and post-login URLs:
https://myapp.acme.com/index.php?title=Special:UserLogin
https://myapp.acme.com/index.php?title=Special:UserLogin&action=Submitlogin
In this case, SubmitLogin is the string that marks a page as coming from the login server. In this case, you would specify the URL pattern as
myapp.acme.com/*SubmitLogin*
If the web application uses the same server (or set of servers) for logins and other types of transactions, you can use the same URLs and servers for Associated Pages as you did for Login Pages.
If the application uses separate login servers, you will need to use the same workflow that you used for the login pages:
◼ Capture one or more associated page views using tcpdump or Transaction Analyzer.
◼ Examine the POST message(s) for the TCP port and IP address for the web server.
◼ Examine the POST message(s) to the URL host and path.
When you specify the host and path, your goal is to enter a regular expression that matches all page views of interest for the web application of interest (and no other web applications that you are tracking in AppResponse 11). The following are some example URL patterns:
◼ inet.acme.com*/*calendar* (“Any page view whose URL includes the host string inet.acme.com and a path with the parameter string calendar”)
◼ calendar.acme.com* (“Any page view whose URL includes the host string calendar.acme.com”)
◼ www.webstore.com*/shopchart/* (“Any page view whose URL includes the host string www.webstore.com and a parameter string that starts with /shopcart/”)
Define User Session Tracking for a Web Application
A User Session Tracking definition specifies a set of related web pages and the key strings that the web client and web server use to track individual sessions. Each definition corresponds to one web application. AppResponse 11 requires this definition to track individual users and the page views for each user.
User Session Tracking Definition Settings
Setting | Notes |
Name | Identifies the web application and associated pages. |
Description | |
Status | To enable user tracking, select Active. To disable, select Inactive. |
User Key | The key name used to track the username (for example, user in key=value pair user=jsmith) and the HTTP/HTTPS locations to search. This field is required for WTA to identify usernames in web traffic. |
Session Key | The session ID used to track the session ID (for example, sessionID in key=value pair sessionID=12345). This field is required for WTA to identify session IDs in web traffic. |
Use session IDs as User IDs if User ID is not found. Prefix: | This option is useful to track users when the appliance did not observe the initial login sequence for a session. This can occur because n A web application uses an authentication server whose traffic is not monitored by the appliance. n The login occurred before WTA was enabled. When this option is enabled, WTA creates User names with the label [prefix]+[session_tag]. The session tag is a unique, auto-generated tag (not the session ID). Note—If the prefix includes a non-alphanumeric character, enclose the argument string in single quotes (example: 'FinTrx$Session'). |
Login Page | The login pages where users enter usernames. n Ports—Port number(s) used by these login pages n IP addresses—The IP address(es) for all hosts that serve these login pages n URL Patterns—A set of strings or regular expressions to identify the login pages. Specify the following: n 1+ strings/patterns for the hostname/domain (examples: www.acme.com and *.google.com). Do not include a port number in this field, even if the web application normally includes one in its URL—for example, enter only www.mywebapp.com and not www.mywebapp.com:8010. n 1+ strings patterns for the login page (examples: */identification.aspx and *AUTH_Login*) |
Associated Pages | Web pages that use Session IDs based on the key specified under the Parameters Tab. To identify users that downloaded these pages, WTA parses the traffic for session IDs and matches an individual session to a username. n Ports—Port number(s) used by associated pages n IP addresses—The IP address(es) for all hosts that serve these associated pages n URL Patterns—A set of strings or regular expressions to identify associated pages. Specify the following: n 1+ strings/patterns for the hostname/domain (examples: www.acme.com and *.google.com). Do not include a port number in this field, even if the web application includes one in its URL—for example, enter www.mywebapp.com and not www.mywebapp.com:8010. n 1+ strings patterns for the login page (examples: */identification.aspx and *AUTH_Login*) |
