Buffering proxy for telnet access

CROSS REFERENCE TO RELATED APPLICATIONS

p-0002(Not applicable)

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

p-0003(Not applicable)

BACKGROUND OF THE INVENTION

p-0004The present invention relates to Telnet proxies and, more particularly, to Telnet proxies that buffer option negotiation commands until after Telnet sessions are established between clients and remote servers.

p-0005Telnet is a well-known computer network protocol used to establish a connection over a network between a real or emulated terminal and a remote computer (also called a “remote server” or simply a “host”). Such a Telnet session enables a user to log in to the remote host and to engage in an interactive session with the host. A Telnet session is typically carried over a TCP/IP connection.

p-0006A Telnet session is established between a client and a server. Between the client and the server, the Telnet session simulates a Network Virtual Terminal (NVT). Data from the client, such as characters typed on a keyboard, is treated as though it was entered on the NVT, and the data is delivered to the server. Similarly, data sent by the server is treated as though it is displayed on the NVT. If a user uses Telnet to log in to a remote host, the user typically executes a terminal emulator program (the client), such as on a personal computer. The terminal emulator accepts input from a real keyboard and treats the input as though it was entered on the NVT. The terminal emulator displays characters received by the NVT on the user's real display device.

p-0007To accommodate the wide variety of hardware and software, such as keyboards and displays, that the user and the remote host can use, the Telnet protocol defines how characters sent between the client and the server are treated. These characters include 95 printable characters (such as letters, digits and punctuation marks) and 33 control characters, such as BS (backspace), CR (carriage return) and HT (horizontal tab). Most characters, such as a-z, A-Z, 0-9, punctuation marks, BS, HT (horizontal tab), FF (form feed), etc., have their normal meanings.

p-0008In addition, the Telnet protocol allows the client and the server to negotiate various options. For example, the client and the server can negotiate whether characters entered by the user are echoed locally by the terminal emulator or remotely by the server. Each party (the client and the server) can request the other party to perform or to not perform a specified option. In addition, each party can, on its own (i.e., without a request from the other party), declare to the other party that the declaring party will or will not perform a specified option.

p-0009Sometimes these option negotiations are constrained by hardware or software limitations in the client or the server. Thus, one party might refuse to perform a requested option, because it is incapable of performing the function. In other cases, one party can arbitrarily refuse to perform a requested option.

p-0010An option negotiation is conducted by sending a series of WILL, WON'T, DO and/or DON'T Telnet commands between the parties. The WILL command is used by either party to indicate that the party is willing to begin performing a specified option. For example, a first party sends a “WILL Echo” command to indicate that the party is able and willing to echo characters locally. The other party sends a “DO Echo” or “DON'T Echo” command to request that the first party begin locally echoing characters or not, respectively. The first party then responds with a “WILL Echo” or “WON'T Echo” as a positive or negative acknowledgment, respectively.

p-0011A Telnet proxy is an entity that resides in a network connection between a client and a server. The proxy presents an interface to the client in which the proxy appears to be a server. Similarly, the proxy presents an interface to the server in which the proxy appears to be a client. Some conventional Telnet proxies authenticate users, such as by requiring the users to enter valid user names and passwords, before establishing a Telnet session between the user's client and a requested remote host. When a Telnet connection is established between the client and the host, the Telnet proxy passes data sent by either party to the other party.

p-0012Some conventional Telnet proxies negotiate options with clients before establishing Telnet sessions with remote hosts, then attempt to negotiate the same options with the remote hosts. However, if the remote hosts reject the negotiation attempts, the proxies must then renegotiate the options with the clients. These renegotiations can be inconvenient and time consuming.

p-0013Some conventional Telnet proxies do not permit option negotiations to occur until after a Telnet session is established with a remote host, because the capabilities of the remote host are not known until after the Telnet session is established. However, this deferral of options negotiation delays the productive portion of the user's session with the remote host.

BRIEF SUMMARY OF THE INVENTION

p-0014The present invention provides a buffering Telnet proxy that accepts option negotiation commands from a client before a Telnet connection is established between the client and a host (Telnet server). The proxy negotiates a limited set of options with the client before the Telnet connection is established. The proxy buffers (i.e., accepts and temporarily stores without responding to) other received option negotiation commands until after the proxy establishes the Telnet connection to the host and logs in to the host on behalf of a user.

p-0015When the user identifies a host to which the user wishes to be connected, the proxy checks the user's access rights. If the user's access rights permit a Telnet connection to be established to the identified host, the proxy establishes the Telnet connection. The proxy buffers any option negotiation commands sent by the host until after the proxy logs in to the host.

p-0016The proxy attempts to log in to the host on behalf of the user. If the login succeeds, the proxy sends the client's buffered option negotiation commands to the host, and the proxy sends the host's buffered option negotiation commands to the client, all without renegotiating any options. The proxy then ceases buffering option negotiation commands sent by either party and enters a “pass-through” mode, in which the proxy passes characters and commands between the parties, until the session ends. A “party” herein refers to a user computer, a proxy, a server or the like.

p-0017These and other features, advantages, aspects and embodiments of the present invention will become more apparent to those skilled in the art from the Detailed Description Of The Invention that follows.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

p-0018The invention will be more fully understood referring to the Detailed Description Of The Invention in conjunction with the Drawings, of which:

p-0019<figref idrefs="DRAWINGS">FIG. 1</figref> is a prior art block diagram of a conventional Telnet connection between a Telnet client and a Telnet server;

