Enterprise authentication server

In a computer-implemented authentication method, a first authentication request from a first machine is received at an authentication server. The first authentication request includes an identification of a second machine that is to provide a requested service. An authentication token including client-specific and server-specific portions is generated at the authentication server, responsive to receiving the first authentication request from the first machine. An authentication identifier and the server-specific portion of the authentication token are transmitted from the authentication server to the second machine, responsive to receiving the first authentication request from the first machine. A second authentication request, including the authentication identifier and both the server-specific and the client-specific portions of the authentication token, is received at the authentication server from the second machine. An authentication status for the requested service is determined at the authentication server, responsive to receiving the second authentication request from the second machine.

BACKGROUND

The present disclosure relates generally to electronic devices, and more particularly, to authentication of electronic devices.

Enterprises and/or cloud environments typically include multiple systems and subsystems, and many of the systems may be integrated with each other. Point-to-point authentication in such systems may thus become tightly coupled, which may introduce problems with respect to time scalability, maintainability, and/or cost. For example, as the various systems having different configurations in an enterprise and/or cloud environment may lack common audit and/or logging capabilities, system accountability may not be transparent. Furthermore, with increasing system size, point to point authentication may become increasingly more time consuming.

SUMMARY

Some embodiments of the present disclosure are directed to a computer-implemented authentication method in which a first authentication request from a first machine is received at an authentication server. The first authentication request includes an identification of a second machine that is to provide a requested service. An authentication token including client-specific and server-specific portions is generated at the authentication server, responsive to receiving the first authentication request from the first machine. An authentication identifier and the server-specific portion of the authentication token are transmitted from the authentication server to the second machine, responsive to receiving the first authentication request from the first machine. A second authentication request including the authentication identifier, the server-specific portion of the authentication token, and the client-specific portion of the authentication token is received at the authentication server from the second machine. An authentication status for the requested service is determined at the authentication server, responsive to receiving the second authentication request from the second machine. The operations of the computer-implemented method are performed by at least one processor of the authentication server.

In some embodiments, the client-specific portion of the authentication token may not be transmitted to the second machine from the authentication server.

In some embodiments, the authentication identifier and the client-specific portion of the authentication token may be transmitted from the authentication server to the first machine, responsive to receiving the first authentication request. The second authentication request may be received from the second machine responsive to transmitting the client-specific portion of the authentication token to the first machine.

In some embodiments, the server-specific portion of the authentication token may not be transmitted to the first machine from the authentication server.

In some embodiments, a third authentication request including the authentication identifier may be received at the authentication server from the first machine, responsive to determining the authentication status. An acknowledgment including the authentication status may be transmitted from the authentication server to the first machine, responsive to receiving the third authentication request.

In some embodiments, an authentication response including the authentication status may be transmitted from the authentication server to the second machine, responsive to the determining of the authentication status. The third authentication request may be received from the first machine responsive to transmitting the authentication response to the second machine.

In some embodiments, in determining the authentication status, the server-specific and the client-specific portions of the authentication token received from the second machine in the second authentication request may be compared with the authentication token generated at the authentication server responsive to receiving the first authentication request. The authentication status may be determined as positive responsive to a match indicated by the comparing, and the authentication status may be determined as negative responsive to an absence of a match indicated by the comparing.

In some embodiments, the acknowledgment including the authentication status as positive may indicate authorization for the first machine to accept a response for the requested service from the second machine. The authentication response including the authentication status as positive may indicate authorization for the second machine to provide the response for the requested service to the first machine.

Further embodiments of the present disclosure are directed to a computer system including a processor and a memory coupled to the processor. The memory includes computer readable program code embodied therein that, when executed by the processor, causes the processor to generate an authentication token having client-specific and server-specific portions, responsive to receiving a first authentication request from a first machine. The first authentication request includes an identification of a second machine that is to provide a requested service. The memory also includes computer readable program code embodied therein that, when executed by the processor, causes the processor to transmit, to the second machine, an authentication identifier and the server-specific portion of the authentication token, responsive to receiving the first authentication request from the first machine. The memory further includes computer readable program code embodied therein that, when executed by the processor, causes the processor to determine an authentication status for the requested service responsive to receiving, from the second machine, a second authentication request including the authentication identifier, the server-specific portion of the authentication token, and the client-specific portion of the authentication token.

