Title of Invention	A HIGH PERFORMANCE AUTHENTICATION SERVER
Abstract	The invention relates to a system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component.

Title of Invention

A HIGH PERFORMANCE AUTHENTICATION SERVER

Abstract

The invention relates to a system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component.

Full Text	DEC 2006 iMM^L4^SH^ FORM 2 THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION (Section 10; rule 13) 1. TITLE OF THE INVENTION: "A HIGH PERFORMANCE AUTHENTICATION SERVER" 2. APPLICANT (S) (a) Name : Tata consultancy Services Ltd. (b) Nationality: An Indian Company. (c) Address : Air India Building, 11th floor, Nariman Point, Mumbai - 400 021 3. PREAMBLE TO THE DESCRIPTION The following specification particularly describes the invention and the manner in which it is to be performed. FIELD OF THE INVENTION The invention relates to a high performance Authentication Server for open systems.. More particularly the present invention relates to High Performance Authentication Server that is capable of handling and processing twenty file thousand authentication requests per second; and also scalable up to more than ten million user profiles. DEFINITIONS: As used in this specification the following words are generally intended to have a meaning as set forth below, except to the extent that the context in which they are used indicate otherwise. "Proxy server": A proxy server is a computer that offers a computer network service to allow clients to make indirect network connections to other network services. A client connects to the proxy server, then requests a connection, file, or other resource available on a different server. The proxy provides the resource either by connecting to the specified server. In some cases, the proxy may alter the client's request or the server's response for various purposes. "LDAP" (Lightweight Directory Access Protocol): In computer networking, the Lightweight Directory Access Protocol, or LDAP ("ell-dap"), is a networking protocol for querying and modifying directory services running over TCP/IP. An LDAP directory usually follows the X.500 model: it is a tree of entries, each of which consists of a set of named attributes with values. While some services use a more complicated "forest" model, the vast majority use a simple starting point for their database organization. An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Further into the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry, or multiple entries. 2 "API" (Application programming interface): An application programming interface (API) is the interface that a computer system, library or application provides in order to allow requests for services to be made of it by other computer programs, and/or to allow data to be exchanged between them "Authentication servers": are servers that provide authentication services to users or other systems. Users and other servers authenticate to such a server, and receive cryptographic tickets. These tickets are then exchanged with one another to verify identity. Authentication is used as the basis for authorization (determining whether a privilege will be granted to a particular user or process), privacy (keeping information from becoming known to non-participants), and non-repudiation (not being able to deny having done something that was authorized to be done based on the authentication). BACKGROUND OF THE INVENTION Directory services for computer networks have been around for several years. When the Internet became popular, it was necessary to create a way to locate organizations, individuals, and other resources such as files and devices in a network, whether on the Internet or a corporate network. This information may need to be retrieved even without knowing a domain name, Internet Protocol (IP) address, or geographic location. In a typical LDAP network, there is a node (computer) designated as the master. The LDAP server may run on this master node, in which case it is called the primary LDAP server. There are then many clients dispersed on many different nodes interacting with the LDAP server on the master node through an LDAP Application Program Interface (API). There is also typically another special node called the vice-master node, which acts as a backup for the master node in case of failure. The LDAP server on the vice-master node is called the secondary LDAP server. 3 When the LDAP. server on the master node fails (or the master node itself fails and brings the LDAP server down along with it), the vice-master is promoted to be the new master node. The secondary LDAP server is then promoted to be the primary LDAP server in the network. The data managed by the different instances of LDAP servers (primary and secondary) must be consistent. Though different LDAP server instances may be acting as the primary LDAP server, a modification performed by the primary LDAP server must be immediately available to the secondary LDAP server, in case the primary LDAP server fails just after the modification takes place. The typical solution to this problem is to configure the primary and secondary LDAP serves to use a master-master replication if one is available. However, the replication in this case is not strong, in that the updates on one LDAP server are not guaranteed to be available immediately on the other LDAP server. The Authentication Servers (LDAP servers) used at present have limitations in that they do not scale beyond certain number of users, typically few millions. The existing Severs can process only 2500 to 3000 search requests per seconds Such servers are referred to as lightweight Directory Access Protocol' or LDAP authentication Severs. PRIOR ART In US 6,347,312 a method of hierarchical LDAP searching in an LDAP directory service having a relational database management system (DBMS) as a backing store is disclosed. The method begins in response to a search query to the relational database. Search results retrieved in response to the search query are cached, preferably in a pair of caches in the directory service. The first cache receives a set of identifiers indexed by a filter key of the search query. The search results, namely entries corresponding to the set of identifiers, are then stored in the second cache. In response to subsequent issuance of the search query, the cached search results are 4 then used in lieu of accessing the relational database to increase search efficiency. To maintain the integrity of the cached information, routines are provided to invalidate the caches during given directory service operations. In US 6,973,463 a directory server includes a supplier server, a consumer server in communication with the supplier server, a plurality of pluggable services that manage replication of data contained within the directory server from the supplier server to the consumer server, and a change log maintained on the consumer server of data replicated to the consumer server. The replication of data is managed by the plurality of pluggable services using the change log. In US 6,513,061 the proxy server selecting unit (corresponding to the foregoing dynamic DNS server) is provided to manage the location information and the load condition of the proxy servers distributively located on the network, when notifying a client of the address of the server for the domain name inquired by the client, select the most approximate proxy server to the client based on the location information of the client and the managed content, and notify the client of the address of the selected proxy server. In US 7,016,897 A method, program and system for authenticating LDAP referral searches are provided. The invention comprises receiving a bind request from a LDAP referred search request and then searching the local directory for an entry corresponding to the distinguished name (DN) of the bind request. If an entry for the bind DN is located within the local directory, the bind request is authenticated. If an entry for the bind DN is not found in the local directory, a defined reference server is checked for the prefix of the bind DN. If the prefix for the bind DN is located in the reference server, the reference server is contacted for authentication, which is performed using a root DN. If an entry for the bind DN is not found in either the local directory or reference server, the bind request cannot be authenticated and is denied. In US 7,082,297 a method for performing authentication in a communication system comprising an authentication server, and a user profile store storing user profiles for users of the communication system is disclosed. The method comprises 5 transmitting from the authentication server to the user profile store a request for the user profile of a user; receiving at the authentication server a response to the request; determining whether the response is indicative of an error; and if the response is indicative of an error, transmitting from the authentication server to the user profile store a message of a type such as to trigger the user profile store to perform a location update procedure in respect of the user. In US 7,107,355 Management of lightweight directory access protocol (LDAP) service may be accomplished through the use of remote mirroring and a unique application program interface (API). Both a primary and a secondary LDAP server are maintained. Any modification to the primary LDAP server is then mirrored on the secondary LDAP server. When a call is attempted on the primary server, if it fails, the call is retried on the secondary LDAP server. The API allows for specialized grammar for commands that permits the system to handle primary (and secondary) LDAP server failure. Therefore the objective of the present invention is to provide a solution for an application that have millions of users and need to support thousands of user authentication requests per second. Another object of the present invention is to provide an authentication server which is scalable up to more than fifty million user profiles. BRIEF DESCRIPTION OF THE DRAWINGS The invention is explained by referring to the following drawings: FIGURE 1 is a block diagram showing architecture of server and proxy without LDAP support FIGURE 2 is a block diagram showing architecture of server and proxy with LDAP support FIGURE 3 is a detailed block diagram showing multi node deployment architecture 6 FIGURE 4 is a detailed block diagram showing internal components of the main Authentication Engine of the Authentication Server. FIGURE 5 is a block diagram showing working of the Health Checker process of the server. FIGURE 6 is a detailed block diagram showing internal working/components of the Session Controller process of the server. FIGURE 7 is a detailed block diagram showing internal working/components of the GATEPASS Proxy. DETAILED DESCRIPTION OF THE INVENTION Embodiments of the present invention are described herein in the context of a system of computers, servers, and software. Those of ordinary skill in the art will realize that the following detailed description of the present invention is illustrative only and is not intended to be in any way limiting. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the present invention as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts. In the interest of clarity, not all of the routine features of the implementations described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure. 7 The inventor has adopted a self conceived and designed name "GATEPASS" for addressing the present invention (Authentication Server). Therefore any reference in the specification as "GATEPASS" should be treated as the present invention (Authentication Server or High Performance Authentication Server) The present invention will now be described with reference to drawings. Referring to FIG. 1, architecture of server and proxy without LDAP support also called standard "GATEPASS" configuration. The "GATEPASS" Proxy provides two different versions, with LDAP Support and without LDAP support. The LDAP is a standard light weight directory access protocol. The "GATEPASS" server or Authentication Server consists of three different processes, Authentication Engine (AE), Health Checker (HC) and Session Controller(SC).The Authentication Engine (AE)(101) process implements the caching and authentication logic, and it is the main process of the "GATEPASS" server, one or more instances of the AE process can be run on single "GATEPASS" server or. The Health Checker (HC) (102), the process that is responsible for controlling and monitoring the health of the AE and SC processes. The Session Controller (SC) (103), the process that is responsible for maintaining the session information for the logged in users. The "GATEPASS" Proxy or Authentication Server Proxy (ASP) (104) is a library component that gets loaded into the client process that can be Web Server process (107) as shown in the diagram. The ASP emulates the APIs provided by "GATEPASS" server, hence it called the Proxy. The ASP consists of the Router Table (RT) (105) and Connection Pool (CP) (106) components that implements the logic required to failover from one server to another and also of making remote method (API) call on the server. [108-Servlet]. Referring to FIG. 2, gives the schematic of the "GATEPASS" LDAP Wrapper architecture. The "GATEPASS" LDAP Wrapper (GPLW) (201) is an independent process that consists of LDAP Wrapper and ASP components. The GPLW provides the 8 The inventor has adopted a self conceived and designed name "GATEPASS" for addressing the present invention (Authentication Server). Therefore any reference in the specification as 'GATEPASS" should be treated as' the present invention (Authentication Server or High Performance Authentication Server) . The present invention will now be described with reference to drawings. Referring to FIG. 1, architecture of server and proxy without LDAP support also called standard "GATEPASS" configuration. The "GATEPASS" Proxy provides two different versions, with LDAP Support and without LDAP support. The LDAP is a standard light weight directory access protocol. The "GATEPASS" server or Authentication Server consists of three different processes, Authentication Engine: (AE), Health Checker (HC) and Session Controller(SC).The Authentication Engine (AE)(101) process implements the caching and authentication logic, and it is the main process of the "GATEPASS" server, one or more instances of the AE process can be run on single "GATEPASS" server or. The Health Checker (HC) (102), the process that is responsible for controlling and monitoring the health of the AE and SC processes. The Session Controller (SC) (103), the process that is responsible for maintaining the session information for the logged in users. The "GATEPASS" Proxy or Authentication Server Proxy (ASP) (104) is a library component that gets loaded into the client process that can be Web Server process (107) as shown in the diagram. The ASP emulates the APIs provided by "GATEPASS" server, hence it called the Proxy. The ASP consists of the Router Table (RT) (105) and Connection Pool (CP) (106) components that implements the logic required to failover from one server to another and also of making remote method (API) call on the server. [108 - Servlet]. Referring to FIG. 2, gives the schematic of the "GATEPASS" LDAP Wrapper architecture. The "GATEPASS" LDAP Wrapper (GPLW) (201) is an independent process that consists of LDAP Wrapper and ASP components. The GPLW provides the 8 interpretation service for "GATEPASS" APIs, it translate the LDAP client API calls into the GATEPASS proprietary APIs. The GPLW provides the standard LDAP APIs that can be used by any standard LDAP client. The "GATEPASS" is not a full-fledged LDAP server or directory server; it is a high performance authentication server that also supports the LDAP APIs specific to authentication, for easier integration with LDAP client. The LDAP Wrapper component implements all the LDAP API wrappers, which internally calls the "GATEPASS" APIs provided by the ASP. The numbers in the figure no. 1 are kept constant for brevity and convenience. [202 - Web servers] Referring to Figure 3, which is detailed block diagram showing multi node deployment architecture, which displays "GATEPASS" multi node deployment for a web application. 301 - Node configuration 302 - RDBMS 303 - Web server The "GATEPASS" can be used as one plus one or one plus N node configuration (301) for high availability architecture. All "GATEPASS" node share one common RDBMS database (302) to store the user profile data. Referring to FIGURE 4 is a detailed block diagram showing internal components of the Authentication Engine process of the "GATEPASS" server. Authentication Engine process implements two different type of in-memory Data Store (imDS) or caching, imDS-A(401) and imDS-B(402). The imDS-A (401) and imDS-B (402) are high performance caching engine, used to cache the data required for user authentication. On server restart the "GATEPASS" server process loads the user profile information into imDS from the existing data file or it can create a new data file from the RDBMS database. 9 The diagram below depicts the major components of the Authentication Engine process, besides imDS there is a Receiver(403), Sender(404), Queue Manager(405), Master Controller(406), Synchronizer(407), DB Replicator(408), Schema Manager(409), Logger(410) and Configuration Manager(411). Each component functioning is explained in detail below: imDS The imDS-A (401) is designed to optimize the search and update request only, it is ideal for user group that does not allow online addition of new user. It requires server restart after addition of new users to make them active. The imDS-B (402) is designed to optimize the search, update and insert request, unlike imDS-A, it does not restrict the online addition of new user in a group. The "GATEPASS" server allows creating multiple instances of imDS-A and imDS-B in single server process. Receiver The Receiver (403) is the main listener thread of the GATEPASS server process that receives the request from the "GATEPASS" Proxy. The Receiver (403) writes the entire incoming request in to the Receiver-Q. The Receiver-Q is the operating system IPC Q. Sender The Sender (404) read the message from the Sender-Q and sends it to the appropriate "GATEPASS" proxy. Queue Manager The Queue manager (405) Component is responsible for managing the IPC queues. It is a utility component for the Server process that provides the functionality such as create Q, delete Q, read Q and Write Q. 10 Master Controller The Master Controller (406) reads the request from the Receiver-Q and*:directs the request to the appropriate imDS for further processing. On receiving the response from the imDS, it writes the response into the Sender-Q. Synchronizer When ever there is an update in the user profile information for example password change, the imDS will log the change in the transaction log, on successful write in the transaction log, it will update the imDS followed by a profile-update message in to the Synch-Q. The Synchronizer (407) will pick the message from the Synch-Q and will publish it to all the subscriber nodes. The subscriber node will also log the change in its own transaction log followed by an update in imDS. This is an online synchronization protocol for replicating the changes across the nodes. In case of the offline mode, all nodes will be connected to common disk system, where in they keep their data files and transaction log file. In this case the synchronizer (407) will read the transaction log file of each node at periodic time interval of X seconds (the same is configurable parameter in server configuration file) and update its transaction log and imDS. DB Replicator The DB Replicator (408) thread will read the transaction log file periodically, from where it left last time and update the database accordingly. The read frequency can be configured using the configuration file. The DB Replicator (408) help keeps the database in synch with the data in transaction log file and appropriate imDS. Schema Manager The Schema Manager (409) manages different Schema Files and provides APIs to read the Schema File. The "GATEPASS" support one or more Schema File within a single server instance: Each Schema file is attached with a particular imDS; this mapping is always one to one. The Schema File provides flexibility to add or delete fields into the user profile. The Schema File is very similar to RDBMS table structure. 11 It is possible to map a User Schema with the table in database; it allows mapping each field in the schema file with the column in a table. The User Schema is also used to define what fields to be cached into imDS. This can be configured at the field level. The sample of the User Schema is as given below: [FIELD-1] FName = UserlD [Field Name] IsSameAs = [Indicate if the filed is same as other] FType = char [Field Type] FLength = 10 [Field Length] MinLen = 6 [Minimum length of the field] InMem = true [Indicate if the field needs to be cached] Tbl-Col = reg_user.User_Id_Pk [Indicate the mapping to table column name] Logger The Logger (410) is a separate library that is common in all components of the "GATEPASS", the server and proxy. The Logger allows logging the message with different log level. The "GATEPASS" keeps a detailed log file that keeps track of all the activities performed by the server, for example login, logout, password change, password reset etc Configuration Manager (411) The GATEPASS uses standard INI file as a configuration file, which can be used to configure almost all the features of the server. The following is list of features that are configurable: • Health Checker and Auth-Server port • Log level • Mapping between the User Schema and imDS type 12 • Select the Replication type online or offline , • Define Publisher/ Sub Scriber • DB Replicator • Switch on/off Replication process • Switch on/off the DB replication process Referring to FIGURES, which is a block diagram showing working of the Health Checker process of the server. The Heath Checker (HC) (502) is "GATEPASS" server component that creates, controls and monitors the Authentication engine and Session Controller (SC) processes. The HC creates one or more instance of Authentication engine (AE) process based on the heath checker configuration. The Health Checker (502) is a parent process of the GATEPASS server; it creates and manages the one or more instance of the authentication engine process (501) and session controller process. It continuously keeps track of the health of the Authentication Engine and Session Controller (503) server processes. In case of any failure of these processes, the Heath Checker (HC) (502) can restart them automatically. When ASP starts, first it performs handshake with the Heath Checker (HC) and request HC to provide information about the status and user range served by the Authentication Engine and status of the Session Controller process. The Health Checker (HC) knows how many instances of the Authentication Engine processes are running, what range of users are served by different server process, the listener port and the status of the server process. The Heath Checker (HC) provides facility to retrieve this information locally or remotely by publishing standard APIs for the same. [504 - Proxy Listener; 505-Proxy monitor] Different services provided by the Health Checker: † Creates control one or more Authentication Server (AS) processes † Creates and control the Session controller (SC) process † Monitors the status of Authentication Engine (AE) and Session controller (SC) processes † Restarts the Authentication Engine (AE) and Session controller (SC) process if it is 13 down, its optional feature Heath Checker (HC) Provides the following information to external entity such as ASP - Authentication Engine (AE) and Session controller (SC) listener port - Authentication Engine (AE) and Session controller (SC) status ' - User range supported by different Authentication Engine (AE) instance And referring to FIGURE 6, which is a detailed block diagram showing internal working/components of the Session Controller process of the server. 601 - Listener thread 602 - Session Monitor thread 603 - Session data store 604 - Session synchronizer thread 605 - SyncQ used for synchronization 606 - Web server; 607 - Authentication Proxy and 608 - Gatepass Server 2 - not explained but only shown diagrammatically. The Session Controller (SC) is a separate process and part of the GATEPASS server side process. The Session Controller (SC) is also multi-threaded high performance process. There can be only two Session Controller SC processes running in the multi-node GATEPASS installation. The one Master and other Slave SC running on two different nodes in multi node setup. The Session Controller (SC) uses its own imDS to store the session objects, this in-memory data store is optimized data-structure to support high rate of inserts and query. The Session Controller (SC) has its own components to synchronize session information between master and slave servers. The active Session Controller (SC) process is called Master SC, while the stand by Session Controller (SC) processes is known as Slave Session-Controller (SC). The Auth-Proxy connects to both SC and mark the first one as Master and other one as Slave. The ASP also has capability to fail over between the Session Controller (SC). 14 The main job of Session Controller (SC) is to manage the session information for the "GATEPASS" server. It stores the User ID, Proxy ID and Time information into its session object. It allows resetting session created from particular Proxy, while the session time out feature is provided as optional. Referring to Figure 7, The "GATEPASS" Proxy is the client side component, the client process that wants to use "GATEPASS" server uses APIs provided by the proxy. The "GATEPASS" Proxy encapsulates the logic required to make remote method calls and switching from one server to another in case of failure. The GATEPASS client can simply calls the APIs provided by the Proxy and need not worry about remote method calls and server fail over. The "GATEPASS" Proxy has three major components, AS Proxy (701), Router Table (702) and Connection Pool (703), besides the utility components such as Configuration Manager (704), Logger (705) and Schema Manager (706). AS Proxy (701) The Proxy components that provides the wrapper for all the APIs provided by the "GATEPASS" server. It performs the basic validations on the inputs; prepare the request message to be sent to the remote GATEPASS server. Once message is ready it checks out with the Router for the appropriate server to whom the message to be sent. At last it asks the connection pool to provide a free connection, use this connection to send request to the GATEPASS Server. It receives the response from the server on the same connection and provides that response back to the client. Router Table (702) The Router Table keeps the information about all the server nodes in a cluster. It stores the information such as ServerlD, Range of Users served, Status of the server, Role of the server (primary or secondary). The router table provides this complete information for the given user id. For each user id range router tables knows two alternate servers who are catering to that particular range. It keeps the track of the status of the server, so it knows if a particular server is up or down. On server 15 information request for the given user id, it will pass on the server having the online status only. Connection Pool (703) The connection pool component maintains multiple connections with each server node in a cluster. It keeps track of no of free and used connections, the total no of connection is configurable. It provides the free connection for the given server id, the client (Auth-Proxy component) need to implement its own wait logic, if none of the connection is free. The embodiments of the invention as described above and the methods disclosed herein will suggest further modification and alternations to those skilled in the art. Such further modifications and alterations may be made without departing from the sprit and scope of the invention, which is defined by the scope of the following claims. STATEMENT OF INVENTION The present invention therefore; A system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component. The in-memory data stores are imDS-A and imDS-B. The in-memory data stores are data structures that support high rate of inserts and queries. The said imDS-A optimizes the search and update request for user groups that does not allow online addition of new users. The said imDS-B optimizes the search, update and insert request that allows the online addition of new user in a group. 16 The Authentication Engine allows creating multiple instances of said imDS-A and imDS-B in single server process. In the present invention User ID, Proxy ID and Time information in a single session is managed by a Session controller. The present invention employs an Authentication LDAP server. The Authentication LDAP server component runs as separate process and uses the said authentication server Proxy library. It consists of LDAP Wrapper component that implements all the LDAP API wrappers. The Authentication server can be integrated with a tool for digital signature verification. The said Authentication Proxy stores information required to make remote method calls and switching from one server to another in case of failure. In the present invention at least 5000 requests are processed per second and further upto 25000 requests can be processed per second. The entire user profile is additionally stored in a disk. A system to perform authentication as per claim 1, wherein the operating system is 32 bit or 64 bit. The present invention also is A method for performing authentication in a system comprising an authentication engine process, a session controller process and a health checker process. The said authentication engine process the information required for authentication, is cached in plurality of in-memory data stores to process a huge magnitude of authentication requests per second. The authentication server caches only part of the data of the complete user profiles stored in a file on the disk to optimize memory usage. It allows defining or configuring the fields of the user profiles to be cached and the fields to be read from the disk. The said Session controller process the session information of the logged-in users is stored. 17 The session information between the master and slave servers is synchronized by the session controller. The said health checker process creates and manages one or more instance of the authentication engine process and session controller process. The said health checker process the information of the running processes of the authentication server, the listener port, the session controller and their status is stored. It process retrieves information locally or remotely by means of standard APIs. 18 We Claim: 1. A system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component. 2. A system to perform authentication as per claim 1, wherein the in-memory data stores are imDS-A and imDS-B. 3. A system to perform authentication as per claim 1, wherein, said imDS-A optimizes the search and update request for user groups that does not allow online addition of new users. r 4. A system to perform authentication as per claim 1, wherein said imDS-B optimizes the search, update and insert request that allows the online addition of new user in a group. 5. A system to perform authentication as per claim 1, wherein said Authentication Engine allows creating multiple instances of said imDS-A and imDS-B in single server process. 6. A system to perform authentication as per claim 1, wherein the in-memory data stores are data structures that support high rate of inserts and queries. 7. A system to perform authentication as per claim 1, wherein the User ID, Proxy ID and Time information in a single session is managed by a Session controller. 19 8. A system to perform authentication as per claim 1, wherein an Authentication LDAP server is used. 9. A system to perform authentication as per claim 8, said Authentication LDAP server component runs as separate process and uses the said authentication server Proxy library. 10. A system to perform authentication as per claim 8, said Authentication LDAP server consists of LDAP Wrapper component that implements all the LDAP API wrappers. 11. A system to perform authentication as per claim 1, wherein the said Authentication server is integrated with a tool for digital signature verification. 12. A system to perform authentication as per claim 1, wherein the said Authentication Proxy stores information required to make remote method calls and switching from one server to another in case of failure. 13. A system to perform authentication as per claim 1, wherein at least 5000 requests are processed per second. 14. A system to perform authentication as per claim 1, wherein upto 25000 requests are processed per second. 15. A system to perform authentication as per claim 1, wherein the entire user profile is additionally stored in a disk. 16. A system to perform authentication as per claim 1, wherein the operating system is 32 bit. 17. A system to perform authentication as per claim 1, wherein the operating system is 64 bit. 20 18. A method for performing authentication in a system comprising an authentication engine process, a session controller process and a health checker process. 19. A method as per claim 18, wherein in the said authentication engine.-process ' the information required for authentication, is cached in plurality of in-memory data stores to process a huge magnitude of authentication requests per second. 20. A method as per claim 18, wherein the authentication server caches only part of the data of the complete user profiles stored in a file on the disk to optimize memory usage. 21. A method as per claim 18, wherein the authentication server allows defining or configuring the fields of the user profiles to be cached and the fields to be read from the disk. 22. A method as per claim 18, wherein in the said Session controller process the session information of the logged-in users is stored. 23. A method as per claim 18, wherein the session information between the master and slave servers is synchronized by the session controller. 24. A method as per claim 18, wherein the said health checker process creates and manages one or more instance of the authentication engine process and session controller process. 25. A method as per claim 18, wherein in the said health checker process the information of the running processes of the authentication server, the listener port, the session controller and their status is stored. 26. A method as per claim 18, wherein the health checker process retrieves information locally or remotely by means of standard APIs. 21 27. A method as claimed in the claims above substantially such as herein described with reference to the accompanying drawings. 28. A system as claimed in the claims above substantially such as herein described with reference to the accompanying drawings. Dated this 1st day of November 2006 Anand Deshpande For DSK Legal Agent for Applicant 22

