Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A method to close previous iFrame session under SSO environment

IP.com Disclosure Number: IPCOM000028609D
Original Publication Date: 2004-May-24
Included in the Prior Art Database: 2004-May-24
Document File: 4 page(s) / 18K

Publishing Venue



A method to close previous iFrame session under SSO environment

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 4

A method to close previous iFrame session under SSO environment

A program is disclosed to secure an iFrame application from exposing personal information under an SSO environment.

A typical web application places the pages containing a users private information under a secured directory. The user has to pass through authentication (login) to get to the secured pages. This mechanism works when the user explicitly logs in to the application.

However, if the application runs in an iFrame and the main window application and the iFrame application are set up under Single-Sign-On through an LTPA token, the iFrame application will be implicitly authenticated when the user logs into the main application via an LTPA token.

When the user logs out of the main window, although the main window's user session is closed, the application in the iFrame's session is still open. When another user logs in the main window, although a new LTPA token is created in the iFrame application with the new user's credentials, but since the iFrame window's session is still open, no login is needed. This results in the main window running a new user session while the iFrame runs the previous users session. This causes a security hole for LTPA Single-Sign-On. This happens in both IE and Mozilla.

The core idea of this invention is creating an initialize page under a secured directory in the iFrame application. The iFrame URL points to the initialize page instead of the typical welcome page or a page that includes personal information. An illustration of the mechanism; a personal inbox page. In the initialize page, save the user's LTPA token in the session, check if the current LTPA token is the same as the one saved previously. If not, a new user has logged in. Next, invalidate the session and forward to the inbox page. Since the inbox page is under a secured directory and needs to have a valid user session, it forces the application to re-log in as the new user by invalidating the user session before the inbox page.

Here is a detailed description on how this innovation works:

The main browser window runs application A on server 1. The iFrame runs application B on server 2. Server 1 and server 2 are set up with Single-Sign-On through LTPA. In application B, all pages for the application are placed under a secured directory. This means that the user has to login to go to these secured pages.

The innovation is to create an initialize page to invalidate the session by comparing the current users LTPA token and the previous users token.


Page 2 of 4

The flow:
1. UserA logs into portal. An iFrame application is called for the first time. There is no user session
2. Since there is no user session, the application goes to login page.
3. Because SSO is setup, the application logs in through the current LTPA token (userA ) the application creates a new session for userA
4. Since UserA's session is new, there is no previous user token in the session. Initialize.jsp saves t...