Still further embodiments of the present disclosure are directed to a computer system including a computer readable storage medium having computer readable program code embodied in the medium. When executed by a processor, the computer readable program code causes the processor to generate an authentication token having client-specific and server-specific portions, responsive to receiving a first authentication request from a first machine. The first authentication request includes an identification of a second machine that is to provide a requested service. The computer readable program code, when executed, also causes the processor to transmit, to the second machine, an authentication identifier and the server-specific portion of the authentication token, responsive to receiving the first authentication request from the first machine. The computer readable program code, when executed, further causes the processor to determine an authentication status for the requested service responsive to receiving, from the second machine, a second authentication request including the authentication identifier, the server-specific portion of the authentication token, and the client-specific portion of the authentication token.

It is noted that aspects described herein with respect to one embodiment may be incorporated in different embodiments although not specifically described relative thereto. That is, all embodiments and/or features of any embodiments can be combined in any way and/or combination. Moreover, other systems, methods, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, and/or computer program products be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

DETAILED DESCRIPTION

Various embodiments will be described more fully hereinafter with reference to the accompanying drawings. Other embodiments may take many different forms and should not be construed as limited to the embodiments set forth herein. Like numbers refer to like elements throughout.

As described herein, a computing system or environment may include one or more hosts, operating systems, peripherals, and/or applications. Machines in a same computing system or environment may have shared memory or resources, may be associated with the same or different hardware platforms, and/or may be located in the same (e.g., local) or different (e.g., remote) physical locations. Computing environments described herein may refer to a virtualized environment (such as a cloud environment) and/or a physical environment. Machines described herein may refer to physical machines or virtual machines (VMs), which may be managed by one or more virtual hypervisors in some embodiments.

Various embodiments of the present disclosure may arise from realization that, based on problems including system accountability, time scalability, maintainability, and/or cost, some conventional point-to-point authentication systems may benefit from an authentication server according to embodiments described herein, which can provide a less-complex configuration for system level authentication. In particular, the authentication server provides a common authentication mechanism for the systems in an enterprise and/or cloud environment, as well as an extra layer of security for the systems and subsystems, by utilizing a central registry for the machines in the environment. For a requested service, the authentication server thus provides a centralized solution (in contrast with separate ticket-granting and authentication servers) that directly communicates with and validates all involved parties (i.e., both the requesting client and the requested server), rather than only the requesting client. The authentication server can utilize randomly encrypted and randomly hashed token-based authentication, which can provide a stable, flexible, extensible, maintainable, and scalable solution, for both service-oriented architectures and the cloud.

FIG. 1Ais a block diagram illustrating a computing system or environment100in accordance with embodiments described herein, whileFIG. 1Bis a flow diagram illustrating operations performed by elements of a computing system or environment100in accordance with embodiments described herein.

Referring now toFIGS. 1A and 1B, a computing environment100(such as an enterprise and/or cloud environment) includes a plurality of computing machines (illustrated by way of example with reference to Machine1105and Machine2110) and an authentication server115that are communicatively coupled via networks120A,120B,120C. In some instances, the computing needs of users (e.g., humans and/or other virtual/non-virtual machines) may drive the functionality of the machines105and/or110. In the example ofFIGS. 1A and 1B, Machine1functions (and is referred to herein) as a client device105that is configured to request a service from Machine2, which functions (and is referred to herein) as a server device110that is configured to provide the requested service. As described in greater detail herein, the authentication server115provides machine-to-machine authentication based on participation and communication between all involved parties (e.g., between the authentication server115, the requesting client Machine1105, and the requested server Machine2110).

The networks120A,120B,120C may be global networks, such as the Internet or other publicly accessible networks. Various elements of the networks120A,120B,120C may be interconnected by a wide area network (WAN), a local area network (LAN), an Intranet, and/or other private network, which may not be accessible by the general public. Thus, the communication networks120A,120B,120C may represent a combination of public and private networks or a virtual private network (VPN). The networks120A,120B,120C may be a wireless network, a wireline network, or may be a combination of both wireless and wireline networks. Although illustrated as separate networks, it will be understood that the networks120A,120B,120C may represent a common network in some embodiments. A such, the machines105,110may communicate with one another and/or with the authentication server115by any conventional public and/or private, real and/or virtual wired and/or wireless network including all or a portion of the global communication network known as the Internet.