Full Text

DEC 2006 iMM^L4^SH^
FORM 2

THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Section 10; rule 13)

1. TITLE OF THE INVENTION:
"A HIGH PERFORMANCE AUTHENTICATION SERVER"
2. APPLICANT (S)
(a) Name : Tata consultancy Services Ltd.
(b) Nationality: An Indian Company.
(c) Address : Air India Building, 11th floor, Nariman
Point, Mumbai - 400 021
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION
The invention relates to a high performance Authentication Server for open systems.. More particularly the present invention relates to High Performance Authentication Server that is capable of handling and processing twenty file thousand authentication requests per second; and also scalable up to more than ten million user profiles.
DEFINITIONS:
As used in this specification the following words are generally intended to have a meaning as set forth below, except to the extent that the context in which they are used indicate otherwise.
"Proxy server": A proxy server is a computer that offers a computer network service to allow clients to make indirect network connections to other network services. A client connects to the proxy server, then requests a connection, file, or other resource available on a different server. The proxy provides the resource either by connecting to the specified server. In some cases, the proxy may alter the client's request or the server's response for various purposes.
"LDAP" (Lightweight Directory Access Protocol): In computer networking, the Lightweight Directory Access Protocol, or LDAP ("ell-dap"), is a networking protocol for querying and modifying directory services running over TCP/IP. An LDAP directory usually follows the X.500 model: it is a tree of entries, each of which consists of a set of named attributes with values. While some services use a more complicated "forest" model, the vast majority use a simple starting point for their database organization. An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the topmost levels of the hierarchy. Further into the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry, or multiple entries.
2