p-0020<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary network that includes a buffering Telnet proxy, in accordance with an embodiment of the present invention;

p-0021<figref idrefs="DRAWINGS">FIG. 3</figref> is a more detailed block diagram of the network and the buffering Telnet proxy of <figref idrefs="DRAWINGS">FIG. 2</figref> during an authentication/setup phase;

p-0022<figref idrefs="DRAWINGS">FIG. 4</figref> is a more detailed block diagram of the network and the buffering Telnet proxy of <figref idrefs="DRAWINGS">FIG. 2</figref> during a pass-through phase;

p-0023<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram of an exemplary hardware embodiment of the Telnet proxy of <figref idrefs="DRAWINGS">FIG. 2</figref>;

p-0024<figref idrefs="DRAWINGS">FIG. 6(</figref><i>a</i>-<i>c</i>) is a flowchart of operations performed by the buffering Telnet proxy of <figref idrefs="DRAWINGS">FIG. 2</figref>, according to an embodiment of the present invention;

p-0025<figref idrefs="DRAWINGS">FIG. 7</figref> depicts an exemplary interactive session between the user and the buffering Telnet proxy of <figref idrefs="DRAWINGS">FIG. 2</figref>; and

p-0026<figref idrefs="DRAWINGS">FIG. 8</figref> is a block diagram of an another exemplary network that includes a buffering Telnet proxy, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

p-0027In accordance with the present invention, a method and apparatus is disclosed for buffering option negotiation commands until after a Telnet connection is established between a client and a host. Before discussing the inventive buffering proxy, a brief overview of Telnet option negotiations is provided.

Telnet Option Negotiation

p-0028<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram of a conventional Telnet connection between a user computer <b>100</b> and a remote computer <b>104</b> via a network <b>102</b>. The user computer <b>100</b> executes a Telnet client program <b>106</b>, which simulates a terminal (not shown) to a user. The Telnet client program <b>106</b> accepts inputs from the user, such as through a keyboard <b>108</b>, and displays outputs to the user, such as through a display <b>110</b>. The Telnet client program <b>106</b> communicates, according to the Network Virtual Terminal (NVP) <b>112</b> Telnet standard, with a Telnet server program <b>114</b> in the remote computer <b>104</b>.

p-0029The Telnet server program <b>114</b> provides the user inputs to a remote login server or other program <b>116</b> being executed by the remote computer <b>104</b>. Similarly, the Telnet server program <b>114</b> sends outputs from the remote login server or other program <b>116</b> to the Telnet client program <b>106</b> for display on the display <b>110</b>. This arrangement enables the user to remotely log in to the remote computer <b>104</b> and interact with programs being executed there.

p-0030The Telnet protocol defines various commands that control interactions between the client <b>106</b> and the server <b>114</b>. Each command is sent as a sequence of two or more bytes beginning with an “Interpret as command” (IAC) character (decimal code 255) followed by a command byte. Table 1 is a partial list of conventional Telnet command codes. Commands dealing with option negotiation are three-byte sequences, the third byte being an option code. Table 2 is an exemplary list of conventional Telnet option codes.

p-0031<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary Telnet Commands</entry></row><row><entry>(Prior Art)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="35pt" align="center" /><colspec colname="3" colwidth="224pt" align="left" /><tbody valign="top"><row><entry /><entry>Code</entry><entry /></row><row><entry>Name</entry><entry>(Decimal)</entry><entry>Meaning</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>EC</entry><entry>247</entry><entry>Erase character. The receiver should delete the last preceding non-deleted</entry></row><row><entry /><entry /><entry>character from the data stream.</entry></row><row><entry>EL</entry><entry>248</entry><entry>Erase line. Delete characters from the data stream back to, but not including,</entry></row><row><entry /><entry /><entry>the previous CR LF.</entry></row><row><entry>WILL</entry><entry>251</entry><entry>Indicates a desire by a sender to begin performing, or confirmation that the</entry></row><row><entry /><entry /><entry>sender is now performing, the indicate it option.</entry></row><row><entry>WON'T</entry><entry>252</entry><entry>Indicates a refusal by a sender to perform, or continue performing, the</entry></row><row><entry /><entry /><entry>indicated option.</entry></row><row><entry>DO</entry><entry>253</entry><entry>Indicates a request that the other party perform, or confirmation that the</entry></row><row><entry /><entry /><entry>sender is expecting the other party to perform, the indicated option.</entry></row><row><entry>DON'T</entry><entry>254</entry><entry>Indicates a demand that the other party stop performing, or confirmation that</entry></row><row><entry /><entry /><entry>the sender is no longer expecting the other party to perform, the indicated</entry></row><row><entry /><entry /><entry>option.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0032<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary Negotiable Telnet Options</entry></row><row><entry>(Prior Art)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70pt" align="center" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="63pt" align="center" /><tbody valign="top"><row><entry>Code</entry><entry>Name</entry><entry>RFC</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70pt" align="char" char="." /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="63pt" align="char" char="." /><tbody valign="top"><row><entry>1</entry><entry>Echo</entry><entry>857</entry></row><row><entry>3</entry><entry>Suppressed go ahead</entry><entry>858</entry></row><row><entry>24</entry><entry>Terminal type</entry><entry>1091</entry></row><row><entry>39</entry><entry>Telnet environment option</entry><entry>1572</entry></row><row><entry>31</entry><entry>Window size</entry><entry>1073</entry></row><row><entry>35</entry><entry>X display location</entry><entry>1096</entry></row><row><entry>23</entry><entry>Send location</entry><entry>779</entry></row><row><entry>0</entry><entry>Binary transmission</entry><entry>856</entry></row><row><entry>17</entry><entry>Extended ASCII</entry><entry>698</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0033As noted above, the Telnet client program <b>106</b> and the Telnet server program <b>114</b> negotiate options by sending a series of WILL, WON'T, DO and DON'T Telnet commands to each other. Each such command begins with an IAC character, followed by a WILL, WON'T, etc. command code and ends with an option code. For example, a command to request the other party to begin locally echoing characters takes the form: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0033">IAC (255)+DO(253)+Echo (1)</li></ul></li><li id="ul0001-0002" num="0034">The recipient of this command can agree or decline to perform the requested option. If the recipient declines to perform the requested option, the recipient sends: <ul><li id="ul0003-0001" num="0035">IAC (255)+WON'T (252)+Echo (1)</li></ul></li><li id="ul0001-0003" num="0036">On the other hand, if the recipient agrees to perform the requested option, the recipient sends: <ul><li id="ul0004-0001" num="0037">IAC (255)+WILL (251)+Echo (1)</li></ul></li><li id="ul0001-0004" num="0038">Upon receiving the command indicating that the recipient agrees to perform the requested option, the requester sends: <ul><li id="ul0005-0001" num="0039">IAC (255)+DO (253)+Echo (1)</li></ul></li></ul>

