Abstract:
User access to applications is controlled by associating an alias for an individual with a user profile for the individual; the user profile typically contains data referring to one or more applications. Access to an application is obtained using the data in the user profile, e.g., through automatic completion of forms or screens within an application. In addition, the user profile may be employed to limit user access to parts of an application, or to terminate a user&#39;s access to an application.

Description:
FIELD OF INVENTION  
         [0001]    The invention relates generally to controlling access to a computer system. More specifically, in one embodiment, the invention relates to systems and methods for using user profiles to authenticate the identify of a user of a computer system.  
         BACKGROUND  
         [0002]    The number of computer applications used by large corporations has increased significantly over the past twenty years. For example, companies may employ separate applications for electronic mail, document control, financial applications, inventory management, manufacturing control and engineering functions, in addition to overall network access. Each application often requires a separate login procedure, including some form of personal identification such as a user ID, a password, a key sequence or biometric authentication. The increase in the number of applications requiring user authentication requires significant effort on part of the users of the applications to create, secure, and remember their authentication data. Furthermore, from a management perspective, the proliferation of computer applications with varying security and sign-on procedures adds significant cost to the ongoing maintenance of a secure information technology infrastructure.  
           [0003]    The user faces similar login requirements when accessing server-based applications over the Web. For example, the user may face different login procedures (typically involving different passwords) to access bank accounts, brokerage accounts, subscription content sites, etc.  
           [0004]    Indeed, the mere need for computer users to keep track of multiple logon names, passwords and PINs in order to access different information further increases the chances of unauthorized use and loss of private information. Users may resort to using the same logon name and password combinations for all accounts, rendering them equally vulnerable if unauthorized access to a single account is obtained. On the other hand, security-conscious users who maintain different logon names and passwords for individual accounts may, to avoid confusion, write them down where they may be found or store them on easily stolen devices such as personal digital assistants—thereby undermining their own efforts. Often those who routinely change their passwords but record them on paper or in a computer file are at greater risk of being compromised than those who use a single but difficult-to-crack password. At the very least, such security-conscious individuals risk forgetting their access information, necessitating time-consuming calls to customer-support lines. In some known systems, different applications may attempt to synchronize their login procedures and user credentials, but this is often limited to applications from particular suppliers and cannot be extended across varying technology platforms.  
           [0005]    What is needed, therefore, is a method and system for facilitating the central management of user authentication, access, and usage that can easily accommodate the introduction of new computer applications into a large computing environment.  
         SUMMARY OF THE INVENTION  
         [0006]    The present invention automates the login process by storing login indicia (such as passwords, biometric authentication information, and the like) and recognizing the login screens of server and/or web-based applications. In response to a user&#39;s selection of an application and consequent receipt of a login or other form-based screen, the invention fills in the information called for by the screen and causes its transmission back to the server. In this way, the user is not burdened by the login process, and need not maintain awareness of the different requirements of each login screen she may encounter. The functionality of implementing the login resides on the user&#39;s client computer. The user&#39;s profile—i.e., the authentication information as well as the characteristics of the login screens for which the user is registered—is stored on a single-sign-on server and subsequently provided to the client computer only after the user authenticates herself thereto.  
           [0007]    Accordingly, in a first aspect, the invention comprises a method for controlling user access to computer applications. The method comprises storing user profile information on a server, and authenticating a user&#39;s identity to the server from a client machine. The server sends the stored user profile information to the client machine, and the client machine transmits data sent as part of the user profile to one or more applications, thereby granting the user access to the applications.  
           [0008]    The user profile can include one or more passwords, user identification codes, or secure access codes for granting a user&#39;s access to one or more applications. The user profile can also include a set of user privileges that define a user&#39;s functional capabilities within a set of applications. Additionally, the user profile information can include biometric data. The biometric data can be captured at the client machine, sent to a server machine, and compared to a reference set of biometric data to confirm the identity of a user.  
           [0009]    In one embodiment, the invention recognizes application screens as they are presented to a user, and in response to the screens, enters data into one or more fields that make up the screen, and sends the data to the application. Moreover, the invention can facilitate the revocation of a user&#39;s access to one or more applications, or require a user to reauthenticate their identity. The revocation or reauthentication can, for example, be initiated by one or more trigger events. The trigger events can be stored in the user profile,and can include a broken communications connection, the expiration of a password, a changed password, the passage of time, or a sequence of events at the client or in the application, or both. The user profile can remain on the client machine after the termination of a user session, or alternatively, can be erased upon termination of a user session.  
           [0010]    In a second aspect, the invention comprises a system for controlling user access to one or more applications. The system has a server for storing user profile information relating to one or more applications. The system also includes a web server for transmitting the user profile to a client computer, and a client-resident agent for facilitating the receipt of the user profile information from the server.  
           [0011]    In one embodiment, the user profile stored on the server can include one or more of a password, a user identification code, and a secure access code. The user profile can include a set of user privileges defining a user&#39;s access and functionality rights within one or more applications. In one embodiment, the system includes a biometric device attached to the client computer for capturing biometric data from a user, a communications module for transmitting the biometric data, and a server for receiving the biometric data and comparing it to a set of reference biometric to determine the identification of the user. The client-resident agent may be configured to recognize application-specific screens, to use information stored in the user profile to complete data entry fields on the screens,and to transmit the data to the application server for processing.  
           [0012]    Other aspects and advantages of the invention will become apparent from the following drawings, detailed description, and claims, all of which illustrate the principles of the invention, by way of example only. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]    The above and further advantages of the invention may be better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:  
         [0014]    [0014]FIG. 1 is a block diagram of a system to authenticate a user and automate login to one or more applications using a client-resident user profile and a single-sign-on server in accordance with the invention;  
         [0015]    [0015]FIG. 2 is a flow diagram of a process to authenticate a user to one or more applications using a client-resident profile and a single-sign-on server in accordance with the invention;  
         [0016]    [0016]FIG. 3 is a flow diagram of a process to disable a user from one or more applications and define events that require a user to re-authenticate themselves using a client-resident profile and a single-sign-on server in accordance with the invention; and  
         [0017]    [0017]FIG. 4 is a flow diagram of a process to audit user activities within one or more applications using a client-resident profile and a single-sign-on server in accordance with the invention. 
     
    
     DETAILED DESCRIPTION  
       [0018]    In broad overview, FIG. 1 illustrates an embodiment of a system  100  to automate the login process to and to audit the user&#39;s activity within one or more applications in accordance with the invention. The system  100  includes a first computing system (a “client”)  104 , a second computing system (an “application server”)  106  and a third computing system (a “single-sign-on server”)  108 , all in communication with a network  110 . The client node  104  is used by one or more users, indicated graphically at  102 . The client node  104 , the application server  106  and the single-sign-on server  108  are in communication with the network  110  using communication channels  112 .  
         [0019]    For example, the communication channels  112  can connect the client  104  to a local-area network (LAN), such as a company Intranet, a wide area network (WAN) such as the Internet, or the like. The client  104  and servers  106 ,  108  communicate with the network  110  through the communication channels  112  using any of a variety of connections including, for example, standard telephone lines, LAN or WAN links (e.g., T1, T3, 56 kb, X.25), broadband connections (ISDN, Frame Relay, ATM), wireless connections, and the like. The connections can be established using a variety of communication protocols (e.g., HTTP(S), TCP/IP, SSL, IPX, SPX, NetBIOS, Ethernet, RS232, direct asynchronous connections, a proprietary protocol, and the like). In one embodiment, the client  104  and the servers  106 ,  108  encrypt all communication when communicating with each other.  
         [0020]    Each of the servers  106 ,  108  can be any computing device capable of providing the services requested by the client  104 . Particularly, this includes logging into secure applications, tracking user activities within applications, and terminating a user&#39;s access to applications as described in more detail below.  
         [0021]    The application server  106  includes one or more server-resident application modules  114  and one or more application database modules  116 . The application server  106  may also include an application web server module  118  to facilitate communication with the client  104  over the network  110  where the communication network  110  is the Internet, an intranet, or the like. The single-sign-on server  108  includes a single-sign-on application server module  120 , a single-sign-on web server module  122 , and a single-sign-on database module  124 . The modules throughout the specification can be implemented in whole or in part as a software program and/or a hardware device (e.g., ASIC, FPGA, processor, memory, storage and the like).  
         [0022]    For purposes of illustration, FIG. 1 depicts an application server  106  as an entity separate and distinct from the single-sign-on server  108  and each server in independent communication with the network  110 . It is to be understood, however, that the servers  106 ,  108  can also be implemented, for example, on a single server (e.g., as logically distinct modules), distributed on portions of several (i.e., more than two) servers, and/or as part of a single server node or server farm in communication with the network  110  through, for example, a single web server (not shown). It should further be understood that even if two logical servers are running in the same physical machine, they may be secured logically if any of the following conditions are met: (1) the servers run in different process spaces (so there is no possibility for one process to access the memory of another process); (2) the servers access different logical databases (which may be further partitioned) with different credential or entry requirements; (3) sensitive data in the application server  106  and the single-sign-on server  108  are encrypted using separate encryption keys; or (4) the server applications are launched (e.g., in a Unix environment) under two different logon accounts. For heightened security, it is possible to encrypt all the data used by the single-sign-on server  108  using a key maintained by the application server  106  or an external key server. This approach enhances security because a breach of the of the single-sign-on server  108  and its database  124  would yield only encrypted data.  
         [0023]    The client  104  can be any computing device (e.g., a personal computer, set top box, wireless mobile phone, handheld device, personal digital assistant, kiosk, etc) used to provide a user interface to access the application server  106 . The client  104  includes one or more input/output devices  126  such as a keyboard, a mouse, a screen, a touch-pad, a biometric input device, and the like. The client  104  also includes an operating system  128 . Operating systems supported by the client  104  can include any member of the WINDOWS family of operating systems from Microsoft Corporation. The client  104  may also include one or more client-resident applications  130 , such as INTERNET EXPLORER developed by Microsoft Corporation, NETSCAPE NAVIGATOR developed by AOL Time Warner, or ATTACHMATE developed by Attachmate Corporation.  
         [0024]    To use the system  100 , a user  102  registers that user&#39;s authentication data for one or more applications with the application server  106 . The authentication data can include, for example, a password, a user identification number, or biometric data associated with the individual&#39;s fingerprint(s), facial characteristics, voice, and the like. The system  100  stores authentication data identifying the user to the system (e.g., username, logon ID, employee ID, and the like) in the application database module  116 . The application database module  116  may also associate an alias with that stored data. For example, employee #2054 may be associated with the alias 719j LL01. As the user logs into an application  114  (residing on the application server  106 ) via the network  110 , a single-sign-on agent  132  residing on the client  104  captures the authentication data entered by the user  102  using one or more input devices  126  and transmits (or causes the transmission of) the authentication data to the single-sign-on web server module  122  residing on the single-sign-on server  108 . The single-sign-on agent  132  captures the data by, for example, monitoring a messaging queue for instructions sent to and from the operating system, intercepting HTTP requests sent to and from the network  110 , capturing screen images sent to the output device(s)  126 , as well as other methods. The single-sign-on web server module  122  provides the authentication data to the application server module  120 , which in turn stores the data in the database module  124 . The single-sign-on application server module  120  then retrieves the updated authentication data and sends it to the client  104  using the web server module  122  and the single-sign-on agent  132 . The authentication data is stored on the client  104  in the user profile  134  for future use by the single-sign-on agent  132  residing on the client  104 . Thereafter, as the user logs into an application in the usual fashion, the single-sign-on agent  132  operates in the background, gathering and transmitting to the single-sign-on-server  108  all the information necessary to automate subsequent logins.  
         [0025]    Alternatively, or in addition, the single-sign-on agent  132  may reside on a server. This embodiment is particularly useful in a “thin-client” environment, such as CITRIX METAFRAME. In this embodiment, a user  102  connects to a server where the single-sign-on agent  132  resides. This server, in turn, communicates with the application server  106  and identification server  108 . The displayed output (such as HTML or screen dumps, for example) is obtained indirectly from the application server  106 , by way of the server on which the single-sign-on agent  132  resides; that is, this additional server runs the single-sign-on agent  132  and passes back the display information (as pixel values, markup code, or any other suitable display modality) to the client  104 .  
         [0026]    The user profile  134  can contain various data furthering the function of the invention, such as: a user identification code; an authentication modality (such as password, biometric data, or the like); an application profile (such as a user&#39;s rights and privileges within an application); an application credential for access (such as a user&#39;s password, a digital representation of biometric data, or the like); and audit records of a user&#39;s activities within an application. The single-sign-on agent  132  can then use the data stored in the user profile  134  to determine which HTTP requests to intercept, to complete login screens with stored authentication data, and the like.  
         [0027]    In the illustrated embodiment, there are security measures that the system  100  can use to ensure that a listening device does not capture this authentication data, or if the data is captured, that it is not usable by itself. For example, the single-sign-on agent  132  can encrypt the alias and the biometric data independently; the single-sign-on agent  132  and the single-sign-on database  124  can communicate with each other using SSL and/or public and private keys; and/or the single-sign-on agent  132  can transmit the alias and the authentication data independently to the single-sign-on database  124 .  
         [0028]    The registration process can be initiated in several different ways. The responsible technology administrator may initiate the registration. For example, the administrator can have the user come to the administrator&#39;s client  104  or a secure client  104  used only for registration when the employee starts work, when a customer purchases services accessible via the application server  106 , and the like. Alternatively, the application server  106  can initiate registration when the user first requests a service from the application server  106  requiring user authentication. The client  104  can display a graphical user interface (“GUI”) leading the user through the registration process. The level of authentication of the user at registration may be selected by the administrators of the system  100  and can range, for example, from a user presenting the correct password to the application server  106  to a user being present in person in front of an administrator who can check the identification of the user.  
         [0029]    Once the system  100  registers an individual, the single-sign-on application server module  120  creates an association between the data identifying the user to the single-sign-on system and the user&#39;s alias in the application database  116 , and another association between the user&#39;s alias and the user&#39;s authentication data in the single-sign-on database module  124 . Storing the two associations at locations separate from each other requires a breach in security of both the application database  116  and the single-sign-on database  124  to put authentication data together with some identifying data. For example, the first association may be stored in the application database module  116  residing on one physical server, while the second association may be stored in the single-sign-on database module  124 , residing on a second physical server. Further, if the identifying data is just another unique identifier that does not reveal identity by itself, for example an employee number, then the security of a third database (not shown) containing the association between the employee number and the identity (e.g., name and address of the employee) would have to be breached to match the identity of the user with that individual&#39;s biometric data.  
         [0030]    With an individual registered in the single-sign-on server  108  (i.e., with user-identifying information, an alias, and authentication information obtained and stored in the single-sign-on database module  124 ), a process  200  as shown in FIG. 2 may be used to authenticate a user to one or more applications without the user having to provide authentication information for the application(s) each time the user requests access. The user  102  of the client  104  logs into the single-sign-on server  108  (step  202 ) by providing one or more of a password, user identification code, biometric data, or the like. The single-sign-on server  108  authenticates the user (step  204 ) and retrieves the user profile  134  associated with the user  102  from the single-sign-on database module  124  (step  206 ). The single-sign-on server  108  sends the user profile  134  to the client  104  (step  208 ) for future use by the single-sign-on agent  132 .  
         [0031]    In one version of the above-described embodiment, the user profile  134  remains on the client  104  after the user  102  terminates each session. In this case,the user profile  134  that is sent from the single-sign-on server  108  automatically overwrites the user profile  134  from the previous session. More preferably, however, the user profile  134  is deleted upon termination of each session for security purposes. In either case, once the update data arrives from the single-sign-on server  108  and is stored in the user profile  143  on the client  104 , the single-sign-on agent  132  uses the data contained in the user profile  134  to automatically register the user  102  with the application  114  without the user needing to perform any authentication procedures.  
         [0032]    The application server  106  provides access to a service (e.g., execution of an application program, access to a financial or medical database, access to an electronic vault with which the user is associated, download of data and/or application program and the like). As illustrated in the present embodiment, the user of an application requests access to the application by navigating to a login page or to an access screen for the application (step  210 ). The single-sign-on agent  132  recognizes the user action as a request to access an application and determines if the application is a restricted access application (decision step  212 ). If the single-sign-on agent  132  determines that, based on the data stored user profile  134  and described in detail above, the application is not restricted, access is granted (step  214 ).  
         [0033]    Alternatively, if the single-sign-on agent  132  determines that the requested application is a restricted access application, the single-sign-on agent  132  traps the login or access screen (step  216 ). The login or access screen may be trapped by, for example, querying an operating system message queue, initiating random screen captures, attaching an object to an Internet browser to intercept HTTP messages, connecting to a terminal emulator using the HLLAPI protocol, and recognition of HTTP addresses, among other methods. In conjunction with trapping the login screen, the single-sign-on agent  132  queries the user profile  134  to determine the authentication modality used to gain access to the application (step  218 ). The single-sign-on agent  132  further determines whether the user  102  has previously accessed the application being requested (decision step  220 ). If in one instance, the user  102  has previously accessed the application being requested, the single-sign-on agent  132  obtains the application credentials (step  222 ) from the user profile  134 , completes the login form or access screen, and transmits (step  234 ) the credentials to the application server  106 . The application server  106  may then grant the user access to the application (step  214 ).  
         [0034]    For example, in the case of a web application,the single-sign-on agent  132  may recognize, based on an entry in the user profile  134 , an HTTP address entered by the user into the location field of a client-resident Internet browser application. If, for example, the resulting web page includes form fields requiring user authentication, the single-sign-on agent  132  queries the user profile  134  for the data records corresponding to that address, which include the data necessary to complete the form. Recognizing the data as corresponding to the requested web page, the single-sign-on agent  132  automatically completes the form and sends the data to the application server  106 . Thus, the user gains access to the application without having to enter her authentication information and can perform the desired functions within the application.  
         [0035]    Alternatively, for network-based applications accessed via application server  106 , the single-sign-on agent  132  monitors the operating system message queue, recognizes messages corresponding to the requested application (based on entries in the user profile  134 ) and takes the appropriate action (also as specified entries in the user profile  134 ), e.g., logging the user in or, as described below, enforcing restrictions.  
         [0036]    In another instance of the current example, a user  102  may be requesting access to an application for the first time. In such a case, the single-sign-on server  108  may not have the correct authentication credentials for the user  102 , and therefore the single-sign-on agent  132  will not be able to complete the login screen. Therefore, the user  102  manually enters her authentication credentials (step  224 ) using one or more input devices  126 . Using one or more of the methods described above, the single-sign-on agent  132  captures the authentication credentials (step  226 ), and if the login is successful, sends the information to the single-sign-on server  108 . The single-sign-on server  108  receives the authentication credentials for the newly requested application (step  228 ), and sends them to the single-sign-on database module  124 . The single-sign-on server  108  then updates the user profile (step  230 ) in the single-sign-on database module  124 , and sends the updated user profile  134  back to the client  104 . The single-sign-on agent  132  then obtains the application credentials (step  222 ) from the updated user profile  134 , completes the login form or access screen, and transmits (step  234 ) the credentials to the application server  106 . The application server  106  may then grant the user access to the application (step  214 ).  
         [0037]    In some circumstances, the login process may not be successful. This may be due to the user  102  manually changing his application password, the password expiring, an administrator resetting the password, or other application specific event. In such cases, the single-sign-on agent  132  recognizes the screens or messages representing an unsuccessful login sent from the application server  106  to the client  104 . The application  106  can then send screens to the client  104  instructing the user  102  to reset his password PIN, or other authentication data. The single-sign-on agent  132  captures the reset process, updates the user profile  134  with the new data, and sends the new password to the single-sign-on server  108  where it is stored in the database module  124 . The single-sign-on server  108  can then send the user profile  134  back to the client  104  for use during the current and/or future sessions. In some versions, the single-sign-on agent  132  can also automatically generate a random password for the user  102  such that the user  102  is unaware of the password-reset process.  
         [0038]    With an individual registered in the single-sign-on server  108  (i.e., with user-identifying information, an alias, and authentication information obtained and stored), a process  300  as shown in FIG. 3 may be used to automatically withdraw a user&#39;s access rights to an application and to define events that require a user to be re-authenticated. Prior to a user  102  being logged into the single-sign-on server  108 , an administrator may define trigger events (step  302 ) which, when recognized by the single-sign-on agent  132 , may terminate access, or require re-authentication, to the single-sign-on server  108 . A trigger event can be a particular function or screen accessed by a user, a broken communications link, inactivity of the user, a signal from the server sent on a periodic or random basis, expiration of an application password, or the like. Furthermore, trigger events can be set globally for all users and all applications, for individual users across all registered applications, for particular applications, for certain modules within applications, or for entries in selected fields on particular screens. The trigger events can be stored in the single-sign-on database module  124  as part of a user profile  134 . When a user  102  logs into the single-sign-on server  108  (step  304 ), his authentication credentials are authenticated (step  306 ) by the single-sign-on server  108 . The single-sign-on server  108  queries the single-sign-on database module  124  and gathers the data necessary to construct the user profile (step  308 ). The single-sign-on agent  132  residing on the client obtains the user profile data from the single-sign-on server  108  and stores the user profile on the client  104  (step  310 ).  
         [0039]    Continuing with the example above, a user  102  requests access (step  312 ) to an application server  106 . The single-sign-on agent  132  retrieves the authentication credentials (step  314 ) from the user profile  134  residing on the client  104 , and transmits the credentials to the application server  106 . The application server  106  receives the application credentials (step  316 ) from the client  104 , and grants the user  102  access to the requested application (step  318 ). Once granted access to the application server  106 , the user  102  may execute functions (step  320 ) within the application based on the data stored in his user profile  134 .  
         [0040]    Data specifying these restrictions is stored in the user profile  134 , and once again, the single-sign-on agent  132  constantly monitors the user&#39;s activities (by trapping screens, fields within a screen, etc.) and permits execution of only these actions consistent with the restrictions.  
         [0041]    For example, a first user  102  may be restricted to view only particular screens within an application, may only have read access to data on particular screens, may only be able to update a single field on a screen, or may be blocked from viewing certain web pages within a permitted web site. Conversely, a second user (not shown) may have full administrative rights to an application, and/or may have rights to view any or all web pages within a particular web site. Therefore, the single-sign-on agent  132  may restrict the first user&#39;s actions based on the information in her user profile (preventing transmission of “save” commands in conjunction with read-only data or requests for disallowed web pages), while the second user may have no restrictions on the functions she may perform, or data she can enter and update based on the data in her user profile.  
         [0042]    In one particular version, the invention permits an administrator to revoke a user&#39;s access to one or more applications  114  registered with the single-sign-on server  108 , even in the case where the user  102  is currently logged into the application(s). Referring again to FIG. 3, the single-sign-on agent  132  may constantly monitor the ongoing user activity (step  320 ) for activities corresponding to entries in the user profile  134  currently residing on the client  104 . An administrator may then update one or more user profiles  134  (step  22 ) with instructions that the user&#39;s access rights are to be revoked. The updated user profile may then be sent (step  324 ) to the client  104  for use by the single-sign-on agent  132  as it monitors ongoing user activity, overwriting the previous user profile  134 . If the single-sign-on agent  132  receives notice the user&#39;s access rights have been revoked (decision step  328 ), the single-sign-on agent traps the user activity and terminates access (step  326 ) to the identified application(s)  106 .  
         [0043]    A user  102  may also be required to re-authenticate himself to the single-sign-on server  108  based on one or more trigger events. A re-authentication trigger event may be, for purposes of illustration, a particular function initiated by a user or an administrator, a broken communication link, a screen or web page requested by a user, inactivity of the user, passage of some period of time, revocation of access rights, the execution of a particular sequence of functions, elapsed time within an application, the receipt of web content, or a signal from the server sent on a periodic or random basis. The trigger events can be stored in the single server database module  124  as part of a user profile  134 , and are sent to the client  104  when a user  102  logs into the single-sign-on server  108 . As the user  102  performs ongoing activities within applications, the single-sign-on agent  132  can determine if the user&#39;s access privileges have been revoked (decision step  328 ). If a user&#39;s access privileges have not been revoked, the single-sign-on agent  132  can then determine if a re-authentication trigger event has occurred (decision step  330 ). If, in one case, no re-authentication trigger event has occurred, the user  102  may continue to use the application(s)  106  without interruption. If, however, a re-authentication trigger event has occurred, the user activity can be interrupted and the user may be presented with a login screen (step  304 ) for the single-sign-on server  108 .  
         [0044]    [0044]FIG. 4 illustrates yet another feature of the invention that facilitates the capturing of some or all of a user&#39;s activities (or particular specified activities) within one or more applications, and the recording of the activities in audit records, which may be stored on the single-sign-on server  108 , in the user profile  134 , or both. As discussed above, the user of an application requests access to the application by navigating to a login page for the single-sign-on server (step  402 ). The user is authenticated (step  404 ) to the single-sign-on server  108 , the user profile  134  for that user is retrieved (step  406 ) from the single-sign-on database module  124 , sent to the client  104 , and obtained (step  408 ) by the single-sign-on agent  132 . A user  102  may now request access (step  410 ) to one or more applications  106  via the single-sign-on server  108 , according to the process described above and illustrated in FIG. 2.  
         [0045]    As described above, the single-sign-on agent  132  obtains the application credentials (step  412 ) from the user profile  134 , completes the login form or access screen, and transmits (step  414 ) the credentials to the application server  106 . The application server  106  then grants the user  102  access to the application (step  416 ), and the user  102  may then perform various functions (step  418 ) within the applications which are completed (step  420 ) by the application server  106 . During this process, the single-sign-on agent  132  can capture, on a continual, predefined, random or some other periodic basis, (step  422 ) data relating to the functions requested or performed by the user  102 .  
         [0046]    For example, the mere fact that the user has accessed the application and the time this occurred may represent an auditable event. Thus, as previously described, the single-sign-on agent  132  watches for user activities (again, as specified in the user profile  134 ) by monitoring message queues, HTTP requests, screens or the like, and the accessed application and the time of access may be stored as audit data in an audit log. For example, the data may initially be stored in the client  104  and periodically and/or concurrently sent to the single-sign-on server  108  for storage on the database  124 .  
         [0047]    Specific user transactions may also represent auditable events. Data specifying these events may be stored in the user profile  134  and organized as sublistings according to the applications to which they relate. For example, suppose the user accesses his brokerage account, checks his portfolio positions, and orders a trade. Perhaps successful login to the account and the trade execution represent auditable events, but the portfolio query, as no more than status check, may not be such an event. In this case, a sublisting of auditable events pertaining specifically to the brokerage account HTTP is stored in the user profile  134  along with data enabling the single-sign-on agent  132  to trap the appropriate data. For example, the user profile may specify data enabling recognition of the trading page, as well as the page fields corresponding to the desired audit data and an instruction to attach a time stamp to the data when it is transmitted. More generally, the single-sign-on agent  132  monitors the user&#39;s activity in accordance with the sublistings corresponding to the current application, and extracts the audit information specified therein. For example, as noted above, the single-sign-on agent  132  may send the captured data (step  424 ) to the single-sign-on server  108 , which thereby obtains the records of the captured user activities (step  426 ), and may update the audit log (step  428 ) stored in the single-sign-on database module  124 .  
         [0048]    In this way, the need to store audit data on an application-by-application, server-by-server basis is eliminated. Instead, such data can be stored on a user basis across applications, and in whatever physical location is deemed appropriate. The data may later be sorted to track the user&#39;s individual activity, or to track the activities of all users of a given application.  
         [0049]    In the embodiments of the invention described above, the software may be configured to run on any computer or workstation such as a PC or PC-compatible machine, an Apple Macintosh, a Sun workstation, etc. In general, any device can be used as long as it is able to perform all of the functions and capabilities described herein. The particular type of computer or workstation is not central to the invention.  
         [0050]    The single-sign-on server  108  may include a network interface continuously connected to the network  110 . In a typical implementation, the network interface and the other internal components of the single-sign-on server  108  intercommunicate over a main bi-directional bus. The main sequence of instructions effectuating the functions of the invention and facilitating interaction among clients  104 , servers  106  and  108 , and the network  110  can reside on a mass storage device (such as a hard disk or optical storage unit) as well as in a main system memory during operation. Execution of these instructions and effectuation of the functions of the invention is accomplished by a central-processing unit (“CPU”).  
         [0051]    A group of functional modules that control the operation of CPU and effectuate the operations of the invention as described above can be located in system memory. An operating system directs the execution of low-level, basic system functions such as memory allocation, file management, and operation of mass storage devices. At a higher level, a control block implemented as a series of stored instructions, responds to client-originated queries by selecting and/or assembling, and then transmitting, appropriate data.  
         [0052]    Equivalents  
         [0053]    The invention can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting on the invention described herein. Scope of the invention is thus indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.