"API" (Application programming interface): An application programming interface (API) is the interface that a computer system, library or application provides in order to allow requests for services to be made of it by other computer programs, and/or to allow data to be exchanged between them
"Authentication servers": are servers that provide authentication services to users or other systems. Users and other servers authenticate to such a server, and receive cryptographic tickets. These tickets are then exchanged with one another to verify identity.
Authentication is used as the basis for authorization (determining whether a privilege will be granted to a particular user or process), privacy (keeping information from becoming known to non-participants), and non-repudiation (not being able to deny having done something that was authorized to be done based on the authentication).
BACKGROUND OF THE INVENTION
Directory services for computer networks have been around for several years. When the Internet became popular, it was necessary to create a way to locate organizations, individuals, and other resources such as files and devices in a network, whether on the Internet or a corporate network. This information may need to be retrieved even without knowing a domain name, Internet Protocol (IP) address, or geographic location.
In a typical LDAP network, there is a node (computer) designated as the master. The LDAP server may run on this master node, in which case it is called the primary LDAP server. There are then many clients dispersed on many different nodes interacting with the LDAP server on the master node through an LDAP Application Program Interface (API). There is also typically another special node called the vice-master node, which acts as a backup for the master node in case of failure. The LDAP server on the vice-master node is called the secondary LDAP server.
3

