Patent Publication Number: US-2003236977-A1

Title: Method and system for providing secure access to applications

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
     [0001] This application claims priority to U.S. Provisional Patent Application Nos. 60/347,392 filed Jan. 9, 2002, and 60/378,305 filed May 7, 2002 and is a continuation-in-part of U.S. patent application Ser. Nos. 09/842,266; 09/841,732; 09/842,268; 09/841,733; 09/842,267; 09/841,731; and 09/842,269; each filed Apr. 25, 2001; and Nos. 10/090,689; 10/090,680; 10/090,681; and 10/090,679; each filed Mar. 5, 2002. 
    
    
     
       STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH  
       [0002] Not applicable.  
       BACKGROUND OF THE INVENTION  
       [0003] 1. Field of the Invention  
       [0004] The present invention is directed generally to methods and systems for providing secure access to applications over computer networks.  
       [0005] 2. Description of the Background  
       [0006] Maintaining security and privacy with respect to certain information is of great importance to many industries, such as the healthcare industry, as well as to the government. While various systems exist for providing individuals access to information in a secure fashion, such systems are less than ideal. For example, existing systems require IT administrators to build lists of authorized individuals, thereby requiring involvement of IT administrators every time a new individual is to be provided with secure access to information.  
       [0007] Further, some existing systems are tied to organizational models of roles. In particular, individuals on a particular access list are assigned to roles by virtue of their job function or departmental affiliation and are thereby granted access to confidential information generally deemed appropriate for their role. Such systems are not useful in situations in which different organizations cooperate on a project or otherwise have a need to share data. Also, in the cooperative organization situation, each of the users requiring access to an application may employ a different authentication modality and, thus, there is a need to accommodate a diverse group of users within a single system. Moreover, because such systems are role-based and not individualized, delegating access to applications on a need-to-know basis becomes cumbersome. Other security models are rules-based (e.g., customers who register and provide a valid credit card may open an account and view certain information). Such rules-based systems make auditing access to information difficult and implementation on a large scale expensive.  
       [0008] While existing systems allow organizations to control access to information at a high level (i.e., a user may gain access to an application and delegate such access to others or not), in certain circumstances, it may be advantageous to maintain more fine-grained control over such access. In addition, while certain existing security solutions allow reasonable protection in connection with providing access to permanent employees, such solutions are not acceptable for situations in which an individual is to be provided access to applications for a limited period of time (for example, a temporary employee, consultant, customer, supplier, or collaborator) or in which it may become necessary to revoke access rights quickly.  
       BRIEF SUMMARY OF THE INVENTION  
       [0009] The present invention is directed to methods and systems for providing secure access to applications over a computer network. An administrative user who is authorized to delegate to a first user a permission to access an application authenticates to a server. A request is received at the server from the administrative user to delegate a first permission to access at least a portion of the application to the first user. The server receives a request from the first user to register with the server. The administrative user authenticates the first user with authentication information, which includes non-secret information. The first user is provided access to the application.  
       [0010] The present invention is also directed to methods and systems for delegation of permits with specialized limitations. A first user delegates to a second user permission to access an application. In connection with the delegation, an access control list is appended with the identity of the first user (the issuer); the identity of the second user (the subject); the identity of the application to which access is delegated; and a limitation on the number of further delegations the second user can make and, in some cases, a limitation on the length of the delegation chain. Upon authenticating the second user, the second user is provided with access to the application. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0011] The accompanying drawings, wherein like referenced numerals are employed to designate like parts or steps, are included to provide a further understanding of the invention, are incorporated and constitute a part of this specification, and illustrate embodiments of the invention that together with the description serve to explain the principles of the invention.  
     [0012] In the drawings:  
     [0013]FIG. 1 illustrates a preferred embodiment of a system used in connection with the present invention.  
     [0014]FIG. 2 illustrates an exemplary database schema for storing data generated in connection with a preferred embodiment of the present invention.  
     [0015] FIGS.  3 A- 3 D illustrate process flow diagrams illustrating one embodiment of the authorization, delegation, registration, and the authentication process flows, respectively, of the present invention.  
     [0016] FIGS.  3 E- 3 G illustrate process flow diagrams illustrating an alternate embodiment of the access control, delegation, and retrieve delegation process flows, respectively, of the present invention.  
     [0017] FIGS.  4 A- 4 Y illustrate exemplary user interfaces that may be used to access various aspects of the system, in accordance with a preferred embodiment of the present invention.  
     [0018]FIG. 5A is a flow chart illustrating a preferred embodiment of a method of the present invention.  
     [0019] FIGS.  5 B- 5 E illustrate exemplary user interfaces that may be employed in connection with the present invention.  
     [0020]FIG. 6 is a flow chart illustrating a preferred embodiment of a method of the present invention. 
    
    
     DETAILED DESCRIPTION  
     [0021] Among many other benefits, the present invention allows trusted users to delegate secure access to others, eliminating the need for an IT administrator continually to create and manage lists of users. Allowing for chained delegations (i.e., delegating the power to delegate) enables decision making as close as necessary to the front lines. In particular, decisions can be made by the people directly involved, who know the people to whom they are providing access and who are in the best position to administer secure authentication protocols. Moreover, the invention supports authentication and authorization in real-world, mixed environments where users employ different means for authentication. These and other advantages and benefits of the present invention will become apparent from the detailed description of the invention herein below.  
     [0022] Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. It is to be understood that the figures and descriptions of the present invention included herein illustrate and describe elements that are of particular relevance to the present invention, while eliminating, for purposes of clarity, other elements. Those of ordinary skill in the art will recognize that other elements are desirable and/or required in order to implement the present invention. However, because such elements are well known in the art, and because they do not facilitate a better understanding of the present invention, a discussion of such elements is not provided herein.  
     [0023] The systems and methods disclosed herein relate to providing secure access to applications. An application may include any object, data, document, file, directory, text, software, computer application or other information to which secure access is desired. Such secure access is provided by way of delegations (also referred to herein as permits), pursuant to which privileges for a resource (i.e., pointers to applications) are passed from user to user. Users may only delegate existing resources, either ones that were delegated to them or ones that they created. In order to re-delegate a resource (the same or less access) that was delegated to the user, the user must be authorized to do so. Each delegation includes, in the preferred embodiment, an issuer; a subject; the desired resource; one or more constraints (e.g., validity period, authority to re-delegate etc.); a validity state; and, optionally, one or more attached files and/or a secure message.  
     [0024] Resources are qualified pointers to applications, which are uniquely identified by a resource identifier (“RI”). While in some embodiments, the RI may be a Uniform Resource Identifier (“URI”) or a Uniform Resource Locator (“URL”), which identify an electronic resource that belongs to a specific machine or file name, in other embodiments, the RI may identify a resource that represents a physical object, such as a door. In a preferred embodiment, the RI includes a mechanism used to access the resource, the specific location of the resource (e.g., the computer that houses the resource), and the specific name of the resource at that location (e.g., on the computer). For example, in an embodiment in which the application resides on a web server, the resource is identified by a URL, such as http://www.some_domain.com/someApp?Id= 1 &amp;View=All.  
     [0025] Resource groups are logical groupings of RIs that are used in the authorization process to determine if a user is authorized to gain access to a particular application. While a particular permit delegated to a user may point to a single RI, this particular RI may be associated with a group of related RIs (i.e., a resource group) such that access to one RI may imply access to a group of RIs.  
     [0026]FIG. 1 depicts a preferred embodiment of a system  100 , which may be used to support the present invention. The client/server configuration illustrated in FIG. 1 includes client  101 , application server  102 , and authentication/authorization server  103 . While in the configuration of FIG. 1, application server  102  and authentication/authorization server  103  are shown as two separate servers, the components of and functionality performed by each server may be combined into a single server or may be spread out over multiple servers. Such alternate embodiments are within the scope of the present invention. Client  101 , application server  102 , and authentication/authorization server  103  are linked together to form a computer network, such as a local area network, a wide area network, or the Internet. Where the communications among client  101 , application server  102 , and authentication/authorization server  103  take place over the Internet, client  101  requires an SSL-enabled web browser.  
     [0027] Application server  102  maintains the applications  106  to which a user at client  101  seeks access. Database  107  stores information specific to the applications  106 . Authentication/authorization server  103  includes the components that are used in connection with the authentication and authorization processes. In the preferred embodiment, application server  102  and authentication/authorization server  103  reside in same domain, given that the preferred embodiment of the invention is implemented using two cookies—a persistent cookie that contains user preference data, which is set on client  101  by authentication/authorization server  103 , and a session cookie, which contains authentication information and is not stored to a disk. In other embodiments, however, the application server  102  and the authentication/authorization server  103  do not reside in the same domain. In these embodiments, authentication information (e.g., password, certificate etc.) is collected by the application server  102  and sent to the authentication/authorization server  103  for verification. The authentication/authorization server  103  then sends the data to be maintained in the cookie to the application server  102 . The application server  102  then sets the cookie on the client  101 , thereby eliminating the need for both the application server  102  and the authentication/authorization server  103  to reside in the same domain.  
     [0028] Component  108  of authentication/authorization server  103  encapsulates services available to applications  106  on application server  102 . In the preferred embodiment, two types of services are available: authorization service  112  and user data service  111 . Authorization service  112  may be used by an application  106  to query for authorization rights for a specific user regarding a specific resource. User data service  111  may be used by an application  106  to query for information about a user.  
     [0029] Component  109  encapsulates modules of the system  100  with which users interact. In particular, administration module  113  of component  109  allows an administrative user, with proper authorization, to view and update system parameters, in accordance with one embodiment. In addition, administration module  113  is used to register, configure and remove applications from the authentication/authorization server  103 . Authentication module  116  maintains data pertinent to the user&#39;s registration with the system, such as the user&#39;s name and electronic mail address, and including the authentication modality (e.g., password, digital certificate) chosen by the user. Account manager module  117  allows users to manage their permits. For example, using account manager module  117 , the user may confirm or revoke permissions to access applications for which the user has issued permits. In addition, account manager module  117  allows users to change their account preferences, such as the display of their name or their authentication modality. Account manager module  117  also allows a user to view permits created by that user and, if desired, send such permits. This module also allows the user to view permits sent to that user and send such permits to another if authorized to do so (i.e., further delegate permission to access the application).  
     [0030] Permit module  114  is responsible for displaying information about permits. Delegation module  115  is responsible for creating permits. In some embodiments, permit module  114  and delegation module  115  are implemented as a single component.  
     [0031] Database  110  stores the data generated in connection with the delegation, authorization and authentication activities performed by the various components of system  100 . FIG. 2 illustrates an exemplary database schema for database  110  of FIG. 1. In embodiments in which system parameters can be configured by a user by way of the system  100 , such parameters are maintained in table  202 . Errors table  280  represents error messages that are displayed to the user. Application information, such as the resource identifier and name, are stored in table  204 . Each resource group  206  is associated with an application  204 . An application may own one or more resource groups. Associated with each resource group are one or more resource group RIs (e.g., URLs), which are stored in table  208 . Also associated with each resource group are resource group parameters, which are stored in table  210 . Information regarding resources, which belong to a particular resource group, is stored in table  212 . Such information includes, in the preferred embodiment, an identification of the owner of the record (i.e., the user that created the resource), the resource group identifier, the name of the resource, and the base RI (e.g., base URL) for the particular resource. Each resource has associated with it resource parameters, which are stored in table  214 .  
     [0032] Referring still to FIG. 2, information regarding users who are registered with the system is maintained in table  260 . Such information includes, in the preferred embodiment, the user&#39;s electronic mail address, first and last name, an identifier of the authentication module used to authenticate the particular user, a confirmation identifier (used, in one embodiment, to identify a user upon registration with the system), the user&#39;s authentication state, and a time stamp. Table  216  maintains an authorization log indicating, by way of example, for a particular identified user, the RIs such user has accessed, the parameters associated with accessing the RI, whether the access attempt was successful, the time period for which the user is authorized to access the application, and whether the user is permitted to delegate the resource to others. To the extent user groups are employed (to allow users to build address books and create groups to which the user may delegate permits), tables  218  and  220  would be used to store such information. Table  291  stores information regarding the user&#39;s state (e.g., unregistered, pending, confirmed, disabled, revoked). Table  232  stores information regarding changes in the user&#39;s state. Thus, for example, for a particular user identifier or changed user identifier, table  232  stores the user&#39;s old state, new state, and level (i.e., the user&#39;s level relative to other users of the system, such as active, revoked, or blocked, as opposed to a system level state, such as unregistered, pending, active, revoked, or blocked, which is stored in table  260 ). Administrator table  290  maintains information regarding administrative users of the system  100 , including the type of administrator described in the particular record (such as system, user, application or root) and managed identifier, which indicates the administrator who has rights to manage the administrator represented by the record.  
     [0033] Table  224  maintains configuration information for authentication module plug-ins, thereby enabling the system to accept from users a variety of different types of authentication modalities. Table  226  is a log of authentication attempts. Tables  230  and  228  store user-specific authentication information. In the event a user chooses to authenticate him/herself using a password, information regarding the same is maintained in table  228 . Information regarding authentication using a digital certificate is maintained in table  230 . To the extent additional authentication modalities can be used in connection with the system  100 , additional data tables would be included to accommodate the same, within the scope of the present invention.  
     [0034] Information regarding delegations/permits is stored in tables  234 ,  236 ,  238 ,  240 ,  292  and  293 . In the preferred embodiment, delegation table  234  stores information regarding the identity of the delegation owner (i.e., the individual who originally issued the permit), the identity of the issuer of the permit, the identity of the permit subject, the identity of the resource, the state of the permit (i.e., whether the permit has been revoked), the method for creating the permit (i.e., whether the delegation was created manually, where the user affirmatively delegates a resource to another user, or automatically, where the ownership of a delegation is changed), whether the resource is further delegable (including, in the preferred embodiment, any vertical and horizontal limitations on delegations), the time period in which the permit is valid, and whether a message is associated with the delegation. Table  236  stores information regarding the delegation trail, including the identity of a particular delegation and the identity of the parent delegation, from which the particular delegation was derived. To the extent any files are attached to a delegation, information regarding the same is stored in tables  240  and  238 . For a particular delegation (identified by a delegation identifier), which has been delegated to a particular user (identified by a user identifier), delegation state change log  292  maintains information regarding the old and new states (i.e., active, blocked, or revoked)) of the delegation as of a certain time. For a particular user and delegation, delegation owner change log  293  maintains information regarding the identity of the old and new owner of the delegation.  
     [0035]FIGS. 3A through 3D are flow diagrams illustrating the authorization, delegation, registration and authentication process flows, in accordance with one embodiment of the present invention. FIG. 3A illustrates one embodiment of the authorization process flow. In step  302 , the user browses to an application of interest. In step  303 , the application checks for the user&#39;s authentication cookie. If the cookie does not exist, the application redirects the user to the authentication application in step  305 . In step  306 , the user browses to the authentication application and an authentication attempt is made in step  307 . FIG. 3D illustrates one embodiment of the authentication process flow. If the authentication attempt is not successful, the user is denied access to the application in step  309 . If the authentication attempt is successful, the user is redirected to the original RI (step  302 ) corresponding to the application, in step  308 . The application again checks for the authentication cookie in step  303 . At this point, the authentication cookie exists and, in step  304 , the application requests, from the authentication/authorization server  103 , the authenticated user&#39;s access rights.  
     [0036] In step  310 , the authorization component again checks whether the user is authenticated. If not, in step  314 , an error code is generated and returned, in step  315 , to the application server  102 . The error code is checked in step  316  to determine if the user is authorized. If not, an HTML error page is generated in step  318  and displayed to the user in step  319 . If the user is authorized, an HTML page is generated in step  317  and displayed to the user in step  319 . If, in step  310 , it is determined that the user is authenticated, in step  311 , it is determined whether the user is authorized to access the application. If so, in step  312 , a success code/message is generated, and the code/message is returned in step  315 . If in step  311  it is determined that the user is not authorized, in step  313 , and error code/message is generated and returned in step  315 . The process then continues from step  316  as previously described.  
     [0037]FIG. 3B illustrates one embodiment of the delegation process flow. In step  320 , the user browses to the application delegation web page. In step  321 , the application checks to see that the user is authenticated and authorized to delegate a resource relating to the subject application. If not, in step  322 , the steps set forth in FIG. 3A are performed (i.e., if the user is not authenticated, the authentication process will proceed; once the user is authenticated the authorization process commences). If so, the user&#39;s credentials and delegation parameters are passed to the authentication/authorization server  103  in step  323 . In step  324 , the user and the parameters inputted by the user are checked. If the user and parameters are valid, in step  326 , a permit, success code and message are generated and returned to the user in step  327 . If the user and/or the parameters are not valid, in step  325 , an error code and message are generated and returned to the user in step  327 . In step  328 , the application server  102  checks the code and message returned in step  327 . If the code indicates that validation was not successful, in step  329 , an error page is generated and returned to the user. If the code indicates that the validation was successful, in step  330 , an HTML page indicating this success is generated. The page contains a registration RI. In step  331 , this page is shown to the user at client  101 . In step  332 , an electronic mail message containing the registration RI is sent to the subject (i.e., the delegatee).  
     [0038] In the preferred embodiment, system  100  includes a time out feature. In particular, the user&#39;s session will time out after a certain period of total time that the user has been logged onto the system and/or after a certain period of idle time. If one of the timeout values expire, the user will be required to log in and commence the authentication/authorization process anew. In other embodiments of the invention, a time out feature is not implemented.  
     [0039] While in the preferred embodiment, only users who are delegated a permit may register with the system, in other embodiments, any user may register with the system. FIG. 3C illustrates one embodiment of the registration process. In step  333 , a user browses to the registration URL. In step  334 , the authentication/authorization server  103  attempts to validate the URL. If the URL is invalid, in step  335 , the user is not permitted to access the application. If the URL is valid, in step  336 , the user is registered, along with the URL, if necessary. In step  337 , the authentication/authorization server  103  checks for proper authentication and authorization (see FIGS. 3A and 3D). If the user is not authorized, it is determined in step  338  whether the user needs to be registered. If not, in step  339 , the process fails and the user cannot access the registration application (i.e., because he is already registered). If the user needs to be registered, in step  340 , user proceeds with the registration process. If in step  337  the user is authorized and authenticated, in step  341 , the user is redirected to the application. In step  342 , the user accesses the application.  
     [0040]FIG. 3D illustrates one embodiment of the authentication process flow. In step  343 , the user browses to the authentication application. In step  344 , the authentication/authorization server  103  checks to see if the user is authenticated. If not, in step  345 , the authentication/authorization server  103  checks for a valid preference cookie. If there is no preference cookie, in step  346 , the user is asked to provide his mode of authentication preference and a cookie, indicating this preference, is written to the client machine  101 . Then, in step  347 , the module corresponding to the user&#39;s preferred mode of authentication is loaded. Similarly, if a preference cookie exists in step  345 , the module corresponding to the user&#39;s preferred mode of authentication is loaded in step  347 . In step  348 , the user is forwarded to the user interface used in connection with the authentication process. In step  351 , this user interface is displayed on the client machine  101  and the user enters his credentials. In step  352 , an attempt to verify the user&#39;s credentials is made. If the user is not authenticated with the credentials provided, the user is again forwarded to the user interface to provide the credentials a second time. If the user&#39;s credentials are verified, an authentication cookie is written in step  353 . In the preferred embodiment, the cookie is a non-persistent cookie that is destroyed when the browser is closed. In addition, the authentication cookie contains no authentication data and only holds a date, an authenticated user identifier, and a signature. In step  349 , the user is redirected to the desired RI and, in step  350 , the user is able to browse to the RI using client  101 . Referring back to step  344 , if the user is authenticated, the user is redirected to the desired RI in step  340 .  
     [0041]FIGS. 3E, 3F, and  3 G are flow diagrams illustrating the access control, delegation, and retrieve delegation process flows in accordance with an alternate embodiment of the present invention. With reference to FIG. 3E, in step  370 , the user browses to an application. In step  371 , an application JSP checks for a valid authentication cookie. If a valid authentication cookie is identified, in step  387 , authentication/authorization server  103  is asked for access rights. In step  388 , an authorization JSP checks the validation query. If the query is not valid, in step  392 , an error code and message are generated. If the query is valid, in step  389 , an authorization JSP checks for valid authorization data. If valid authorization data is identified, in step  390 , a success code and message are generated. If not, in step  391 , it is determined if such authorization is pending. If so, a pending code and message are generated in step  392  and, if not, an error code and message are generated in step  393 . In step  395 , the appropriate code and message are returned. In step  396 , the returned code is checked. If the user is authorized, an HTML page is generated in step  398  and shown to the user in step  399 . If the user is not authorized, an HTML error page is generated in step  397  and shown to the user in step  399 .  
     [0042] Returning again to step  371  of FIG. 3E, if the user is not authenticated, in step  372 , a redirect is generated. In step  373 , the user browses to an authentication page on authorization server  103 . Here, in step  374 , an authentication JSP determines if the user is authenticated. If so, in step  386 , the user is redirected back to the application (step  370 ). If not, in step  375 , an authentication JSP checks for the client authentication preference cookie. If there is no preference cookie, in step  376 , the subject is permitted to select an authentication method and, upon doing so, an authentication preference cookie is set. Then, (or if a preference cookie exists in step  374 ), the client is redirected to the proper authentication method application according to the user&#39;s preference, in step  377 .  
     [0043] In step  378  of FIG. 3E, the user browses to the authentication page. In step  379 , the authentication application asks for the user&#39;s credentials in step  379 . If valid, a non-persistent authentication cookie is set in step  381 , the user is redirected to the original URL in step  386 , and browses back to the application in step  370 . If not valid, it is determined in step  380  whether the user&#39;s authentication is pending. If pending, the user is denied access in step  385 , but only pending confirmation from the permit issuer. If the user&#39;s authentication is not pending, in step  382 , it is determined whether the user has a delegation URL. If not, in the preferred embodiment, in step  384 , the user cannot register because he does not have a delegation URL. While in other embodiments it is possible for the user to register without having first been issued a delegation, this may not be preferred as it would result in cluttering the database  110  with unnecessary user registration information. If the user has a delegation URL, in step  383 , the user is registered in an unconfirmed state. The user must be confirmed to continue. An example of this confirmation process is illustrated with respect to FIGS.  5 A- 5 D.  
     [0044] Referring now to FIG. 3F, a delegation process flow chart, in accordance with another embodiment of the present invention, is illustrated. In step  3301 , a user seeking to make a delegation browses to the delegation page. An application JSP checks for the existence of a valid authentication token in step  3302 . In some embodiments, both an authentication cookie and an authorization cookie may be used. If the cookie does not exist, in step  3304 , the user continues in accordance with the process flow illustrated in FIG. 3E. If the user is authenticated and authorized, in step  3303 , the user&#39;s credentials and delegation parameters are passed to the delegation service on authentication/authorization server  103 . In step  3305 , a delegation JSP determines if the parameters are valid. If not, an error code and message is generated in step  3309 . If the parameters are valid, in step  3306 , the delegation JSP checks for authorization to access and delegate the URL. If authorized, in step  3307 , a delegation RI is generated, along with a success code and message. If not authorized, in step  3308 , an error code and message are generated. Depending on the outcome of step  3309  and  3306 , XML data is returned in step  3310 . In step  3311 , the application JSP checks the data returned in step  3310 . If the data indicates that the attempt to create a delegation was successful, in step  3313 , a permit is generated (which contains the delegation RI) and displayed to the user in step  3314 . If the data indicates the attempt was unsuccessful, in step  3312 , an error page is generated and displayed to the user in step  3314 .  
     [0045] In accordance with the retrieve delegation process flow chart of FIG. 3G, a user may retrieve a permit delegated to that user in accordance with one embodiment of the present invention. In step  3320 , the user may browse to a location indicated in a permit issued to the user (e.g., by way of a URL). In one embodiment, in step  3321 , a delegation JSP validates the delegation RI (e.g., the URL) with a signature. In step  3322 , the process fails if the delegation RI is invalid. In step  3323 , if the delegation RI is valid, the delegation JSP finds the application RI matching the reference identifier in the delegation RI. If not found, the process fails in step  3322 . If found, in step  3324 , the delegation JSP checks to see if the user has identified himself to the system. If so, in step  3325 , the user is redirected to the application RI. In step  3326 , the user browses to the application page. In step  3327 , the user is taken through the access control process, illustrated by way of example in FIG. 3E. If in step  3324  the user is not authenticated, in step  3328 , the user is redirected to a location for authentication.  
     [0046] In step  3329 , the user browses to the authentication location. In step  3330 , an authentication JSP checks for a client authentication cookie. If the user is authenticated, in step  3337 , the user is redirected to the original RI. If no authentication cookie is found, in step  3331 , the authentication JSP checks for the client authentication preference cookie. If no authentication cookie is found, in step  3332 , the user is allowed to select an authentication method and the preference cookie is set. Then, or if an authentication cookie was found in step  3331 , the client is redirected to the proper authentication method in step  3333 . In step  3334 , the user browses to the location for performing authentication and, in step  3335 , the user&#39;s credentials are requested. If the user is valid, in step  3336 , a cookie is set and the user is redirected to the original RI, in step  3337 . If the user is not valid, it is determined in step  3338  if the user&#39;s authentication is pending. If so, in step  3340 , access is denied, but only pending confirmation by the issuer of the permit (e.g., which might occur after authenticating the subject using non-secret information). In step  3338 , if the user&#39;s authentication is not pending, it is determined if the user has been issued a delegation. If not, in step  3341 , the process fails because, in the preferred embodiment, the user cannot register unless he has been delegated a permit. If the user has been delegated a permit, in step  3342 , the user is granted an unconfirmed status pending confirmation. The permit issuer must confirm the user before the user is allowed to continue.  
     [0047]FIGS. 4A through 4Y illustrate exemplary user interfaces that may be used to access the functionality of the inventive system. In particular, an initial user of the system (e.g., a system administrator), who has authenticated to the system and is authorized to access a super-set of applications within the system, logs in using interface  401  shown in FIG. 4A. FIG. 4B shows an exemplary permit  402  delegated to the system administrator, indicating that the permission is from the system; to the system administrator; grants permission to access all administrative aspects of the system; the date of issuance; and dates of validity. Using permit  402 , the system administrator can view data, delegate a permit to another, or access the account manager. Assuming the system administrator desires to delegate a permit, he will be directed (either from permit  402  or from a page from which delegations can be made or from some other entry point) to a series of interfaces  4001 ,  4002 ,  4003 ,  4004 , and  4005 , shown in FIG. 4C. Using interface  4001 , the system administrator can identify the subject of the permit (i.e., the delegates) by way of, for example, an electronic mail address. The subject can be chosen from an address book or list of contacts  4010 . Using interface  4002 , the user may select the permit on which the delegation will be based, if the user has more than one permit that is relevant to the resource in question. Using interface  4003 , the issuer may indicate whether further delegation of the permit is to be limited in any way. For example, the issuer may indicate that the permit may only be subsequently delegated by the subject five times (a horizontal limitation). Further, the issuer may indicate that the length of the delegation chain cannot exceed one (meaning that the subject of this particular permit may further delegate to others access to the data that is the subject of the permit, but may not delegate to such others the ability to further delegate). The vertical limitation must be set to 1 or more if the horizontal limit is to apply. The issuer may further indicate a validity period and, in connection therewith, the relevant time zone. Using interfaces  4004  and  4005 , the issuer may provide a secure message to be sent along with the permit and attach any files to the permit. Upon sending the permit, the system administrator may be sent a return message, confirming that the permit was successfully transmitted.  
     [0048] The recipient of the permit from the system administrator may then further delegate the permission (if authorized to do so in his permit) to others. FIG. 4D illustrates an exemplary permit  413  received from the system administrator. Using permit  413 , the user may view the data (i.e., application) that is the subject of the permit; delegate the permit to others; and view any secure messages or files attached to permit  413 .  
     [0049] A user to whom a permission has been delegated, may further delegate the permission by way of the exemplary interfaces shown in FIGS.  4 E- 4 H. Interface  404  of FIG. 4E allows a user to register, providing his name, electronic mail address and preferred method of authentication. The user may also change his identification preferences, using interface  405  of FIG. 4F. A variety of different authentication modalities are supported such as, by way of example and not limitation, digital certificates, passwords, smart cards, and biometrics. Other forms of authentication modalities will be known to those skilled in the art and are within the scope of the present invention. In the preferred embodiment, the system administrator determines what forms of authentication are acceptable and includes modules for accommodating the same in authentication/authorization server  103 . If the user chooses to identify himself using a certificate, referring to FIG. 4G and interface  406 , the user may, in some embodiments, create a new certificate for use in authenticating himself to the system or may register an existing certificate. Upon the certificate being successfully generated, a message will be displayed to the user, confirming the same. Alternatively, as shown in FIG. 4H, the user may create a password using interface  407 .  
     [0050] With reference to FIG. 41, the system administrator may, using interface  408 , check the status of other users of the system (e.g., unregistered, pending, confirmed, disabled, revoked) and may change the status of any such user (i.e., revoke any permissions delegated to the user or disable his registration status). Only system users with authorization to do so may change the confirmation state of other users in the system, except that any user who delegates a permit has the power to revoke that permit using the account manager. Allowing revocation of access immediately and at any time may be very valuable in certain circumstances.  
     [0051] Returning again to FIG. 4B, using the account manager feature, the system administrator may perform a variety of activities. A user may view and manage permits received and sent, using interface  409 , as shown in FIG. 4J. For example, from interface  410  of FIG. 4K, a user may obtain access to permits sent by that user, including detail regarding the permit, as shown in FIG. 4L. Using interface  411  of FIG. 4M, a user may view information regarding permits received. Referring again to interface  409  of FIG. 4J, a user may elect to view and change his preferences. For example, with reference to FIG. 4N and interface  412 , a user may view and change his first and last name, electronic mail address, and method of identification.  
     [0052] Referring to FIG. 4O, and interface  415 , an authorized user may take advantage of the functionality of the system manager. Interface  416  of FIG. 4P allows a user to configure system parameters, such as the domain of the servers that are used to support the system; the RIs to which a user is directed for authentication, account manager, system manager, and delegation activities, as well as for accessing a permit delegated to the user; the address of the electronic mail server; whether attachments may be appended to delegations and where such attachments will be stored; and any default messages included with delegated permits. The authority to access and make changes to system parameters may also be further delegated using interface  416 . In other embodiments, this functionality can be accessed external to system  100 .  
     [0053] Interface  415  of FIG. 4O may also be used to access the user manager, as illustrated in interface  417  of FIG. 4Q. A user may find any other user who is registered with the system using interface  417  and obtain, using interface  418  of FIG. 4R, more detail about such other user&#39;s confirmation state, last login, and last access to the system. From interface  418 , the user may obtain access to an authentication log (identifying records for the other user&#39;s login attempts shown in interface  419  of FIG. 4S) and to an authorization log (identifying records for the other user&#39;s application accesses shown in interface  420  of FIG. 4T). This auditing capability allows for the tracking, and reporting if necessary, of which users delegated access, the applications to which access was delegated, which users accessed applications, and when such access occurred. Auditing, and other administrative functions, are available to users with regard to permissions such users have delegated.  
     [0054] Interface  415  of FIG. 4O may also be used to access application manager, allowing a user to configure applications accessible via the system. Initially, it is necessary to provide one or more users (e.g., the system administrator) with full access to all features of the configured application. Upon registering an application, a unique identifier will be created by database  110  and assigned to the application (as illustrated in FIG. 2). Then, the application can be configured such that the RIs that make up the application are split into one or more resource groups. Each resource group has a set of parameters that can be used to determine authorization (i.e., that control access to the data displayed by the resource). For example, the resource parameters for the resource  
     [0055] http://www.some_domain.com/someApp?Id= 1 &amp;View=All  
     [0056] are “ID” and “View”. All items in a particular resource group must be able to handle all of the resource group parameters as input. All resource parameters are not necessarily required for authorization. The resource parameters may be set at one of several levels of importance, such as required, optional-limiting (parameter is optional unless it exists in the delegation; then it must exist in the request), and optional-enabling (parameter is optional unless it does not exist in the delegation; then it must not exist in the request). Parameters may also be configured with a comparison operations (including but not limited to equals, greater than, less than, greater than or equal to, less than or equal to).  
     [0057] Referring to FIG. 4U, interface  421  allows a user to change properties of applications existing on the system and add new applications. A user may also delegate to others the ability to change application properties or add new applications using interface  421 . For example, with reference to FIG. 4V, and an application named “Inquiry”, the user may identify the name of the group to which the application belongs and identify the resource group RIs and resource group parameters corresponding to the application. With reference to FIG. 4W, the user may view the RIs corresponding to the resource group for the identified application and add new RIs to the list. With reference to FIG. 4X, the user may insert resource group parameters for the application, including the name of the parameter, its condition, and any expression relating thereto. Two exemplary resource group parameters are shown with reference to FIG. 4Y.  
     [0058] For the application identified in FIG. 4V, the delegation tree may be initialized (i.e., pursuant to which the administrative user delegates access to the first user).  
     [0059] With reference to FIG. 5A, a flow chart illustrating a preferred embodiment of the method of the present invention is shown. In step  502 , an administrative user, who is authorized to delegate a permission to a first user to access an application, authenticates to a server. In step  504 , a request is received at the server from the administrative user to delegate to the first user a first permission to access at least a portion of the application. In step  505 , the administrative user delegates to the first user a permit. FIG. 5B illustrates an exemplary electronic mail message in which the administrative user sends to the first user a permit pertaining to the subject data. Upon clicking on the permit icon  550 , the first user may be shown the details of the permit, in the preferred embodiment, as illustrated in FIG. 5C.  
     [0060] However, as can be seen in FIG. 5C, the first user must register with the system and authenticate himself to the server prior to gaining access to the information. Thus, in step  506 , the server receives a request from the first user to register with the server. Upon the first user seeking to register himself in connection with the permit received, in the preferred embodiment, the administrative user is sent an electronic mail message, indicating the same and informing the administrative user that he must authenticate the first user. An example of an electronic mail message of this sort is illustrated in FIG. 5D. In step  508 , the administrative user authenticates the first user with non-secret information. This may occur by way of a telephone call, for example, where the administrative user knows the telephone number and voice of the first user. This confirmed registration technique is particularly advantageous because it allows for secure authentication without the need for passwords or other secret information to be passed between the issuer and subject of a permission. During this call, the administrative user confirms that the first user received a delegation from the administrative user. In some embodiments, in step  507 , the server transmits to the first user a confirmation identifier upon the user registering with the system. The confirmation identifier is used as an additional item of authentication information, thereby providing added security to the system. Upon authenticating the first user, in the preferred embodiment, the administrative user follows the link  560  of FIG. 5D to confirm the permit. Upon confirming the permit, the first user is informed of the same and, in step  510 , the first user is provided access to the application by way of the permit (shown, for example, in FIG. 5E). Steps  502 ,  504 ,  505 ,  506 ,  507  and  510  are performed over a computer network, such as the Internet.  
     [0061] In some embodiments, in step  512 , the administrative user audits access of the first user to the application (as shown in FIGS. 4S and 4T). In still other embodiments, in step  514 , the administrative user terminates access of the first user to the application (using, for example, interface  408  of FIG. 41).  
     [0062] In some embodiments, the first permission also includes permission to delegate a subsequent permission (based on the first permission) to a second user. For example, with reference to FIG. 5E, the first user may choose delegation button  570  on his permit to delegate further access. In these embodiments, in step  516 , the server receives a request from the first user to delegate the subsequent permission to the second user. In step  518 , the second user registers with the server. In step  520 , the first user authenticates the second user with non-secret information. In step  522 , the second user is provided access to the application. Steps  516 ,  518 , and  522  are performed over a computer network, such as the Internet.  
     [0063] In certain embodiments, the delegation from one user to a second user can be specialized in terms of the limits placed on the delegation. For example, with reference to FIG. 6, in step  602 , a first user delegates to a second user permission to access an application. In step  604 , in connection with the delegation, an access control list is appended with the identity of the first user (the issuer); the identity of the second user (the subject); the identity of the application to which access is delegated; and a limitation on the number of further delegations the second user can make and, in some cases, a limitation on the length of the delegation chain (as shown in table  234  of FIG. 2). In step  606 , upon authenticating the second user, the second user is provided with access to the application.  
     [0064] While the invention has been described in detail and with reference to specific embodiments thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope thereof. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.