The computing system or environment can operate as follows to provide authentication for a requested service. The content of example requests, responses, and/or other messages1-8communicated between the machines105,110, and/or115illustrated inFIGS. 1A and 1Bare shown in greater detail below with reference to Tables 1-8. Referring toFIGS. 1A and 1B, Machine1105initiates a call or request for authentication by transmitting an initial or first authentication request1(auth_en_req) to the authentication server115. As shown in Table 1, the first authentication request1includes an identification Machine2110, such as the IP address and/or hostname of Machine2110. The authentication server115checks to determine whether the first authentication request1is received from an IP address and/or hostname (i.e., that of Machine1105) that is registered with the authentication server115, and to determine whether the IP address and/or hostname included in the first authentication request1(i.e., that of Machine2110) is registered with the authentication server115. If Machine1105is not registered, the authentication server115does not return a response. If Machine1105is registered but Machine2110is not registered, the authentication server115generates and returns a response only to Machine1105.

If both Machine1105and Machine2110are registered, the authentication server115generates and returns respective responses to Machine1105and Machine2110. In particular, in response to determining that Machine1105and Machine2110are registered based on the first authentication request1, the authentication server115generates a unique authentication identifier for the requested service, and also a randomly encrypted authentication token. The authentication server115logically divides the authentication token into two parts, one that is specific to the requesting client device105, and another that is specific to the requested server device110. The authentication server115thus generates and transmits a response message2a(auth_en_res) including the authentication identifier and the client-specific portion of the authentication token to Machine1105(as shown in Table 2a), and generates and transmits a response message2b(auth_en_message) including the authentication identifier and the server-specific portion of the authentication token to Machine2110(as shown in Table 2b). Machine1105and Machine2110accept and/or consume the authentication identifier included in the messages2aand2b, respectively.

In some embodiments, symmetric key encryption/decryption may be used when the authentication server115exchanges information with the client machine105and the server machine110. For example, the authentication server115and Machine1105(client) may use an encryption key (key1) for communication, which is stored at the authentication server115. Likewise, the authentication server115and Machine2110(server) may use a different encryption key (key2) for communication, which is also stored at the authentication server115. In some embodiments, the authentication server115may generate, store, and use one encryption key per machine, which is shared with respective machine. The authentication server-to-machine communication may use a common symmetric encryption algorithm, such as 3DES. The authentication server115may not exchange or otherwise share the respective encryption keys with any other machine in the environment100.

As such, in some embodiments the authentication server115may use two levels of encryption/decryption, one for authentication server-to-machine communication, and another for generation of the randomly encrypted and/or randomly-hashed authentication token. The central authentication server115may be capable of configuring N number of cryptographic hash functions and M number of encryption algorithms. The authentication server115may store hash type (e.g., md5, SHA-1, SHA2, SHA-3 etc.) and encryption type (Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, 3DES) for each authentication token. The authentication server115may generate a different encrypted authentication token for each received authentication request1, and thus, the number of generated authentication tokens may be relatively large, depending on the database and/or specific application (e.g. oracle, mysql etc.). The number of symmetric encryption keys used by the authentication server115may be relatively smaller, as, for authentication server-to-machine communication, the number of symmetric keys depends on the number of machines in the environment10(e.g., for an environment100including 10 machines, the authentication server115will store 10 keys, one per machine).

Still referring toFIGS. 1A and 1B, in response to receiving the response message2a(auth_en_res) from the authentication server115, Machine1105transmits a request or call3(cl_req) to Machine2110. As shown in Table 3, the request3from the client machine105includes the authentication identifier and the client-specific portion of the authentication token. Upon receipt of the request3, Machine2110checks for the authentication identifier, and, if it matches the authentication identifier received in the response message2b, directs a request to the authentication server115. In particular, Machine2transmits a subsequent or second authentication request4to the authentication server115. As shown in Table 4, the second authentication request contains the authentication identifier (which was received in message2band message3), the client-specific portion of the authentication token (which was received from the client machine105in message3), and the server-specific portion of the authentication token (which was received from the authentication server115in message2b).