When the LDAP. server on the master node fails (or the master node itself fails and brings the LDAP server down along with it), the vice-master is promoted to be the new master node. The secondary LDAP server is then promoted to be the primary LDAP server in the network.
The data managed by the different instances of LDAP servers (primary and secondary) must be consistent. Though different LDAP server instances may be acting as the primary LDAP server, a modification performed by the primary LDAP server must be immediately available to the secondary LDAP server, in case the primary LDAP server fails just after the modification takes place.
The typical solution to this problem is to configure the primary and secondary LDAP serves to use a master-master replication if one is available. However, the replication in this case is not strong, in that the updates on one LDAP server are not guaranteed to be available immediately on the other LDAP server.
The Authentication Servers (LDAP servers) used at present have limitations in that they do not scale beyond certain number of users, typically few millions. The existing Severs can process only 2500 to 3000 search requests per seconds Such servers are referred to as lightweight Directory Access Protocol' or LDAP authentication Severs.
PRIOR ART
In US 6,347,312 a method of hierarchical LDAP searching in an LDAP directory service having a relational database management system (DBMS) as a backing store is disclosed. The method begins in response to a search query to the relational database. Search results retrieved in response to the search query are cached, preferably in a pair of caches in the directory service. The first cache receives a set of identifiers indexed by a filter key of the search query. The search results, namely entries corresponding to the set of identifiers, are then stored in the second cache. In response to subsequent issuance of the search query, the cached search results are
4