p-0034Telnet option negotiations can be initiated by either party. For example, if a first party wishes to locally echo characters without having been requested to do so by the other party, the first party sends a command of the form: <ul><li id="ul0006-0001" num="0000"><ul><li id="ul0007-0001" num="0041">IAC (255)+WILL (251)+Echo (1) <br /> The receiving party accepts or declines this offer by sending a DO or DON'T command, respectively. </li></ul></li></ul>

Buffering Proxy

p-0035Corporations and other organizations with multiple computer users typically use local area networks (LANs) to interconnect their computers. Frequently, one or more of these computer users need to log in to, or otherwise access, a remote computer. <figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary context in which a buffering Telnet proxy can be used to provide such remote access. One or more user computers <b>200</b> are connected to a LAN <b>202</b>. Optionally, an authentication server <b>204</b> (described below) is also connected to the LAN <b>202</b>. The LAN <b>202</b> is connected via a buffering Telnet proxy <b>206</b> to the Internet or another wide area network (WAN) <b>208</b>. The buffering Telnet proxy <b>206</b> can also be used for communications among computers <b>200</b> on the LAN <b>202</b> or another suitable computer network. Various remote computers, such as an FTP server <b>210</b>, a web server <b>212</b>, a Telnet server <b>214</b> and an NNTP server <b>216</b>, can be connected to the Internet <b>208</b>. The Telnet server <b>214</b> can be included in any of the other remote computers <b>210</b>, <b>212</b> or <b>216</b>.

p-0036When a user of one of the computers <b>200</b> wishes to access the remote Telnet server <b>214</b>, the user uses a terminal emulator program or other conventional mechanism on the user's computer <b>200</b> to communicate with the buffering Telnet proxy <b>206</b>. The user identifies the Telnet server <b>214</b> to the Telnet proxy <b>206</b> and requests the Telnet proxy to establish a Telnet connection between the user's computer <b>200</b> and the Telnet server. The Telnet proxy <b>206</b> performs various functions during two separate phases. During an “authentication/setup” phase, the Telnet proxy <b>206</b> performs user authentication and, if the user is so authorized, the Telnet proxy <b>206</b> establishes the Telnet connection to the Telnet server <b>214</b>, and the Telnet proxy logs in to the Telnet server <b>214</b> on behalf of the user. Following a successful login, the Telnet proxy <b>206</b> enters a “pass-through” phase. During this phase, the Telnet proxy <b>206</b> transfers data (characters and commands) between the user's computer <b>200</b> and the Telnet server <b>214</b>. Each of these phases is described in more detail below.

Authentication/Setup Phase

p-0037<figref idrefs="DRAWINGS">FIG. 3</figref> is a more detailed block diagram of the environment and the Telnet proxy <b>206</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> during the authentication/setup phase. Before the Telnet proxy <b>206</b> establishes a Telnet connection on behalf of the user, the Telnet proxy requires the user to provide valid credentials, typically in the form of a username/password combination. During the authentication/setup phase, a first portion of the Telnet proxy <b>206</b> (i.e. a first communication protocol proxy system for authentication, identified as a “Telnet server for authentication” <b>300</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>) communicates with the user computer <b>200</b>. After the user identifies the remote server <b>214</b>, to which the user wishes to be connected, a second portion of the Telnet proxy <b>206</b> (i.e. a second communication protocol proxy system, identified as a “Telnet client for setup” <b>310</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>) communicates with the remote server <b>214</b>. An example of an interactive session between a user and the Telnet proxy <b>206</b> is shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. User inputs are underlined.

p-0038The Telnet server for authentication <b>300</b> prompts the user for credentials. For example, in <figref idrefs="DRAWINGS">FIG. 7</figref>, the Telnet server for authentication <b>300</b> prompts for a username at <b>700</b> and for a password at <b>702</b>. The user enters a username at <b>704</b> and a password at <b>706</b>, although the password is echoed by the Telnet server for authentication <b>300</b> as asterisks.