The authentication server115compares the client-specific and server-specific portions of the authentication token received in the second authentication request4with the authentication token that was previously generated by the authentication server115for the received authentication identifier. The authentication server115determines and updates an authentication status for the requested service based on the comparison; if the comparison indicates a match, the authentication status is determined to be positive, while if the comparison does not indicate a match, the authentication status is determined to be negative. The authentication server115thus generates and transmits an authentication status response5(auth_server_res) to the server machine110. The authentication status response5includes the authentication identifier and the determined authentication status, as shown in Table 5.

Responsive to receiving the authentication status response5from the authentication server115, Machine2110generates and transmits a server response6(cl_res) to Machine1105. If the authentication status indicated in the authentication status response5(auth_server_res) is positive, the server response6includes the authentication identifier, as shown in Table 6, and/or other information relating to the requested service. If the authentication status indicated in the authentication status response5(auth_server_res) is negative, however, the server response6may include an error code.

Responsive to receiving the server response6from the requested server machine110, Machine1105determines whether to accept and/or consume the response6by generating and transmitting a verification or third authentication request7(cl_ack_req) to the authentication server115. As shown in Table 7, the third authentication request7includes the authentication identifier, for example, because the client machine105may have outstanding authentication requests to multiple servers (and thus, may be associated by the authentication server115with multiple authentication identifiers). In other words, as Machine1105may be associated with more than on authentication identifier at any given time, the presence of the authentication identifier in the third authentication request7ensures that the authentication server115responds with the authentication status corresponding to the correct service.

In particular, responsive to receiving the third authentication request7, the authentication server115generates and transmits an authentication acknowledgment8(cl_ack_res) to the client machine105. The authentication acknowledgment8includes the authentication identifier and the determined authentication status, as shown in Table 8. If the authentication status indicated in the authentication acknowledgment8is positive, Machine1105accepts and/or consumes the server response6. If the authentication status indicated in the authentication acknowledgment8is negative, Machine1105does not accept and/or otherwise refuses to consume the server response6. Thus, the client machine105transmits the third authentication request7to the authentication server115and uses the authentication acknowledgment8received therefrom as an additional or final check to ensure that the server response6from the server machine110is authentic. If the server response6is accepted, Machine1105connects to Machine2110, for example, based on SSL or other mechanism, depending on the environment. Machine1105, Machine2,110, and/or other machines in the environment100include respective configurations that require connection to the authentication server115with the initial authentication request1(for instance, via respective plug-ins that are configured to communicate with the authentication server), and the authentication server115is configured to maintain a list of all registered machines (for instance, by IP address/hostname) and accept requests from only registered machines.

The computing environment100can include any computing devices capable of implementing the machines105,110, and/or115, which may include, without limitation, a mainframe computer platform, personal computer, mobile computer (e.g., tablet computer), server, wireless communication terminal (e.g., cellular data terminal), or any other appropriate program code processing hardware. One or more of the machines105,110, and/or115may include computer resources such as a processing circuit(s) (e.g., central processing unit, CPU); networking controllers; communication controllers; a display unit; a program and data storage device; memory controllers; input devices (such as a keyboard, a mouse, etc.) and output devices such as printers. The processing hardware may include circuit(s) configured to execute computer program code from memory device(s), described below as a computer readable storage medium, to perform at least some of the operations and methods described herein, and may be any conventional processor circuit(s), such as the AMD Athlon™ 64, or Intel® Core™ Duo. Although some embodiments of the machines105,110, and/or115are configured to operate as a computer server, the functionality of the machines105,110, and/or115is not limited thereto and can be configured to provide other functionality, such as data processing, communications routing, etc. Also, while illustrated inFIGS. 1A and 1Bwith reference to machines105,110, and/or115by way of example, it will be understood that additional machines, servers, systems, etc. may be included in the environment100and configured to carry out the operations described herein.

FIG. 2illustrates an example computing device200in accordance with some embodiments of the present disclosure. The device200may be used, for example, to implement the authentication server115in the system100ofFIGS. 1A-1Busing hardware, software implemented with hardware, firmware, tangible computer-readable storage media having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The computing device200may also be a virtualized instance of a computer. As such, the devices and methods described herein may be embodied in any combination of hardware and software.