then used in lieu of accessing the relational database to increase search efficiency. To maintain the integrity of the cached information, routines are provided to invalidate the caches during given directory service operations.
In US 6,973,463 a directory server includes a supplier server, a consumer server in communication with the supplier server, a plurality of pluggable services that manage replication of data contained within the directory server from the supplier server to the consumer server, and a change log maintained on the consumer server of data replicated to the consumer server. The replication of data is managed by the plurality of pluggable services using the change log.
In US 6,513,061 the proxy server selecting unit (corresponding to the foregoing dynamic DNS server) is provided to manage the location information and the load condition of the proxy servers distributively located on the network, when notifying a client of the address of the server for the domain name inquired by the client, select the most approximate proxy server to the client based on the location information of the client and the managed content, and notify the client of the address of the selected proxy server.
In US 7,016,897 A method, program and system for authenticating LDAP referral searches are provided. The invention comprises receiving a bind request from a LDAP referred search request and then searching the local directory for an entry corresponding to the distinguished name (DN) of the bind request. If an entry for the bind DN is located within the local directory, the bind request is authenticated. If an entry for the bind DN is not found in the local directory, a defined reference server is checked for the prefix of the bind DN. If the prefix for the bind DN is located in the reference server, the reference server is contacted for authentication, which is performed using a root DN. If an entry for the bind DN is not found in either the local directory or reference server, the bind request cannot be authenticated and is denied.
In US 7,082,297 a method for performing authentication in a communication system comprising an authentication server, and a user profile store storing user profiles for users of the communication system is disclosed. The method comprises
5

transmitting from the authentication server to the user profile store a request for the user profile of a user; receiving at the authentication server a response to the request; determining whether the response is indicative of an error; and if the response is indicative of an error, transmitting from the authentication server to the user profile store a message of a type such as to trigger the user profile store to perform a location update procedure in respect of the user.
In US 7,107,355 Management of lightweight directory access protocol (LDAP) service may be accomplished through the use of remote mirroring and a unique application program interface (API). Both a primary and a secondary LDAP server are maintained. Any modification to the primary LDAP server is then mirrored on the secondary LDAP server. When a call is attempted on the primary server, if it fails, the call is retried on the secondary LDAP server. The API allows for specialized grammar for commands that permits the system to handle primary (and secondary) LDAP server failure.
Therefore the objective of the present invention is to provide a solution for an application that have millions of users and need to support thousands of user authentication requests per second.
Another object of the present invention is to provide an authentication server which is scalable up to more than fifty million user profiles.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention is explained by referring to the following drawings:
FIGURE 1 is a block diagram showing architecture of server and proxy without LDAP support
FIGURE 2 is a block diagram showing architecture of server and proxy with LDAP support
FIGURE 3 is a detailed block diagram showing multi node deployment architecture
6

