Browse Prior Art Database

Global authentication mechanism for Single Sign On (SSO) Disclosure Number: IPCOM000029553D
Original Publication Date: 2004-Jul-06
Included in the Prior Art Database: 2004-Jul-06
Document File: 4 page(s) / 36K

Publishing Venue



The problem: Different applications need solutions to authenticate their users. The solution: Enhance the LTPA solution using the WebSphere servlet and LTPA mechanism.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 1 of 4

Global authentication mechanism for Single Sign On (SSO)

Currently, only Java*2 Enterprise Edition (J2EE) applications that run within WebSphere** use LTPA tokens indirectly. This solution gives applications that are not J2EE or are not running under WebSphere the option of using LTPA tokens. Previously, if applications wanted to use the LTPA token mechanism, they had to generate their own tokens using their algorithm, while making sure that they were compliant with the WebSphere token generation algorithm (if they wanted to use SSO with WebSphere). If WebSphere changed the token generation algorithm, those application had to do the same, to change as well or become worthless. (For example: Domino*** and WebSphere 4 versus Domino and WebSphere 5.0.2, which changed the algorithm. If they had been using this solution, it would have avoided some problems.)

    This solution provides a way for applications to authenticate their users. It allows the use of existing, secured, and proven methods of authentication, such as those that were already approved by the enterprise or business using the application. It provides an easy way to use those technologies.

  The solution is composed of client and servlet. The client has two operations: Get the user name and password and encapsulate it as an HTTP request to the

secured servlet. The servlet authenticates the user by the password and generates an LTPA token using the WebSphere mechanism for that user. Get the user name and a given LTPA token and encapsulate it as an HTTP

request to the secured servlet. The servlet uses the WebSphere LTPA mechanism to get an LTPA token for a user and to validate that the given token is legal. If the token is legal, then the servlet verifies that the given user is the creator of the token.

Instead of creating specific authentication solution, each application can use this solution as its authentication mechanism by using the client.

Client A simple API that contains 2 methods:

Create Token, with the following parameters: user name, password. Return the token, created by WAS. Validate token, with the following parameters: user name, token. Return value true/false.

Servlet The servlet needs to be secured (i.e. in the servlet deployment descriptor, indicate that the servlet can only be called by authenticated users). The servlet need to verify that the given user name, is the one that created the token

Simple scenarios:
1. Client calls the create token API method. The API sends HTTP request to the servlet, with basic authentication fields in the request's header (i.e. the Authorization field). When WebSphere receives this request, it first checks whether the authentication is required (the servlet is secured). WebSphere tries to authenticate the user against the directory provided by the enterprise. If it succeeds, it creates an LTPA token for that user, inserting it to the request as a cookie. The servlet returns this cookie to the client.



Page 2 of 4

2. Client...