p-0039The Telnet server for authentication <b>300</b> (<figref idrefs="DRAWINGS">FIG. 3</figref>) validates the user's responses against a local authentication database <b>302</b>. Alternatively or additionally, the Telnet server for authentication <b>300</b> queries a remote authentication server <b>204</b>, which maintains a database <b>306</b> of valid credentials and or/user access rights. The authentication server <b>204</b> can be a proprietary authentication server, an LDAP server, an NTLM authentication proxy server, a Kerberos Key Distribution Center (KDC) or any other mechanism that can validate user credentials or provide information regarding user access rights. Although the authentication server <b>204</b> is shown connected to the LAN <b>202</b>, the authentication server can be located elsewhere, such as on the Internet <b>208</b>. Optionally, the Telnet server for authentication <b>300</b> queries the authentication server <b>204</b> and locally caches all or a portion of the received information in the local authentication database <b>302</b> or in a data store <b>308</b> (described below). The local authentication database <b>302</b> and the combination of the authentication server <b>204</b> and the database <b>306</b> are collectively referred to herein as an authentication database.

p-0040The local authentication database <b>302</b> or the authentication server <b>204</b> provides information to the Telnet server for authentication <b>300</b> about the access rights of the user. These access rights indicate which remote computers the user is permitted to access and/or is forbidden to access. These access rights can be in the form of, for example, an access control list (ACL). Other user- and group-management facilities can also be employed.

p-0041After receiving the user's rights from the local authentication database <b>302</b> or from the authentication server <b>204</b>, the Telnet server for authentication <b>300</b> stores this information in a data store <b>308</b>, which can be a disk memory, random access memory (RAM) or any other suitable memory. Optionally, the Telnet server for authentication <b>300</b> stores an identification of the user's computer <b>200</b>, such as the computer's Internet protocol (IP) address, in association with the received user rights.

p-0042The Telnet server for authentication <b>300</b> prompts the user for the name of a host, to which the user wishes to be connected, as shown at <b>708</b> (<figref idrefs="DRAWINGS">FIG. 7</figref>), and the user enters a host name, as shown at <b>710</b>. The Telnet server for authentication <b>300</b> ascertains whether the user is permitted to access the requested host by comparing the entered host name to one or more lists of hosts that the user is permitted to access and/or forbidden to access. These lists are stored in the data store <b>308</b> or, alternatively, in the authentication database <b>302</b> or <b>306</b>.

p-0043Optionally, the local authentication database <b>302</b> or the authentication server <b>204</b> stores user credentials, such as user names and passwords, that are valid on the remote server <b>214</b> and other computers (if any), on which the user has Telnet-accessible accounts or other accounts. These user credentials are provisioned in advance by a system administrator, for example. These user credentials can be associated with the user, the user's organization or with another entity. These credentials can be used by the Telnet client for setup <b>310</b> to log in to the remote server <b>214</b> on behalf of the user, as described in more detail below. Optionally, the Telnet server for authentication <b>300</b> also stores these user credentials in association with the information that identifies the user's computer <b>200</b> so, later, the Telnet server for authentication <b>300</b> can handle a subsequent request from the same computer <b>200</b> without necessarily querying the authentication server <b>204</b>.

p-0044During the authentication/setup phase, the Telnet server for authentication <b>300</b> implements a subset of the Telnet protocol to communicate with the user's computer <b>200</b>. This subset includes processing a subset of control characters, a subset of Telnet commands and a subset of options. For example, the Telnet server for authentication <b>300</b> treats each CR (carriage return) character as indicating the end of an input, such as a username, a password or a requested host's name. For another example, for each BS (backspace) character the Telnet server for authentication <b>300</b> receives, the Telnet server for authentication ignores a successively earlier-received character from the client (not shown) on the user's computer <b>200</b>. The control-U character (NAK, code 21 (decimal)) causes the Telnet server for authentication <b>300</b> to ignore an entire line of received characters.

p-0045The Telnet server for authentication <b>300</b> requests the client being executed by the user's computer <b>200</b> to suppress “go ahead” and “not to echo” characters, i.e. to enter “one character at a time mode,” at least while the user is entering a password. For each character of the entered password, the Telnet server for authentication <b>300</b> echoes a printable character, such as an asterisk (“*”), to provide feedback to the user without revealing the entered password. For non-password characters, the Telnet server for authentication <b>300</b> either echoes the character or requests the client to locally echo the characters. In other words, during the authentication/setup phase, the Telnet server for authentication <b>300</b> acts somewhat like an interactive shell.

p-0046If the Telnet server for authentication <b>300</b> receives an option negotiation request from the client on the user's computer <b>200</b> indicating that the client is willing to suppress “go ahead” or “to echo” characters, the Telnet server for authentication replies appropriately, i.e. the Telnet server for authentication sends the appropriate DO or DON'T acknowledgment.

p-0047If the Telnet server for authentication <b>300</b> receives an option negotiation request from the client on the user's computer <b>200</b> requesting either binary transmission (code 0, see Table 2) or extended ASCII (code 17), the Telnet server for authentication rejects the request. That is, if the user's computer <b>200</b> sends a WILL negotiation request, indicating a desire to begin performing either of these options, the Telnet server for authentication <b>300</b> replies with a DON'T negotiation request. Furthermore, if the user's computer <b>200</b> sends a DO negotiation request for either of these options, thereby requesting the Telnet server for authentication <b>300</b> to begin performing one of these options, the Telnet server for authentication replies with a WON'T negotiation request.