FIGURE 4 is a detailed block diagram showing internal components of the main Authentication Engine of the Authentication Server.
FIGURE 5 is a block diagram showing working of the Health Checker process of the server.
FIGURE 6 is a detailed block diagram showing internal working/components of the Session Controller process of the server.
FIGURE 7 is a detailed block diagram showing internal working/components of the GATEPASS Proxy.
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention are described herein in the context of a system of computers, servers, and software. Those of ordinary skill in the art will realize that the following detailed description of the present invention is illustrative only and is not intended to be in any way limiting. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the present invention as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts.
In the interest of clarity, not all of the routine features of the implementations described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
7

The inventor has adopted a self conceived and designed name "GATEPASS" for addressing the present invention (Authentication Server). Therefore any reference in the specification as "GATEPASS" should be treated as the present invention (Authentication Server or High Performance Authentication Server)
The present invention will now be described with reference to drawings.
Referring to FIG. 1, architecture of server and proxy without LDAP support also called standard "GATEPASS" configuration. The "GATEPASS" Proxy provides two different versions, with LDAP Support and without LDAP support. The LDAP is a standard light weight directory access protocol.
The "GATEPASS" server or Authentication Server consists of three different processes, Authentication Engine (AE), Health Checker (HC) and Session Controller(SC).The Authentication Engine (AE)(101) process implements the caching and authentication logic, and it is the main process of the "GATEPASS" server, one or more instances of the AE process can be run on single "GATEPASS" server or. The Health Checker (HC) (102), the process that is responsible for controlling and monitoring the health of the AE and SC processes. The Session Controller (SC) (103), the process that is responsible for maintaining the session information for the logged in users.
The "GATEPASS" Proxy or Authentication Server Proxy (ASP) (104) is a library component that gets loaded into the client process that can be Web Server process (107) as shown in the diagram. The ASP emulates the APIs provided by "GATEPASS" server, hence it called the Proxy. The ASP consists of the Router Table (RT) (105) and Connection Pool (CP) (106) components that implements the logic required to failover from one server to another and also of making remote method (API) call on the server. [108-Servlet].
Referring to FIG. 2, gives the schematic of the "GATEPASS" LDAP Wrapper architecture. The "GATEPASS" LDAP Wrapper (GPLW) (201) is an independent process that consists of LDAP Wrapper and ASP components. The GPLW provides the
8

The inventor has adopted a self conceived and designed name "GATEPASS" for addressing the present invention (Authentication Server). Therefore any reference in the specification as 'GATEPASS" should be treated as' the present invention (Authentication Server or High Performance Authentication Server) .
The present invention will now be described with reference to drawings.
Referring to FIG. 1, architecture of server and proxy without LDAP support also called standard "GATEPASS" configuration. The "GATEPASS" Proxy provides two different versions, with LDAP Support and without LDAP support. The LDAP is a standard light weight directory access protocol.
The "GATEPASS" server or Authentication Server consists of three different processes, Authentication Engine: (AE), Health Checker (HC) and Session Controller(SC).The Authentication Engine (AE)(101) process implements the caching and authentication logic, and it is the main process of the "GATEPASS" server, one or more instances of the AE process can be run on single "GATEPASS" server or. The Health Checker (HC) (102), the process that is responsible for controlling and monitoring the health of the AE and SC processes. The Session Controller (SC) (103), the process that is responsible for maintaining the session information for the logged in users.
The "GATEPASS" Proxy or Authentication Server Proxy (ASP) (104) is a library component that gets loaded into the client process that can be Web Server process (107) as shown in the diagram. The ASP emulates the APIs provided by "GATEPASS" server, hence it called the Proxy. The ASP consists of the Router Table (RT) (105) and Connection Pool (CP) (106) components that implements the logic required to failover from one server to another and also of making remote method (API) call on the server. [108 - Servlet].
Referring to FIG. 2, gives the schematic of the "GATEPASS" LDAP Wrapper architecture. The "GATEPASS" LDAP Wrapper (GPLW) (201) is an independent process that consists of LDAP Wrapper and ASP components. The GPLW provides the
8

interpretation service for "GATEPASS" APIs, it translate the LDAP client API calls into the GATEPASS proprietary APIs. The GPLW provides the standard LDAP APIs that can be used by any standard LDAP client. The "GATEPASS" is not a full-fledged LDAP server or directory server; it is a high performance authentication server that also supports the LDAP APIs specific to authentication, for easier integration with LDAP client. The LDAP Wrapper component implements all the LDAP API wrappers, which internally calls the "GATEPASS" APIs provided by the ASP. The numbers in the figure no. 1 are kept constant for brevity and convenience. [202 - Web servers]
Referring to Figure 3, which is detailed block diagram showing multi node deployment architecture, which displays "GATEPASS" multi node deployment for a web application.
301 - Node configuration
302 - RDBMS
303 - Web server
The "GATEPASS" can be used as one plus one or one plus N node configuration (301) for high availability architecture. All "GATEPASS" node share one common RDBMS database (302) to store the user profile data.
Referring to FIGURE 4 is a detailed block diagram showing internal components of the Authentication Engine process of the "GATEPASS" server. Authentication Engine process implements two different type of in-memory Data Store (imDS) or caching, imDS-A(401) and imDS-B(402). The imDS-A (401) and imDS-B (402) are high performance caching engine, used to cache the data required for user authentication. On server restart the "GATEPASS" server process loads the user profile information into imDS from the existing data file or it can create a new data file from the RDBMS database.
9

The diagram below depicts the major components of the Authentication Engine process, besides imDS there is a Receiver(403), Sender(404), Queue Manager(405), Master Controller(406), Synchronizer(407), DB Replicator(408), Schema Manager(409), Logger(410) and Configuration Manager(411). Each component functioning is explained in detail below:
imDS
The imDS-A (401) is designed to optimize the search and update request only, it is ideal for user group that does not allow online addition of new user. It requires server restart after addition of new users to make them active. The imDS-B (402) is designed to optimize the search, update and insert request, unlike imDS-A, it does not restrict the online addition of new user in a group. The "GATEPASS" server allows creating multiple instances of imDS-A and imDS-B in single server process.
Receiver
The Receiver (403) is the main listener thread of the GATEPASS server process that receives the request from the "GATEPASS" Proxy. The Receiver (403) writes the entire incoming request in to the Receiver-Q. The Receiver-Q is the operating system IPC Q.
Sender
The Sender (404) read the message from the Sender-Q and sends it to the appropriate "GATEPASS" proxy.
Queue Manager
The Queue manager (405) Component is responsible for managing the IPC queues. It is a utility component for the Server process that provides the functionality such as create Q, delete Q, read Q and Write Q.
10