As shown inFIG. 2, the computing device200may include input device(s)205, such as a keyboard or keypad, a display210, and a memory212that communicate with one or more processors220(generally referred to herein as “a processor”). The computing device200may further include a storage system225, a speaker245, and I/O data port(s)235that also communicate with the processor220. The memory212may include an authentication module240installed therein. The authentication module240may be configured to determine an authentication status for a service requested by a client (such as Machine1105ofFIGS. 1A-1B), authorize a requested server (such as Machine2110ofFIGS. 1A-1B) to provide the requested service, and authorize the client to accept the requested service, as described herein.

The storage system225may include removable and/or fixed non-volatile memory devices (such as but not limited to a hard disk drive, flash memory, and/or like devices that may store computer program instructions and data on computer-readable media), volatile memory devices (such as but not limited to random access memory), as well as virtual storage (such as but not limited to a RAM disk). The storage system225may store one or more authentication tokens230(for example, one per request/session) and one or more encryption keys231(for example, one per machine) generated by the authentication module240, which may be accessed by the authentication module240to determine an authentication status for a requested service and indicate the authentication status to both the requesting client and the requested server, as described herein. Although illustrated in separate blocks, the memory212and the storage system225may be implemented by a same storage medium in some embodiments.

The input/output (I/O) data port(s)235may include a communication interface and may be used to transfer information in the form of signals between the computing device200and another computer system or a network (e.g., the Internet). The communication interface may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. These components may be conventional components, such as those used in many conventional computing devices, and their functionality, with respect to conventional operations, is generally known to those skilled in the art. Communication infrastructure between the components ofFIG. 2may include one or more device interconnection buses such as Ethernet, Peripheral Component Interconnect (PCI), and the like.

FIG. 3illustrates a software/hardware architecture300for an authentication server in accordance with embodiments of the present disclosure. In particular,FIG. 3illustrates a processor320and memory312that may be used in computing devices or other data processing systems, such as the computing device200ofFIG. 2and/or the authentication server115ofFIG. 1. The processor320communicates with the memory312via an address/data bus310. The processor320may be, for example, a commercially available or custom microprocessor, including, but not limited to, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), and multi-core processors. The memory312may be a local storage medium representative of the one or more memory devices containing software and data in accordance with some embodiments of the present invention. The memory312may include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash, SRAM, and DRAM.

As shown inFIG. 3, the memory312may contain multiple categories of software and/or data installed therein, including (but not limited to) an operating system block302and an authentication module block340. The operating system302generally controls the operation of the computing device or server. For example, the operating system302may manage software and/or hardware resources and may coordinate execution of programs by the processor320in providing the functions of the authentication server115ofFIG. 1. In particular, the authentication module340may be configured to provide instructions to the processor320that, when executed, carry out some or all of the functionality of the authentication server115ofFIG. 1.

Still referring toFIG. 3, the token comparator350is configured to compare information received in a subsequent authentication request from the requested server device110with the authentication token that was previously generated by the token generator335. As noted above, the subsequent authentication request from the server device110may include both the client-specific and the server-specific portions of the authentication token. The results of the comparison are provided to the authentication verification module360, which generates a positive or negative authentication status based on the results of the comparison, and provides the authentication status for transmission to both the client device105and the server device110. In particular, if the client- and server-specific portions of the authentication token received in the subsequent authentication request match the authentication token that was generated by the token generator335, the authentication verification module360generates a positive authentication status, which authorizes the server device110to provide and the client device105to accept the requested service. Conversely, if the information received in the subsequent authentication request does not match the authentication token generated by the token generator335, the authentication verification module360generates a negative authentication status, which effectively instructs the server device110to indicate an error in the authentication process and the client device105to decline the requested service.

Computer program code for carrying out the operations discussed above with reference toFIGS. 1-3may be written in a high-level programming language, such as COBOL, Python, Java, C, and/or C++, for development convenience. In addition, computer program code for carrying out operations of the present disclosure may also be written in other programming languages, such as, but not limited to, interpreted languages. Some modules or routines may be written in assembly language or even micro-code to enhance performance and/or memory usage. It will be further appreciated that the functionality of any or all of the program modules may also be implemented using discrete hardware components, one or more application specific integrated circuits (ASICs), or a programmed digital signal processor or microcontroller.

