Linux-UNIX: Application server S-TAP configuration

Application Server S-TAP is a very easy way to identify application users for Java Application Server applications when built-in functionality is not available. It doesn't require any changes to existing applications which makes it a very attractive solution. Nevertheless some considerations need to be taken into account.

For Application Server S-TAP to work, the username needs to be transmitted in clear text in the HTTP stream. Some authentication mechanisms, for example, regular HTTP based authentication are hashed or Base64 encoded and are not supported. In general Form Logins transmit the username in clear text.

This method does not work with all applications. It depends on the way that connection pooling is used. For example, it requires that the access to the database is synchronous with the same process or thread that is handling the HTTP request. A good example is a servlet-based application where a servlet processes HTTP requests, and in the process receives a connection from a connection pool to access the database.

HTTPS connections are also not supported. This is normally not a crucial problem because the S-TAP is installed on the application server. In normal enterprise configurations, only traffic to the web server is HTTPS encrypted and the connection between web and application server is standard HTTP.

There are situations when it is not possible or desirable to change the application source code, so the Guardium Application Event API cannot be used. The application may also not use stored procedures to define user boundaries. In some of these cases the ability of the Guardium S-TAP to monitor network traffic can be used to identify application users. In this scenario the S-TAP is used to correlate application end users with database activity. An S-TAP is installed on the machine that hosts the application server; and is not installed on the machine that hosts the database server. It is then configured to monitor incoming HTTP traffic to the application server, filter out user names and correlate them through an application server session id with database activity. In Guardium this is called Application Server User Identification or Application Server S-TAP.

This approach is advantageous because it works without changing the application or reconfiguring the application server. It is therefore a very fast and easy solution. The disadvantages are that it also does not work with all enterprise applications. Possible problems include incompatible authentication mechanisms that encrypt or hash user names. Application Server S-TAP works best for standard Java Enterprise Applications using a type of Form Login authentication.

  1. Analyze the application's web traffic to determine:
    • The HTTP port of the application server.
    • The application user name in the HTTP traffic during login.
    • The Java Session ID that is correlated to the user name.
    There are various tools you can use for this analysis. It is beyond the scope of the Guardium Knowledge Center.
  2. Configure and save the Application server S-TAP. Typical parameter values specific for the application server settings:
    • App. Server User Identification: 1
    • App server user ID: 1
    • Session timeout:1800
    • Ports: 8081
    • Login pattern: userid
    • Username prefix: userid=
    • Username postfix: &
    • Session pattern: action=login
    • Session prefix: JSESSIONID=
    • Session postfix: ;
    • Session ID pattern: Cookie
    • Session ID prefix: USESESSIONID=
    • Session ID postfix: ;

Guardium stores the application username in the field Application User, in the entity Access Period. You can add this field to reports.