Master Controller
The Master Controller (406) reads the request from the Receiver-Q and*:directs the request to the appropriate imDS for further processing. On receiving the response from the imDS, it writes the response into the Sender-Q.
Synchronizer
When ever there is an update in the user profile information for example password change, the imDS will log the change in the transaction log, on successful write in the transaction log, it will update the imDS followed by a profile-update message in to the Synch-Q. The Synchronizer (407) will pick the message from the Synch-Q and will publish it to all the subscriber nodes. The subscriber node will also log the change in its own transaction log followed by an update in imDS. This is an online synchronization protocol for replicating the changes across the nodes. In case of the offline mode, all nodes will be connected to common disk system, where in they keep their data files and transaction log file. In this case the synchronizer (407) will read the transaction log file of each node at periodic time interval of X seconds (the same is configurable parameter in server configuration file) and update its transaction log and imDS.
DB Replicator
The DB Replicator (408) thread will read the transaction log file periodically, from where it left last time and update the database accordingly. The read frequency can be configured using the configuration file. The DB Replicator (408) help keeps the database in synch with the data in transaction log file and appropriate imDS.
Schema Manager
The Schema Manager (409) manages different Schema Files and provides APIs to read the Schema File. The "GATEPASS" support one or more Schema File within a single server instance: Each Schema file is attached with a particular imDS; this mapping is always one to one. The Schema File provides flexibility to add or delete fields into the user profile. The Schema File is very similar to RDBMS table structure.
11

It is possible to map a User Schema with the table in database; it allows mapping each field in the schema file with the column in a table. The User Schema is also used to define what fields to be cached into imDS. This can be configured at the field level.
The sample of the User Schema is as given below:
[FIELD-1]
FName = UserlD [Field Name]
IsSameAs = [Indicate if the filed is same as other]
FType = char [Field Type]
FLength = 10 [Field Length]
MinLen = 6 [Minimum length of the field]
InMem = true [Indicate if the field needs to be cached]
Tbl-Col = reg_user.User_Id_Pk [Indicate the mapping to table column name]
Logger
The Logger (410) is a separate library that is common in all components of the "GATEPASS", the server and proxy. The Logger allows logging the message with different log level. The "GATEPASS" keeps a detailed log file that keeps track of all the activities performed by the server, for example login, logout, password change, password reset etc
Configuration Manager (411)
The GATEPASS uses standard INI file as a configuration file, which can be used to configure almost all the features of the server. The following is list of features that are configurable:
• Health Checker and Auth-Server port
• Log level
• Mapping between the User Schema and imDS type
12

• Select the Replication type online or offline ,
• Define Publisher/ Sub Scriber
• DB Replicator
• Switch on/off Replication process
• Switch on/off the DB replication process
Referring to FIGURES, which is a block diagram showing working of the Health Checker process of the server.
The Heath Checker (HC) (502) is "GATEPASS" server component that creates, controls and monitors the Authentication engine and Session Controller (SC) processes. The HC creates one or more instance of Authentication engine (AE) process based on the heath checker configuration.
The Health Checker (502) is a parent process of the GATEPASS server; it creates and manages the one or more instance of the authentication engine process (501) and session controller process. It continuously keeps track of the health of the Authentication Engine and Session Controller (503) server processes. In case of any failure of these processes, the Heath Checker (HC) (502) can restart them automatically. When ASP starts, first it performs handshake with the Heath Checker (HC) and request HC to provide information about the status and user range served by the Authentication Engine and status of the Session Controller process. The Health Checker (HC) knows how many instances of the Authentication Engine processes are running, what range of users are served by different server process, the listener port and the status of the server process. The Heath Checker (HC) provides facility to retrieve this information locally or remotely by publishing standard APIs for the same. [504 - Proxy Listener; 505-Proxy monitor] Different services provided by the Health Checker:
† Creates control one or more Authentication Server (AS) processes
† Creates and control the Session controller (SC) process
† Monitors the status of Authentication Engine (AE) and Session controller (SC) processes
† Restarts the Authentication Engine (AE) and Session controller (SC) process if it is
13

down, its optional feature
Heath Checker (HC) Provides the following information to external entity such as
ASP
- Authentication Engine (AE) and Session controller (SC) listener port
- Authentication Engine (AE) and Session controller (SC) status '
- User range supported by different Authentication Engine (AE) instance
And referring to FIGURE 6, which is a detailed block diagram showing internal working/components of the Session Controller process of the server.
601 - Listener thread
602 - Session Monitor thread
603 - Session data store
604 - Session synchronizer thread
605 - SyncQ used for synchronization
606 - Web server; 607 - Authentication Proxy and 608 - Gatepass Server 2 - not explained but only shown diagrammatically.
The Session Controller (SC) is a separate process and part of the GATEPASS server side process. The Session Controller (SC) is also multi-threaded high performance process. There can be only two Session Controller SC processes running in the multi-node GATEPASS installation. The one Master and other Slave SC running on two different nodes in multi node setup. The Session Controller (SC) uses its own imDS to store the session objects, this in-memory data store is optimized data-structure to support high rate of inserts and query. The Session Controller (SC) has its own components to synchronize session information between master and slave servers.
The active Session Controller (SC) process is called Master SC, while the stand by Session Controller (SC) processes is known as Slave Session-Controller (SC). The Auth-Proxy connects to both SC and mark the first one as Master and other one as Slave. The ASP also has capability to fail over between the Session Controller (SC).
14

The main job of Session Controller (SC) is to manage the session information for the "GATEPASS" server. It stores the User ID, Proxy ID and Time information into its session object. It allows resetting session created from particular Proxy, while the session time out feature is provided as optional.
Referring to Figure 7, The "GATEPASS" Proxy is the client side component, the client process that wants to use "GATEPASS" server uses APIs provided by the proxy. The "GATEPASS" Proxy encapsulates the logic required to make remote method calls and switching from one server to another in case of failure. The GATEPASS client can simply calls the APIs provided by the Proxy and need not worry about remote method calls and server fail over.
The "GATEPASS" Proxy has three major components, AS Proxy (701), Router Table (702) and Connection Pool (703), besides the utility components such as Configuration Manager (704), Logger (705) and Schema Manager (706).
AS Proxy (701)
The Proxy components that provides the wrapper for all the APIs provided by the "GATEPASS" server. It performs the basic validations on the inputs; prepare the request message to be sent to the remote GATEPASS server. Once message is ready it checks out with the Router for the appropriate server to whom the message to be sent. At last it asks the connection pool to provide a free connection, use this connection to send request to the GATEPASS Server. It receives the response from the server on the same connection and provides that response back to the client.
Router Table (702)
The Router Table keeps the information about all the server nodes in a cluster. It stores the information such as ServerlD, Range of Users served, Status of the server, Role of the server (primary or secondary). The router table provides this complete information for the given user id. For each user id range router tables knows two alternate servers who are catering to that particular range. It keeps the track of the status of the server, so it knows if a particular server is up or down. On server
15