Authentication operations in accordance with some embodiments of the present disclosure will now be described with reference to the flowcharts ofFIGS. 4 and 5. The operations described with reference toFIGS. 4 and 5may be performed by the hardware/software architecture300ofFIG. 3, the computing device200ofFIG. 2, the authentication server115ofFIG. 1, and/or elements thereof.

Referring now toFIG. 4, operations begin at Block400where an initial or first authentication request from a first machine (such as the client machine105ofFIG. 1) is received. The first authentication request includes an identification of a second machine (such as the server machine110ofFIGS. 1A-1B), which is configured to provide a service that is requested by the first machine. In response to receiving the first authentication request, an authentication token is generated at Block410. The authentication token includes a client-specific portion and a server-specific portion. For example, a randomly encrypted token may be generated, and the token may be divided into two parts, one specific to the requesting client, and one specific to the requested server. An authentication identifier (for example, a unique identifier corresponding to the authentication request) and the server-specific portion of the authentication token are transmitted to the second machine that provides the requested service at Block420. The client-specific portion of the authentication token, however, is not transmitted to the second machine.

Still referring toFIG. 4, at Block430, a subsequent or second authentication request is received from the second machine, responsive to the transmission of Block420. The second authentication request includes the authentication identifier, the server-specific portion of the authentication token, and also the client-specific portion of the authentication token. The presence of the client-specific portion of the authentication token (which was not transmitted to the second machine by the authentication server) in the second authentication request may indicate communication between the first machine and the second machine.

In response to receiving the second authentication request from the second machine, an authentication status for the requested service is determined at Block440. In particular, the server-specific and client-specific portions of the authentication token received in the second authentication request at Block430may be compared with the authentication token that was generated at Block410, in order to determine whether the tokens match. If the tokens match, the authentication status is determined to be positive, while if the tokens do not match, the authentication status is determined to be negative. The authentication status determined at Block440may then be communicated to both the client and server machines, to either authorize the requested service (if the authentication status is positive) or decline the requested service (if the authentication status is negative).

FIG. 5is a flowchart illustrating authentication operations as described herein greater detail. Referring now toFIG. 5, operations begin at Block500where an initial or first authentication request is received from a first machine or server (such as client Machine1105ofFIGS. 1A-1B) at an authentication server (such as the authentication server115ofFIGS. 1A-1B). As noted above, the first authentication request includes an identification of a second machine or server (such as server Machine2110ofFIGS. 1A-1B) that is configured to provide a service being requested by the first machine.

In response to receiving the first authentication request, an authentication identifier and a randomly encrypted authentication token are generated by the authentication server at Block510. The authentication identifier is a unique character string corresponding or otherwise assigned to the first authentication request that was received from the first machine at Block500. The randomly encrypted authentication token is logically divided into a client-specific portion and a server-specific portion by the authentication server.

The authentication identifier and the client-specific portion of the authentication token are transmitted to the first machine at Block520A. The authentication identifier and the server-specific portion of the authentication token are transmitted to the second machine at Block520B. However, the client-specific portion of the authentication token is not transmitted to the second machine, and the server-specific portion of the authentication token is not transmitted to the first machine by the authentication server. In response to the operations of Blocks520A and520B, a subsequent or second authentication request is received at the authentication server from the second machine at Block530. The second authentication request includes the authentication identifier, the server-specific portion of the authentication token, and also the client-specific portion of the authentication token. As the client-specific portion of the authentication token was not transmitted to the second server, the presence of the client-specific portion of the authentication token in the second authentication request is indicative of communication between the second machine and the first machine (to which the client-specific portion of the authentication token was transmitted at Block520A).

At Block540, the server-specific and the client-specific portions of the authentication token received at Block530are compared to the authentication token generated at Block510to determine the authentication status for the requested service. In particular, a match between the generated authentication token (at Block510) and the received server-specific and the client-specific portions (at Block530) results in a positive authentication status (i.e., the authentication was successful), while the absence of a match between the generated authentication token (at Block510) and the received server-specific and the client-specific portions (at Block530) results in a negative authentication status (i.e., the authentication was unsuccessful).