p-0048If the Telnet server for authentication <b>300</b> receives any other option negotiation request(s) from the client on the user's computer <b>200</b>, the Telnet server for authentication buffers the received option negotiation request(s), such as in the data store <b>308</b>, until after the Telnet client for setup <b>310</b> logs in to the remote server <b>214</b> on behalf of the user. The Telnet server for authentication <b>300</b> does not respond to the client on the user's computer <b>200</b> after receiving these other option negotiation request(s).

p-0049If the user's access rights permit a connection to be established to the requested remote server <b>214</b>, the Telnet client for setup <b>310</b> uses information in the data store <b>308</b> to establish a Telnet connection to the remote server and to remotely log in to the remote server on behalf of the user. Alternatively, the Telnet client for setup <b>310</b> simply establishes a Telnet connection to the remote server <b>214</b> and allows the user to provide his or her credentials directly to the remote server, once the pass-through phase is entered.

p-0050If the Telnet client for setup <b>310</b> receives any option negotiation request(s) from the remote server <b>214</b> before the user is logged in to the remote server, the Telnet client for setup <b>310</b> buffers the received option negotiation request(s) in the data store <b>308</b>, without responding to the remote server <b>214</b>. If the Telnet client for setup <b>310</b> receives any character data from the user's computer <b>200</b>, the Telnet client for setup <b>310</b> echoes this data to the user's computer according to the then-current echo option setting with the user's computer <b>200</b>. The Telnet client for setup <b>310</b> buffers the received character data until after the Telnet connection is established to the remote server <b>214</b> and all buffered options are negotiated with the remote server <b>214</b>. Similarly, if the Telnet client for setup <b>310</b> receives any character data from the remote server <b>214</b>, the Telnet client for setup <b>310</b> buffers the received character data until after all buffered options are negotiated with the user's computer <b>200</b>.

p-0051Optionally, the Telnet server for authentication <b>300</b> and the Telnet client for setup <b>310</b> log significant events in a log <b>312</b>. For example, these events can include indications of successful or failed attempts by users to log in to the Telnet server for authentication <b>300</b>, successful or failed attempts by the Telnet client for setup <b>310</b> to establish Telnet connections to the remote server <b>214</b>, successful or failed attempts by the Telnet client for setup <b>310</b> to log in to the remote server on behalf of users and the ends of Telnet connections. Log entries can include time and date information, as well as an identification of the user (such as username), the user's computer (such as name or IP address), port number on the Telnet proxy, remote server (such as name or IP address), number of bytes or packets sent and/or received, etc. The log <b>312</b> can be used to produce reports of the number, time or frequency of user authentication attempts, successes or failures, the number of currently active Telnet connections, etc.

p-0052Welcome messages, prompts and the like from the remote server <b>214</b> are passed by the proxy <b>206</b> to the user computer <b>200</b>, as shown at <b>712</b> (<figref idrefs="DRAWINGS">FIG. 7</figref>). If the Telnet client for setup <b>310</b> logs into the remote server <b>214</b> on behalf of the user, the username and password <b>714</b> are supplied by the Telnet client for setup from the data store <b>308</b>. The Telnet client for setup <b>310</b> sends the username and password to the remote server <b>214</b>. On the other hand, if the Telnet client for setup <b>310</b> simply establishes a Telnet connection to the remote server <b>214</b> and allows the user to enter his or her credentials directly to the remote server, the credentials <b>714</b> are entered by the user, and the Telnet proxy <b>206</b> passes these through to the remote server <b>214</b>. In either case, these credentials are typically echoed by the remote server <b>214</b>.

Pass-Through Phase

p-0053After the Telnet client for setup <b>310</b> establishes the Telnet connection to the remote server <b>214</b> and logs in to the remote server <b>214</b> on behalf of the user (or the user logs in directly), the Telnet proxy <b>206</b> sends the buffered negotiation requests. That is, the Telnet proxy <b>206</b> sends to the remote server <b>214</b> the buffered negotiation requests that it has received from the user computer <b>200</b>, and the Telnet proxy <b>206</b> sends to the user computer <b>200</b> the buffered negotiation requests that it has received from the remote server <b>214</b>. The Telnet proxy <b>206</b> passes any responses to these option negotiations through to the other party. Having buffered option negotiation requests received from one party and having subsequently forwarded these requests to the other party and having forwarded any responses received from one party to the other party, the buffering Telnet proxy <b>206</b> avoids renegotiating options.

p-0054After the buffered negotiation requests have been sent, the Telnet proxy <b>206</b> sends any buffered character data it has received from one party to the other party and enters the pass-through phase, as shown in <figref idrefs="DRAWINGS">FIG. 4</figref>. During the past-through phase, the Telnet proxy <b>206</b> passes characters and commands it receives from one party to the other party, as indicated at <b>400</b>. This pass-through is also referred to as “tunneling” through the Telnet proxy <b>206</b>.

p-0055Optionally, the Telnet proxy <b>206</b> keeps track of the number of bytes transferred between the parties and occasionally or periodically writes this information to the log <b>312</b>. Alternatively or in addition, the Telnet proxy <b>206</b> writes this data to the log <b>312</b> after the Telnet connection between the user computer <b>200</b> and the remote server <b>214</b> is ended.

p-0056The Telnet proxy <b>206</b> monitors the commands sent by the parties for requests to end the Telnet session. If the user computer <b>200</b> or the remote server <b>214</b> requests that the Telnet session be ended, the Telnet proxy <b>206</b> ends the Telnet session and, optionally, writes an entry in the log <b>312</b>. The kind of information recorded in the log <b>312</b> is described above. The log <b>312</b> can be use to produce reports of the number, time, duration or frequency of client connections to the Telnet proxy <b>206</b> or to the remote server <b>214</b>.

