Clearing Novell Access Manager Application Sessions


By: Jason D. Rivard

How to log out users out of applications protected by Novell Access Manager (NAM) so that multiple users using a single browser do not gain access to each others sessions.


Background Information
Solution Implementation
     Placing a "clearSessions.html" file on the web server
     Adding a public protected resource to Access Manager configuration
     Modifying the "logoutSuccess.jsp" of the access gateway

Background Information

Novell Access Manager (NAM) uses a reverse HTTP proxy server to protect web servers. Access to a web servers is typically permitted only through NAM once the user has authenticated to NAM. After authenticating to NAM, NAM will allow access to the origin web server, and will typically provide single-sign-on to the origin web server.

During this activity, a series of HTTP session cookies will be issued (see Most importantly, the NAM proxy will issue one or more HTTP session cookies, and the web server will issue one or more HTTP session cookies.

When the user logs out of NAM (via the /AGLogout link), the NAM session cookies will be invalidated on the NAM servers, however the application session cookie will be left unchanged on both the browser and the origin web server.

This means that if the user immediately authenticates to NAM again and then accesses the web server, they will resume their previously established HTTP session with the web server. Generally this is desired behavior, as it preserves the state of the users previous session with the web server.

The potential problem comes when two users are involved with this scenario. If "User-A" authenticates to NAM, accesses the application, and then logs out of NAM, the browser will be left with a valid HTTP session cookie for User-A in the browser. If "User-B" immediately authenticates to NAM using the same browser, and then accesses the web application, User-B will resume User-A's HTTP session. To prevent this behavior, the HTTP session cookie of User-A's must be invalidated on either the browser or server.

To be clear, this problem only occurs when two users are using the same browser on the same workstation. When using different workstations or if the browser is closed, there is no issue.

Solution Implementation

In this solution, we will be using custom JavaScript pages to invalidate the browser's HTTP session cookie from the web server.

Because browsers have protections that limit manipulation of session cookies to JavaScripts loaded from the same site the cookies are for, the JavaScript must actually be stored on the origin web servers. The JavaScripts will be made as public resources (accessible without a NAM session) and will be loaded and executed when the NAM logout page is shown. With this approach, the browser's HTTP session cookies for the web server will be invalidated whenever a NAM logout occurs.

The solution consists of the following components:

  1. Placing a "clearSessions.html" file on the web server
  • Adding a public protected resource to Access Manager configuration
  • Modifying the "logoutSuccess.jsp" of the access gateway

Placing a "clearSessions.html" file on the web server

The clearSessions.html will be placed on the web server. Exactly where the file is placed depends on the type of web server and web application is in use. You will need to work with the web server owner to find the best place to locate the file on the web server.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" xml:lang="en" lang="en">
<head><title>Clear Sessions</title></head>
<body onload="doCookie();">
Clearing sessions...
<script type="text/javascript">
function doCookie() {
var cookieName = "JSESSIONID"; // set this to the session cookie name
var cookiePath = "/IDM"; // set this to the path of the session cookie
var now = new Date(); // creates a new date object
now.setTime(now.getTime() -1); // sets the date to the past
document.cookie = cookieName "=x; expires=" now "; path=" cookiePath;

The clearSessions.html will need to be modified to have the correct cookie name and path for your web application. You can see the HTTP session cookies issued by the web server using a browser plugin. One such popular plugin is the WebDeveloper plugin for Firefox ( Using the WebDeveloper plugin, login to the web server and select Cookies -> View Cookie Information.

By default, most Java web application servers use a cookie name of "JSESSIONID" and the path of the first part of the URL after the domain name. (Example for "" the path would be "/webapp").

You can test the placement and configuration of the page directly by accessing the web server without going through NAM. Login to the web server as normal, and then paste the URL for the clearSessions.html page into your browsers location bar. If this works, the next access to the web server will require you to re-authenticate.

Adding a public protected resource to Access Manager configuration

The next step is to configure NAM to allow users to access the clearSessions.html file while not authenticated to NAM. This is required because by the time the clearSessions.html file is called by the browser, the user will no longer be authenticated to NAM.

To apply this configuration, open the NAM Reverse Proxy configuration for your web server. In the screenshot below, this is being done for the "PMF" application. Create a new protected resource with a single path that directly lists the relative location of the clearSessions.html file on the web server. Do not use wildcards in the path, otherwise unauthenticated users may be able to access sensitive information on the webserver.

Leave the Contract, Authorization, Identity Injection and Form Fill configurations for the protected resource blank. After the changes are applied and updated, verify that an unauthenticated user can access the public url of the clearSessions.html file directly without being prompted for a NAM authentication.

Modifying the "logoutSuccess.jsp" of the access gateway

The last step is to make the clearSessions.html file be called by the browser when the user logs out of NAM. To do this, the logoutSuccess.jsp file on each access gateway server in the NAM cluster must be modified. Often this file is already modified to provide a custom look to the logout screen.
This file should be edited to provided an <iframe> tag inside the body. During the initial modify, make the height/width tags so that the clearSession.html page can be seen inside the logout. When functionality is verified, it is common to set the height/width taxes to only a single pixel so it is not noticed by the user.

editing logoutSuccess.jsp

<iframe src="" height="1" width="1">Unable to clear sessions</iframe>


After following these configuration steps, the use case where User-A authenticates to a NAM protected web server and then logs out, and User-B is able to authenticate to NAM and continue User-A's web server session should be resolved.

This approach requires that the origin web servers be modified in some way, which can be a challenge in many customer environments. One other approach would be to embed the contents of the clearSessions.html into a rewriter policy that would modify an unused static html resource on an origin web server to handle the session clearing. However that approach would present a more challenging NAM configuration task.

The solution documented here suffers from several problems:

  • An iframe "box" (even though tiny) will appear as an artifact on the logout screen.
  • Browsers that do not support iframes/JavaScript will not invoke the session clearing JavaScript
  • Security models in browsers may prevent clearing a cookie from certain URLs
  • The user must allow the logout page to load completely and each clearSessions.html resource to load; if the user switches pages to fast, the sessions may not be cleared.

These problems aside, this solution is still desirable for environments where multiple users may use the same web resources on a common browser.


How To-Best Practice
Comment List
  • The ability to "munge" protected application cookies is now a built-in feature of the Access Gateway Service - but not the LAG. See the LAG / AGS feature comparison table in the docs:
    Install Guide | Installation Requirements | Access Gateway Requirements | 3.6.5 Access Gateway Feature Comparison | Table 3.1 | "Manipulates cookies so that when a browser retains application cookies from the Web servers after a user logs out, these cookies become invalid."

    Also at this link directly to the table: