Browse Prior Art Database

Mechanism for safely caching user logon information Disclosure Number: IPCOM000030780D
Original Publication Date: 2004-Aug-26
Included in the Prior Art Database: 2004-Aug-26
Document File: 3 page(s) / 90K

Publishing Venue



The article presents a solution for speeding up inter - application communications by caching authorization and authentication data. Although the example in the article refers to the IBM's Health Network Solution (HNS) product, the idea can be applied to any application.

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

Page 1 of 3

Mechanism for safely caching user logon information

A main function of the health network system (HNS) for interactive users is to access or update medical data through a web-based front-end. The first step when users access the system is to logon. This authentication and authorization process is very slow compared to any other HNS request. However, being performed only once during a session, it does not have a high impact since users perform several tasks, issue a large number of requests during an HNS session.

Although this article makes reference to specific applications such as a request submission program (RSP) (submitting the requests) or HNS (servicing the requests and returning the results), the mechanism can be applied for speeding up the transactions between two connected systems accessed through a single user interface.

When HNS had to service requests from another application (e.g. RSP) instead of a human user, the latency of the logon process became an issue. Each request from the external system is encapsulated into a session, requiring a logon for authentication and authorization. For these single-request sessions, the duration of the logon process becomes very significant.

RSP users have to pass a first level of authentication and authorization on the RSP system. When these users request HNS data, a second level of authentication and authorization takes place in HNS. The requirement is to minimize the HNS transaction time.

From HNS point of view, several RSP users that have the same role (level of authorization), can be viewed as the same HNS user and use the same HNS userid and password. This is configured in the application accessing the HNS system.

So, the first characteristic of this new mechanism is the capability to group several users with the same role (level of authorization). The requester application (RSP) is then configured to submit its request to the application servicing the request (HNS) using the same userid for any user within a specific role. This provides a two tier authentication, at user level in the RSP application communicating directly with the user, and at the role level, when a logged-on RSP user submits an HNS request.

The idea for speeding up the HNS logon process is to cache logon information for RSP users after the first successful logon and re-use this info rather than perform again a full logon. So, after a full logon, requests from the RSP application will perform only quick logon every time. This provides a considerable improvement in the HNS response time, since the quick logon is about ten times faster than a full HNS logon (typically about 30 seconds).

Once a RSP user has been logged on HNS, the users' information is maintained in a hash table with one entry for each distinct userid/facility pair. The requestor application is configured to map several users (having the same role) to the same HNS userid. The first user to logon using a specified userid will perform full authenti...