An authentication response including the determined authentication status is transmitted from the authentication server to the second machine at Block550. If the indicated authentication status is positive, the second machine may respond to the first machine with communications relating to the requested service. On the other hand, if the indicated authentication status is negative, the second machine may respond to the first machine with an error code. The authentication response from the authentication server may thus effectively authorize the second machine to provide the requested service to the first machine.

Another or third authentication request is received at the authentication server from the first machine at Block560. The third authentication request includes the authentication identifier, and is received in response to transmitting the authentication response to the second server that Block550. The third authentication request may indicate to the authentication server that the second machine has responded to the initial request for service, and that the first machine is seeking a confirmation or authorization to accept communications relating to the requested service from the second machine.

At Block570, in response to the third authentication request, an authentication acknowledgement including the determined authentication status is transmitted from the authentication server to the first machine. If the indicated authentication status is positive, the first machine may accept and/or consume communications from the second machine in providing the requested service. If the indicated authentication status is negative, the first server may not accept communications from the second machine. The first machine (i.e., the client) may also implement audit logging with respect to the success or failure of the authentication for the requested service.

Although described above with reference to specific configurations, authentication servers in accordance with embodiments of the present disclosure may include multiple design considerations, some but not all of which are explicitly discussed above, and one or more (but not necessarily all) of which may be employed in embodiments of the present disclosure. For example, the authentication server can be configured to store random SHAs and/or random encrypted tokens, and/or may be capable of configuring M number of encryption algorithms (e.g. Triple DES, DES, etc.). The authentication server may be responsible for dividing the authentication token into the client- and server-specific portions, while the client and server machines may be responsible for updating the actions taken in response to the authentication status. The authentication server may also be configured to handle generation of a unique authentication identifier for each initial authentication request received from a client machine, and/or may be configured to encrypt the authentication identifier with symmetric key encryption. Also, the authentication server may allow for configurable token expiry. The authentication server may be configured to conduct communications with client and server machines in a point-to-point manner. The authentication server may be configured to maintain a queue or pool for incoming authentication requests. In some embodiments, the authentication server may be a web-based application. The authentication server may also include an admin module and/or provide a reporting system. Also, the authentication server may be accessed only by client and/or server machines having registered IP addresses, while communication between the authentication server and other machines may be handled by https (for example, REST or SOAP Web Services over http or https can be implemented). In some embodiments, the authentication server may be used with SSL only. Moreover, the client and server machines may be configured for communication with the authentication server via plug-ins, where the plug-in communicates the authentication requests with the authentication server.

Embodiments described herein may differ from some conventional authentication techniques in several aspects. For example, while some conventional algorithms (such as the Kerberos algorithm) may also utilize an authentication server and a secondary server (such as a ticket-generating or granting server) to authenticate a client application by a server application, such algorithms may communicate with only the client application, or with only the server application. In contrast, embodiments of the present disclosure provide a single, centralized authentication server that is configured to communicate with both the client and server machines, such that all parties are involved in the authentication, without the use of a ticket-generating server or other secondary server in the authentication process. Embodiments of the present disclosure also require an additional authentication request from the client machine (referred to herein as the third authentication request) and a corresponding response from the authentication server (referred to herein as the acknowledgment response), as an additional or final verification step. Also, while some conventional algorithms may only validate the client machine, embodiments of the present disclosure are configured to authenticate both the requesting client machine and the requested server machine. In addition, some such conventional algorithms may use authentication of the end user client, while embodiments of the present disclosure are configured to use machine-to-machine authentication. Furthermore, as embodiments of the present disclosure operate without human intervention, and thus, may differ from keystroke logging- and/or shoulder surfing-based authentication.

The flowchart and block diagrams in the FIGS. illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the FIGS. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting to other embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including”, “have” and/or “having” (and variants thereof) when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. In contrast, the term “consisting of” (and variants thereof) when used in this specification, specifies the stated features, integers, steps, operations, elements, and/or components, and precludes additional features, integers, steps, operations, elements and/or components. Elements described as being “to” perform functions, acts and/or operations may be configured to or otherwise structured to do so. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items and may be abbreviated as “/”.

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and/or combination, and the present specification, including the drawings, shall support claims to any such combination or subcombination.