p-0057After the Telnet session has ended, the Telnet proxy <b>206</b> leaves the pass-through phase and returns to the authentication/setup phase. If the user subsequently requests another connection to the remote server <b>214</b>, or a connection to another computer, the Telnet server for authentication <b>300</b> repeats the processing described above, i.e. the Telnet server for authentication checks whether the user is permitted to access the requested server, buffers option negotiation requests, establishes a Telnet connection to the requested server, etc. The Telnet server for authentication <b>300</b> need not, however, prompt the user for a user name and password, because the user had been previously authenticated, and the user's access rights are stored in the data store <b>308</b>.

Interposing the Buffering Telnet Proxy

p-0058The buffering Telnet proxy <b>206</b> described above can be interposed between an existing Telnet client and an existing Telnet server, such as to add a user authentication service between the existing client and the existing Telnet server. If an existing client is configured to communicate with an existing server using the Telnet protocol, the buffering Telnet proxy <b>206</b> can be interposed between the existing client and the existing server transparently, i.e. without modifying the protocol between the existing client and the existing server. Because the buffering Telnet proxy <b>206</b> presents a Telnet server-like interface to the client and accepts or buffers option negotiation requests, the existing client interacts with the buffering Telnet proxy <b>206</b> in the same way it would interact with the existing Telnet server. Similarly, because the buffering Telnet proxy <b>206</b> presents a Telnet client-like interface to the server, the existing server interacts with the buffering Telnet proxy <b>206</b> in the same way it would interact with the existing Telnet client. Because the buffering Telnet proxy <b>206</b> negotiates some options with the client and with the existing Telnet server and buffers other options until after the proxy <b>206</b> establishes a Telnet connection between the parties, the interposition of the buffering Telnet proxy <b>206</b> does not disturb the Telnet communications between the parties.

p-0059The interposed buffering Telnet proxy <b>206</b> can provide a user authentication service, a usage logging service, etc., as described above. For example, before establishing a Telnet connection between the existing client and the existing Telnet server, the buffering Telnet proxy <b>206</b> can require a user to enter valid credentials. Thus, an organization that previously provided unsupervised Telnet access between clients and Telnet servers (such as Telnet servers on the Internet) can regulate this access by interposing the buffering Telnet proxy <b>206</b> between the clients and the Telnet servers. Such regulation can, for example, limit access by employees to work-related Telnet servers and block access to inappropriate Telnet servers on the Internet during work hours.

p-0060As shown in <figref idrefs="DRAWINGS">FIG. 8</figref>, the buffering Telnet proxy <b>206</b> can also be interposed between an existing Telnet client on user's computer <b>200</b> and an existing conventional Telnet proxy <b>800</b>, such as to add a user authentication service. Alternatively (not shown), the buffering Telnet proxy <b>206</b> can be interposed between the existing conventional Telnet proxy <b>800</b> and the existing Telnet server <b>214</b>. Because the buffering Telnet proxy <b>206</b> presents a Telnet server-like interface to a client and a client-like interface to a Telnet server, the buffering Telnet proxy <b>206</b> can be interposed anywhere along a Telnet connection.

Hardware Embodiment

p-0061<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram of an exemplary hardware embodiment of the Telnet proxy <b>206</b>. A bus <b>500</b> interconnects two network interfaces <b>502</b> and <b>504</b>. One of the network interfaces <b>502</b> is connected to the LAN <b>202</b>. The other network interface <b>504</b> is connected to the Internet <b>208</b>. As noted above, the buffering Telnet proxy <b>206</b> can also be used for communications among user computers (not shown) on a LAN <b>202</b>. In such cases, the second network interface <b>504</b> can be omitted. Optionally, the second network interface <b>504</b> is also connected to the LAN <b>202</b>.

p-0062In some embodiments, the network interfaces <b>502</b> and <b>504</b> facilitate the conversion (translation) of messages (packets, etc.) received over the LAN <b>202</b> or over the Internet <b>208</b> according to a variety of protocols into messages according to a common message format for processing by an operating system or other control software. An exemplary operating system is Data ONTAP®, available from Network Appliance, Inc. of Sunnyvale, Calif. However, any suitable operating system that is capable of receiving and translating data from multiple protocols is acceptable.

p-0063A central processing unit (CPU) <b>506</b> and a memory <b>508</b> are also connected to the bus <b>500</b>. The memory <b>508</b> can be random access memory (RAM), read-only memory (ROM), flash memory or any other memory suitable for storing the operating system, control software or other instructions and data. If the authentication database <b>302</b> (<figref idrefs="DRAWINGS">FIG. 3</figref>) is connected to the Telnet proxy <b>206</b>, then an I/O interface <b>510</b> and a storage device <b>512</b> are also connected to the bus <b>500</b>.

p-0064The network interfaces <b>502</b> and <b>504</b> and the I/O interface <b>510</b> and the storage device <b>512</b> (if present) are controlled by the CPU <b>506</b> executing the operating system, control software or other instructions stored in the memory <b>508</b> to perform the functions described herein. The Telnet proxy <b>206</b> of <figref idrefs="DRAWINGS">FIG. 5</figref> optionally includes other components, such as a compact disc read-only memory (CD-ROM) drive, a compact flash (CF) or secure digital (SD) slot or another mechanism for reading from a removable medium, such as for installing or updating instructions in the memory <b>508</b>. Optionally, the Telnet proxy <b>206</b> includes an interface configured to receive these instructions over a wired or wireless network or link.

p-0065Optionally, the Telnet proxy <b>206</b> can be combined with, or included in, a Network Attached Storage (NAS) device, Storage Area Network (SAN) device, NAS/SAN device, storage system, server, gateway or the like. The user computers <b>200</b> (<figref idrefs="DRAWINGS">FIG. 2</figref>), servers <b>210</b>-<b>216</b> and other clients may be general-purpose computers configured to execute applications under the control of a variety of operating systems, including the UNIX® and Microsoft® Windows® operating systems. These computers may utilize file-based or block-based access protocols when accessing information in a storage system over a NAS-based or SAN-based network, respectively. Therefore, each computer may request the services of the storage system by issuing access protocol messages (in the form of packets) to the storage system over the network. For example, a computer running the Windows operating system may communicate with the storage system using the Common Internet File System (CIFS) protocol over TCP/IP. On the other hand, a computer running the UNIX operating system may communicate with the storage system using the Network File System (NFS) protocol over TCP/IP. It will be apparent to those skilled in the art that other computers running other types of operating systems may also communicate with the storage system, also known as a multi-protocol storage appliance, using other file access protocols. As noted, messages received by the storage system according to various protocols from various clients are translated for execution by an operating system of the storage system.

Flowchart

p-0066<figref idrefs="DRAWINGS">FIG. 6</figref> (<i>a</i>-<i>c</i>) is a flowchart of operations performed by the Telnet proxy <b>206</b>. At <b>600</b>, a client computer connects to the Telnet proxy. At <b>602</b>, the Telnet proxy negotiates a limited set of options with the client computer. This limited set of options can include “go ahead” and echo. At <b>604</b>, other option negotiation requests are accepted and buffered. At <b>606</b>, a user is authenticated, such as by validating user-entered credentials. At <b>608</b>, the user's credentials and access rights, such as information indicating which remote servers the user may access, are stored.

p-0067At <b>610</b>, the user requests a Telnet connection to a remote server. At <b>612</b>, the user's access rights, relative to the requested remote server, are checked. If the user is not permitted to access the requested remote server, control passes to <b>614</b>, at which an error message is displayed. After the error message is displayed, control passes to <b>616</b> (<figref idrefs="DRAWINGS">FIG. 6</figref><i>c</i>), where the transaction is logged.

p-0068If, as determined at <b>612</b> (<figref idrefs="DRAWINGS">FIG. 6</figref><i>a</i>), the user is permitted to access the requested remote server, control passes to <b>618</b>. At <b>618</b>, option negotiation requests from the client are accepted and stored, without responding to the client. As indicated in comment <b>619</b>, any other character data received from the client is buffered and echoed according to the then-current echo option setting.

p-0069At <b>620</b> (<figref idrefs="DRAWINGS">FIG. 6</figref><i>b</i>), a Telnet connection is established to the requested remote server using the user credentials stored at <b>608</b>. If the Telnet connection is not successfully established, control passes from <b>622</b> to <b>624</b>, where an error message is displayed and control is subsequently passed to <b>616</b>, where the transaction is logged. If the Telnet connection is successfully established, control passes from <b>622</b> to <b>626</b>, where the options stored at <b>618</b> are sent to the remote server. As indicated in comment <b>627</b>, any other character data received from the remote server is buffered and echoed according to the then-current echo option setting.

p-0070At <b>628</b>, responses are received from the remote server in response to the option negotiation requests that were sent to the remote server at <b>626</b>. At <b>630</b>, the received option negotiation responses are forwarded to the client. At <b>632</b>, any character data that has been received from the client or the server and has been buffered is sent to the other party, i.e. the data buffers are flushed. At <b>634</b>, pass-through mode is entered, during which character data and commands received from either party are forwarded to the other party.

p-0071At <b>636</b> (<figref idrefs="DRAWINGS">FIG. 6</figref><i>c</i>), the client or the remote server ends the Telnet connection. At <b>616</b>, the transaction is logged, as discussed above. At <b>638</b>, if the user logs off the Telnet proxy, control passes to <b>640</b>, where the stored user's credentials and access rights are deleted. On the other hand, if the user does not log off, control returns to <b>610</b> (<figref idrefs="DRAWINGS">FIG. 6</figref><i>a</i>) to await a request by the user to be connected to the same or a different remote server.

Integration with other Proxied Protocols

p-0072Optionally, the buffering Telnet proxy described herein can be combined with, or included in, Network Attached Storage (NAS) devices Storage Area Network (SAN) devices, NAS/SAN devices, storage systems, servers, gateways and the like that include Internet proxy, caching, access control, content filtering, virus scanning, and/or other services. For example, the buffering Telnet proxy can be included in a device that also proxies connections established using other protocols, such as HTTP, FTP over HTTP, FTP over TCP, Gopher, SSL, NNTP, MMS, RTSP, ICAP, CIFS and/or IPv6. For example, as shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, one or more of the user computers <b>200</b> can access other servers, such as FTP server <b>210</b>, web (HTTP) server <b>212</b> and/or NNTP server <b>216</b> via the buffering Telnet proxy <b>206</b>. In such cases, the buffering Telnet proxy <b>206</b> includes, or can be included in, a device to serve the other protocols. Such a proxy is referred to herein as an “multi-protocol proxy.” The memory <b>508</b> (<figref idrefs="DRAWINGS">FIG. 5</figref>) can include instructions for the CPU <b>506</b> to handle these other protocols.

p-0073Optionally, the multi-protocol proxy uses a common set of user authentication information to allow or deny user requests for connections using various protocols and/or to various servers <b>210</b>-<b>216</b> (<figref idrefs="DRAWINGS">FIG. 2</figref>). Whenever the multi-protocol proxy receives a request from an unknown user computer <b>200</b> for a connection to a server <b>210</b>-<b>216</b> (regardless of protocol), the multi-protocol proxy prompts the user for credentials, as described above with respect to the buffering Telnet proxy. Once the multi-protocol proxy obtains information regarding the user's rights, such as from the local authentication database <b>302</b> (<figref idrefs="DRAWINGS">FIG. 3</figref>) or from the authentication server <b>204</b>, the multi-protocol proxy stores this information in the data store <b>308</b> in association with an identification of the user's computer <b>200</b>. As noted above, this identification can be, for example, the computer's IP address. If the multi-protocol proxy obtains credentials that can be used to log in to one or more of the remote servers <b>210</b>-<b>216</b> on behalf of the user, these credentials are also stored.

p-0074If the multi-protocol proxy subsequently receives a request from the same user's computer <b>200</b> to connect to the same or to a different server <b>210</b>-<b>214</b> (using the same or a different protocol), the multi-protocol proxy need not again prompt the user for credentials. Instead, the multi-protocol proxy uses the identity of the user's computer <b>200</b> to retrieve the associated user's access rights and/or credentials from the data store <b>308</b>. Based on the retrieved user's access rights and the requested server and/or protocol, the multi-protocol proxy either establishes a connection to the requested remote server <b>210</b>-<b>214</b> or denies the user access to the server, as described above with respect to the buffering Telnet proxy <b>206</b>. If user credentials are stored for the accessed remote server <b>210</b>-<b>214</b>, the multi-protocol proxy uses these credentials to log in to the remote server on behalf of the user, as discussed above.

p-0075Thus, the first time a user accesses one of the remote servers <b>210</b>-<b>214</b>, the multi-protocol proxy obtains information about the user or the user's computer <b>200</b>, and the multi-protocol proxy uses this information to handle subsequent requests from the same user or computer. Consolidating user authentication in this manner streamlines the user's access to the remote servers <b>210</b>-<b>214</b>, because the user need not provide credentials each time the user wishes to access a different server. Consolidating user authentication also simplifies system management, because user rights and stored credentials (for logging in on behalf of the user) can be centrally stored and managed. Furthermore, the multi-protocol proxy provides a consolidated log of all connections, and it can enforce connection limits, such as a maximum number of concurrent connections initiated by a single user's computer <b>200</b> or a maximum total connection time per day per user's computer.

p-0076Optionally, the information about the user's access rights and remote credentials is deleted from the data store <b>308</b> after a predetermined amount of time, in response to an explicit request from the user or in response to the user terminating the last of a set of concurrent connections through the multi-protocol proxy. This prevents one user's access rights or stored credentials from mistakenly or maliciously being used on behalf of another user.

p-0077The multi-protocol proxy also facilitates use of legacy computer systems. For example, assume a legacy computer system includes a user authentication component, such as a username/password processor. If an organization institutes a new authentication regime, the multi-protocol proxy acts as a front-end to the legacy system. The multi-protocol proxy provides user authentication (as described above) and logs in to the legacy system on behalf of users, so the users can switch to the new authentication regime, without continuing to explicitly use the legacy computer system's authentication regime.

p-0078As discussed above with respect to the buffering Telnet proxy, the multi-protocol proxy can be interposed between two parties, such as between a user computer <b>200</b> (<figref idrefs="DRAWINGS">FIG. 8</figref>) and a conventional proxy, between a user computer and a server (e.g. an FTP, HTTP, Telnet, NNTP, etc. server), between a conventional proxy and a server, etc.

p-0079A buffering Telnet proxy that accepts communication option negotiation commands from a client before establishing a Telnet connection between the client and a host has been described. In other embodiments, buffering proxies perform similar functions according to other communication protocols.

p-0080The buffering Telnet proxy has been described as logging into a remote server on behalf of a user. Although Telnet is commonly used for communication between a user and a remote server, Telnet and other communication protocols can also be used for communication between pairs of application programs, i.e. without user involvement. In these circumstances, the buffering proxy logs in to the remote server on behalf of the client application program. Thus, the term “account entity” means the user, application programs or other entity that has an account on the remote server.

p-0081A buffering Telnet proxy and a multi-protocol proxy have been described as including a processor controlled by instructions stored in a memory. Those skilled in the art should readily appreciate that instructions or programs defining the functions of the present invention can be delivered to a processor in many forms, including, but not limited to, information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment), information alterably stored on writable storage media (e.g. floppy disks and hard drives) or information conveyed to a computer through communication media. In addition, while the invention may be embodied in software, the functions necessary to implement the invention may alternatively be embodied in part or in whole using firmware and/or hardware components, such as Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs) or other hardware or some combination of hardware, software and/or firmware components.

p-0082While the invention is described through the above-described exemplary embodiments, it will be understood by those of ordinary skill in the art that modifications to, and variations of, the illustrated embodiments may be made without departing from the inventive concepts disclosed herein. Moreover, while the preferred embodiments are described in connection with various illustrative data structures, one skilled in the art will recognize that the system may be embodied using a variety of data structures. Accordingly, the invention should not be viewed as limited, except by the scope and spirit of the appended claims.