information request for the given user id, it will pass on the server having the online status only.
Connection Pool (703)
The connection pool component maintains multiple connections with each server node in a cluster. It keeps track of no of free and used connections, the total no of connection is configurable. It provides the free connection for the given server id, the client (Auth-Proxy component) need to implement its own wait logic, if none of the connection is free.
The embodiments of the invention as described above and the methods disclosed herein will suggest further modification and alternations to those skilled in the art. Such further modifications and alterations may be made without departing from the sprit and scope of the invention, which is defined by the scope of the following claims.
STATEMENT OF INVENTION
The present invention therefore; A system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component. The in-memory data stores are imDS-A and imDS-B. The in-memory data stores are data structures that support high rate of inserts and queries.
The said imDS-A optimizes the search and update request for user groups that does not allow online addition of new users. The said imDS-B optimizes the search, update and insert request that allows the online addition of new user in a group.
16

The Authentication Engine allows creating multiple instances of said imDS-A and imDS-B in single server process.
In the present invention User ID, Proxy ID and Time information in a single session is managed by a Session controller. The present invention employs an Authentication LDAP server. The Authentication LDAP server component runs as separate process and uses the said authentication server Proxy library. It consists of LDAP Wrapper component that implements all the LDAP API wrappers.
The Authentication server can be integrated with a tool for digital signature verification.
The said Authentication Proxy stores information required to make remote method calls and switching from one server to another in case of failure.
In the present invention at least 5000 requests are processed per second and further upto 25000 requests can be processed per second.
The entire user profile is additionally stored in a disk. A system to perform authentication as per claim 1, wherein the operating system is 32 bit or 64 bit.
The present invention also is A method for performing authentication in a system comprising an authentication engine process, a session controller process and a health checker process.
The said authentication engine process the information required for authentication, is cached in plurality of in-memory data stores to process a huge magnitude of authentication requests per second.
The authentication server caches only part of the data of the complete user profiles stored in a file on the disk to optimize memory usage. It allows defining or configuring the fields of the user profiles to be cached and the fields to be read from the disk.
The said Session controller process the session information of the logged-in users is stored.
17

The session information between the master and slave servers is synchronized by the session controller.
The said health checker process creates and manages one or more instance of the authentication engine process and session controller process.
The said health checker process the information of the running processes of the authentication server, the listener port, the session controller and their status is stored. It process retrieves information locally or remotely by means of standard APIs.
18

We Claim:
1. A system to perform authentication comprising an Authentication server and an authentication server proxy, said Authentication Server consisting of an Authentication Engine having plurality of in-memory data stores being implemented in the said Authentication Engine to cache the data required for user authentication, a Health Checker to monitor the health of the said Authentication Engine processes, a Session Controller to store the session information for the logged-in users, the said authentication server Proxy being a client side library component.
2. A system to perform authentication as per claim 1, wherein the in-memory data stores are imDS-A and imDS-B.
3. A system to perform authentication as per claim 1, wherein, said imDS-A optimizes the search and update request for user groups that does not allow online addition of new users.
r
4. A system to perform authentication as per claim 1, wherein said imDS-B optimizes the search, update and insert request that allows the online addition of new user in a group.
5. A system to perform authentication as per claim 1, wherein said Authentication Engine allows creating multiple instances of said imDS-A and imDS-B in single server process.
6. A system to perform authentication as per claim 1, wherein the in-memory data stores are data structures that support high rate of inserts and queries.
7. A system to perform authentication as per claim 1, wherein the User ID, Proxy ID and Time information in a single session is managed by a Session controller.
19

8. A system to perform authentication as per claim 1, wherein an Authentication LDAP server is used.
9. A system to perform authentication as per claim 8, said Authentication LDAP server component runs as separate process and uses the said authentication server Proxy library.
10. A system to perform authentication as per claim 8, said Authentication LDAP server consists of LDAP Wrapper component that implements all the LDAP API wrappers.
11. A system to perform authentication as per claim 1, wherein the said Authentication server is integrated with a tool for digital signature verification.
12. A system to perform authentication as per claim 1, wherein the said Authentication Proxy stores information required to make remote method calls and switching from one server to another in case of failure.
13. A system to perform authentication as per claim 1, wherein at least 5000 requests are processed per second.
14. A system to perform authentication as per claim 1, wherein upto 25000 requests are processed per second.
15. A system to perform authentication as per claim 1, wherein the entire user profile is additionally stored in a disk.
16. A system to perform authentication as per claim 1, wherein the operating system is 32 bit.
17. A system to perform authentication as per claim 1, wherein the operating system is 64 bit.
20

18. A method for performing authentication in a system comprising an
authentication engine process, a session controller process and a health
checker process.
19. A method as per claim 18, wherein in the said authentication engine.-process
' the information required for authentication, is cached in plurality of in-memory
data stores to process a huge magnitude of authentication requests per second.
20. A method as per claim 18, wherein the authentication server caches only part of the data of the complete user profiles stored in a file on the disk to optimize memory usage.
21. A method as per claim 18, wherein the authentication server allows defining or configuring the fields of the user profiles to be cached and the fields to be read from the disk.
22. A method as per claim 18, wherein in the said Session controller process the session information of the logged-in users is stored.
23. A method as per claim 18, wherein the session information between the master and slave servers is synchronized by the session controller.
24. A method as per claim 18, wherein the said health checker process creates and manages one or more instance of the authentication engine process and session controller process.
25. A method as per claim 18, wherein in the said health checker process the information of the running processes of the authentication server, the listener port, the session controller and their status is stored.
26. A method as per claim 18, wherein the health checker process retrieves information locally or remotely by means of standard APIs.
21

27. A method as claimed in the claims above substantially such as herein described with reference to the accompanying drawings.
28. A system as claimed in the claims above substantially such as herein described with reference to the accompanying drawings.
Dated this 1st day of November 2006

Anand Deshpande
For DSK Legal Agent for Applicant
22

A HIGH PERFORMANCE AUTHENTICATION SERVER

Documents:

Inventors:

PCT Conventions: