Network connection controlling method and system thereof

The present invention relates to a firewall technique for interconnecting the Internet and a LAN (Local Area Network), and for securely protecting the resources within the LAN while permitting accesses made from the Internet to the LAN.

Conventionally, a firewall was arranged with a packet filtering method or a filtering method as an application gateway. These methods are intended to determine whether or not to permit an access from an outside to an inside for each service.

With the firewall for protecting in-house resources from an illegal attack from outside when an in-house LAN is connected to the Internet, all accesses are prohibited by default, and only a particular individual access is permitted.

Therefore, with the current filtering method which respectively recognizes a service and a user as first and second standards, almost all network services become unavailable and even legal users cannot receive useful Internet services.

If network services are made available outside and inside a company depending on need in order to satisfy the recently diversified demands of in-house users, data from many services are allowed to pass through the firewall. As a result, it becomes difficult to maintain security.

Additionally, using a remote access method which is currently becoming popular, login to an in-house LAN machine is permitted after authentication checking is made. Accordingly, even a single attack can possibly cause serious damage.

As described above, with the conventional methods, if the number of services which can externally use in-house resources increases, the possibility that the in-house resources, which must be protected, can be exposed to danger becomes great.

This invention was developed in the above described background, and aims at significantly improving the degree of convenience of a firewall, and at securing a security level equivalent to that of a conventional technique by changing a filtering method.

The present invention assumes a network connection controlling method for interconnecting an external network (a network outside a company) and a local area network (a network inside a company).

In an embodiment of the invention, authentication checking is made for a user within an external network (a user of a client machine 301) when the user accesses a local area network (an authentication checking server 101).

Next, a resource request to access a resource within the local area network is received from the user based on the result of the authentication checking (a resource managing server 102).

Then, an access right to the resource within the local area network, is calculated in terms of level or extent (categorised or graded) based on the resource request and the result of the authentication checking (the resource managing server 102).

As a result, an access to the resource is made based on the calculated access right (the resource managing server 102) (e.g. to a calculated level of access).

Here, the accessed resource is transmitted as a mobile code to the client machine operated by the user. The client machine access the data within the resource by receiving and executing the mobile code.

In the above method, filtering is performed by recognizing a user and a service as first and second standards, so that it becomes possible to protect in-house resources from external attacks and to satisfy the diversified demands of in-house users in accordance with the respective policies for respective users, that is, all company employees are permitted to make any accesses by default, while external users are prohibited from making any accesses by default.

Additionally, a change is made from the conventional method for permitting login to a machine within an in-house network after authentication checking is made, to the method for externally transmitting only a requested in-house resource, thereby making the scale of damage which can possibly occur with a single attack less than that of a conventional technique.

More specifically, the distinction between text information such as electronic mail received within a company, multimedia information, etc., and the application program data of a system under development, is not made, and they are defined to be in-house resources. The applications inside and outside the company can be linked and operate together.

As described above, in an embodiment of the invention, the degree of convenience of a firewall can be significantly improved by changing a filtering method, and moreover, the security mechanism is duplicated by checking user authentication and controlling each access to in-house resources, thereby ensuring the security level equivalent to that of a conventional technique.

Reference is made, by way of example, to the accompanying drawings in which: <ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 is a block diagram showing the configuration of a system according to a preferred embodiment of the present invention (No. 1);</li><li>Fig. 2 is a block diagram showing the configuration of the system according to the preferred embodiment of the present invention (No. 2);</li><li>Fig. 3 is a schematic diagram explaining the operations according to the preferred embodiment of the present invention (No. 1) ;</li><li>Fig. 4 is a schematic diagram explaining the operations according to the preferred embodiment of the present invention (No. 2);</li><li>Fig. 5 is a schematic diagram explaining the operations according to the preferred embodiment of the present invention (No. 3) ;</li><li>Fig. 6 is a schematic diagram explaining the operations according to the preferred embodiment of the present invention (No. 4);</li><li>Fig. 7 shows the sequence for establishing a service between a client and a server;</li><li>Fig. 8 shows the procedure sequence at an update (in the case where there is almost no time difference between when a resource is received and when a rewrite operation is performed);</li><li>Fig. 9 shows the procedure sequence at an update (in the case where there is a time difference between when a resource is received and when a rewrite operation is performed);</li><li>Fig. 10 exemplifies a client application program;</li><li>Fig. 11 exemplifies a gate keeper program; and</li><li>Fig. 12 exemplifies a resource manager program.</li></ul>

Provided below is the explanation about the details of the preferred embodiment according to the present invention.

<Characteristics of the Preferred Embodiment According to the Present Invention>

This preferred embodiment is characterized in that filtering is performed by respectively recognizing a user and a service as first and second standards, so that it becomes possible to protect in-house resources from external attacks, and also to satisfy the diversified demands of in-house users in accordance with the respective policies for respective users, that is, company employees are permitted to make any accesses by default, while external users are prohibited from making any accesses by default.

Additionally, this preferred embodiment is characterized in that the scale of damage which can be possibly caused by a single attack can be made less than that of a conventional technique by changing the conventional method for permitting login to a machine included in an in-house network after authentication checking is made, to the method for transmitting only a requested in-house resource.

More specifically, according to this preferred embodiment, the distinction between in-house resources, for example, between text information such as electronic mail received within a company, multimedia information, etc., and the application program data of a system under development, is not made, and an application possessed inside the company is defined to be one of the in-house resources, whereby applications inside and outside the company can be linked and operate together.

As described above, according to this preferred embodiment, the degree of convenience of a firewall can be significantly improved by changing a filtering method, and additionally, the security mechanism is duplicated by checking user authentication and by controlling each access to in-house resources, thereby ensuring the security level equivalent to that of a conventional technique.

<Configuration of the Preferred Embodiment According to the Present Invention>

Fig. 1 is a block diagram showing the configuration of the system according to the preferred embodiment of the present invention.

An authentication checking server 101, which is arranged within an in-house network, comprises at least one service request port for receiving a plurality of types of service requests such as telnet, ftp, http, etc., and has a mechanism for checking user authentication. This server 101 is connected to the Internet via an ISP (Internet Service Provider) 104 included in an external network.

A resource managing server 102, which is arranged within the in-house network, has a capability for managing the resources within the in-house network, and has a mechanism for restricting an access right to each of the in-house resources depending on the attribute or the degree of reliability of a user. This server 102 is connected to the authentication checking server 101.

Note that the resource managing server 102 and the authentication checking server 101 may be directly connected as shown in Fig. 1, or may be connected via a packet filtering router 201 as shown in Fig. 2.

An individual server 103, which is arranged within the in-house network, provides a variety of services such as telnet, ftp, http, etc. This server 103 may be the same server as the resource managing server 102.

<Principle of the Operations According to the Preferred Embodiment of the Present Invention>

Provided next is the explanation about the principle of the operations of the configuration according to the above described preferred embodiment.

A user ID and an authentication password are registered to the authentication checking server 101 beforehand.

If a user ID is not registered to the authentication checking server 101, the corresponding user is recognized to be an external user.

A pass-phrase or an one-time password, etc., which are used by a public key encrypting system, can be adopted as the authentication password, while an electronic mail address is adopted as the user ID.

A user who desires to access an in-house resource makes a connection to the authentication checking server 101, and transmits a service request, the user ID, and the authentication password to the authentication checking server 101.

The authentication checking server 101 which has received the service request calculates the degree of reliability of the user by making a matching between the received user ID and authentication password, and the registered user ID and authentication password.

The authentication checking server 101 then opens a port (socket) for a client machine as the preparation for accepting the resource request.

The client machine transmits the logical name of a desired in-house resource to the port as a resource request. The resource specification is made with a URL (Uniformed or Universal Resource Locator).

The authentication checking server 101 transmits to the resource managing server 102 the resource request transmitted from the client machine and the degree of reliability of the user, which is calculated beforehand.

Upon receipt of the resource request and the degree of reliability of the user from the authentication checking server 101, the resource managing server 102 detects the individual server 103 which provides the specified in-house resource, according to the logical name of the in-house resource included in the resource request. Furthermore, the resource managing server 102 determines an access right to the requested in-house resource according to the degree of reliability of the user, which is received from the authentication checking server 101, transmits the resource request and the access right to the individual server 103, and requests the program code (mobile code) which provides the requested in-house resource.

The individual server 103 which receives the resource request and the access right from the resource managing server 102, generates the mobile code, and embeds a requested resource, a program for accessing the resource,the individual settings such as the access right received from the resource managing server 102, a client identification code, the expiry date of the program, etc. in the generated mobile code. Then, the individual server 103 returns the mobile code to the resource managing server 102.

Upon receipt of the mobile code from the individual server 103, the resource managing server 102 returns it to the authentication checking server 101.

Upon receipt of the mobile code from the resource managing server 102, the authentication checking server 101 encrypts the mobile code by using the registered password (such as a public key, etc.) of the user who has issued the resource request, and returns the encrypted mobile code to the client machine which has issued the resource request.

The client machine which has received the encrypted mobile code extracts the secret key of the user by using the pass-phrase that the user has transmitted to the authentication checking server 101 at the time of the authentication checking, decrypts the encrypted mobile code with the secret key, and executes the program of the mobile code. Consequently, the in-house resource requested by the user is reproduced on the client machine.

The in-house resource reproduced on the client machine rejects an access request which violates the access -right by referencing the access right and the client identification code, which are embedded in the resource itself.

<Specific Operations According to the Preferred Embodiment of the Present Invention>

Sequentially provided below are the explanations about the specific operations according to the preferred embodiment of the present invention, by referring to the schematic diagrams explaining the operations shown in Figs. 3 through 6, the sequences shown in Figs. 7 through 9, and the program examples shown in Figs. 10 through 12.

The explanations to be provided below assume that the authentication checking by the authentication checking server 101 is made based on the public key encrypting system, a pass-phrase is used as the authentication password, and an electronic mail address is used as the user ID.

The authentication checking server 101 has a pair of the electronic mail address and the public key of a user as user information.

In the authentication checking server 101, a gate keeper 303, as shown in Fig. 3, which is a server program for making the authentication checking, leaves only the authentication checking port (socket) open. Whatever network service is used, the connection to this port is first made, and then the authentication checking is made. When the gate keeper 303 opens the above described port, for example, the program code shown in step 1 of Fig. 11 is executed.

If a user requests a network service within an in-house network by executing a client application 302 (Fig. 3) of a client machine 301, an authentication checking request is first issued from the client machine 301 to the authentication checking server 101 (S1 of Fig. 7). In this case, the client application 302 executes, for example, the program codes shown in steps 1 and 2 of Fig. 10. The authentication checking server 101 is specified in step 1, while the connection to the authentication checking port of the authentication checking server 101 is made in step 2.

If the connection to the authentication checking server 101 is successfully made, the user inputs his or her user ID and authentication password by using the window displayed on the client machine 301. The user ID is the electronic mail address of the user, while the authentication password is the pass-phrase used when the public and secret keys are generated.

Upon receipt of the user ID and the authentication password from the client machine 303, the gate keeper 303 included in the authentication checking server 101 decrypts the authentication password by using the public key of the user, and determines whether or not the received user ID is registered to a user database, which is not shown in Fig. 3 but is included in the authentication checking server 101, and whether or not the received authentication password matches any authentication password stored in the user database, if the user ID is registered (S2 of Fig. 7). In this case, the gate keeper 303 executes, for example, the program codes shown in steps 2 and 3 of Fig. 11. The process for receiving the user ID and the authentication password is performed in step 2, while the process for checking authentication is performed in step 3.

Next, the gate keeper 303 calculates the degree of reliability of the user by referencing the above described user database with the result of the authentication checking (S2 of Fig. 7). In this case, the gate keeper 303 executes, for example, the program code shown in step 4 of Fig. 11.

If the electronic mail address of the user, which is the user ID, is registered in the user database and if the authentication password is legal, a high degree of reliability is provided to the user so that he or she can use many services.

If the user ID is not registered in the user database, this user is recognized to be an external user and a low degree of reliability is provided to the user. In this case, only services which do not require the authentication checking, such as the acceptance of electronic mail addressed to an in-house user, etc. are provided.

If the authentication password is illegal although the user ID is registered to the user database, this access is determined to be an attack and is rejected.

If the authentication checking is properly made, the gate keeper 303 secures the port (socket) for accepting the resource request issued from the user (permission/connection port), and activates a relay server for relaying resource associated information, which is communicated between the client machine 301 and the resource managing server 102, in correspondence with the secured port. Then, the gate keeper 303 notifies the client machine 301 of the above described permission/connection port (S3 of Fig. 7). In this case, the gate keeper 303 executes, for example, the program codes shown in steps 5 through 8 of Fig. 11. In step 5, it is determined whether or not the degree of reliability is higher than a threshold. In step 6, the number of the permission/connection port is dynamically secured. In step 7, the relay server using this port number is activated. In step 8, the above described port number is notified to the client machine 301 if the relay server is successfully activated.

When the permission/connection port is notified from the authentication checking server 101, the client application 302 executed by the client machine 301 assembles the resource request in a predetermined data format, extracts the secret key by receiving from the user the pass-phrase for extracting the secret key of the user, and encrypts the resource request with the secret key. Then, the client application 302 transmits the encrypted resource request by using the notified port (S4 of Fig. 7). In this case, the client application 302 executes, for example, the code shown in step 3 of Fig. 10.

The relay server, which is operated by the authentication checking server 101, decrypts the resource request received from the client machine 301 with the public key corresponding to the user who has transmitted the request, embeds in the decrypted resource request the degree of reliability, which is calculated for this user (S2 of Fig. 7), and transmits the resource request to the resource managing server 102 (S5 of Fig. 7).

The resource manager 304 (shown in Fig. 3), which is operated by the resource managing server 102, has the mechanism for providing an external user via an external network with the directory for searching for the individual server 103 which provides the in-house resource corresponding to the logical name of an in-house resource, and for determining the access right from the client machine 301 to the in-house resource.

More specifically, the resource managing server 102 parses the resource request, extracts the resource name and the degree of reliability of the user, and calculates the access right to the resource by using the extracted information, upon receipt of the resource request from the authentication checking server 101 (S6 of Fig. 7). The access right includes, for example, the right to perform a read /write operation for an in-house user, the right to perform only a read operation for an external user, the right to prohibit an access to a confidential resource for an external user, etc. In this case, the resource manager 304 executes, for example, the program codes shown in steps 1 through 3 of Fig. 12. In step 1, the process for receiving a resource request is performed. In step 2, a data set "p", which includes the resource name and the degree of reliability of a user, is extracted by performing the process for parsing the received resource request. In step 3, the process for calculating the access right to the data set "p" is performed.

Note that the determination of the access right may be made by the individual server 103.

Next, the resource managing server 102 searches for the individual server 103 which provides the network service corresponding to the parsed resource request, transmits the parsed resource request and the access right to the searched individual server 103, and requests the relay agent which is the above described mobile code for providing the requested in-house resource (S7 of Fig. 7). In this case, the resource manager 304 executes, for example, the program codes shown in steps 4 and 5 of Fig. 12. It is determined whether or not a permissible access right can be obtained in step 4, while the resource request, the access right, and the request of the relay agent are transmitted to the individual server 103 in step 5.

The individual server 103, which has received the resource request, the access right, and the request of the relay agent from the resource managing server 102, generates the requested relay agent, and embeds in the generated relay agent the individual settings such as the access right received from the resource managing server, the client identification code, the expiry date of the program, etc. (S8 of Fig. 7). This relay agent is written as a mobile code, for example, in JAVA provided by Sun Microsystems. The relay agent can freely move within in-house and external networks, and includes the contents of an in-house resource and the interface (method) for accessing the contents.

The individual server 103 then returns the relay agent to the resource managing server 102 as shown in Fig. 4 (S9 of Fig. 7).

Upon receipt of the relay agent, the resource manager 304 operated by the resource managing server 102 returns the relay agent to the authentication checking server 101 (S10 of Fig. 7). In this case, the resource manager 304 executes, for example, the program code shown in step 6 of Fig. 12.

Upon receipt of the relay agent, as shown in Fig. 4, the above described relay server operated by the authentication checking server 101 encrypts the relay agent with the registered public key of the user who has transmitted the resource request (the key represented within the authentication checking server 101 of Fig. 4), and returns the encrypted relay agent to the client machine 301 which has transmitted the resource request (S11 of Fig. 7).

The client machine 301 which has received the encrypted relay agent extracts the secret key of the user with the pass-phrase that the user has transmitted to the authentication checking server 101 at the time of the authentication checking, decrypts the encrypted relay agent 401 with the secret key (the key represented within the client machine 301 of Fig. 4), and executes the program of the relay agent (S12 of Fig. 7). In this case, the client application 302 run by the client machine 301 executes, for example, the program codes shown in steps 4 through 6 of Fig. 10. In step 4, it is determined whether or not the relay agent 401 has been received. In step 5, the relay agent 401 is decrypted. In step 6, the decrypted relay agent 401 is executed.

Consequently, the in-house resource requested by the user is reproduced on the client machine 301. The user can access the in-house resource reproduced on the client machine 301 within the client machine 301 itself asynchronously to the individual server 103 included in the in-house network, as shown in Fig. 5.

The relay agent 401 executed by the client machine 301 rejects an access request which violates the access right by referencing the access right and the client identification code, which are embedded in the agent 401 itself.

Provided next is the explanation about the case where a data rewrite request to an in-house resource occurs within the client machine 301, by referring to the schematic diagram explaining the operations shown in Fig. 6 and the sequences shown in Fig. 8 and 9. Fig. 8 shows the sequence used when there is almost no time difference between when an in-house resource is received by the client machine 301 and when a rewrite request is issued. Fig. 9 shows the sequence used when there is a time difference. The explanation will be provided by referring to both of Figs. 8 and 9.

When a rewrite request occurs within the client machine 301 (S1 of Fig. 8 or 9), the relay agent 401 executed by the client machine 301 checks the access right of the user who has issued the request according to the code included in the request (52 of Fig. 8 or 9).

If the access is permissible, the relay agent 401 issues an authentication checking request to the authentication checking server 101 (S3 of Fig. 8 or 9. This authentication checking request includes a user ID and an authentication password in a similar manner as in S1 of Fig. 7).

Upon receipt of the user ID and the authentication password from the client machine 301, the gate keeper 303 included in the authentication checking server 101 checks an amount of time elapsed from the connection start of the corresponding the user (S4 of Fig. 8 or S4' of Fig. 9).

If the amount of elapsed time is equal to or smaller than a predetermined amount, and if the permission/connection port (refer to S3 of Fig. 7) for accepting the resource request from the user is still open, the gate keeper 303 notifies the client machine 301 of this permission/connection port (S5 of Fig. 8).

If the amount of elapsed time is longer than a predetermined amount, and if the permission/connection port for accepting the resource request from the user is closed, the gate keeper 303 performs the authentication checking and the reliability degree calculation process in the similar manner as in S2 of Fig. 7 (S4' of Fig. 9), and notifies the client machine 301 of the resultantly secured permission/connection port (S5 of Fig. 9).

When the permission/connection port is notified from the authentication checking server 101, the relay agent 401 executed by the client machine 301 assembles the rewrite request in a predetermined data format in a similar manner as in S4 of Fig. 7, extracts the secret key of the user with the pass-phrase that the user has transmitted to the authentication checking server 101 at the time of the authentication checking, and encrypts the rewrite request including a new content to be rewritten to an in-house resource by using the secret key. Next, the relay agent 401 transmits the encrypted rewrite request by using the notified port (S6 of Fig. 8 or 9).

The relay server executed by the authentication checking server 101 decrypts the encrypted rewrite request received from the client machine 301 with the public key corresponding to the user who has transmitted the request, embeds in the decrypted rewrite request the degree of reliability, which was previously (in the case shown in Fig. 8) or is newly (in the case shown in Fig. 9) calculated, and transmits the rewrite request to the resource managing server 102 (S7 of Fig. 8 or 9).

Upon receipt of the rewrite request from the authentication checking server 101, the resource manager 304 operated by the resource managing server 102 parses this request, extracts the resource name and the degree of reliability of the user, and calculates the access right to the resource by using the extracted information in a similar manner as in S6 of Fig. 7 (S8 of Fig. 8 or 9).

The resource managing sever 102 searches for the individual server 103 which provides the network service corresponding to the parsed rewrite request, and transmits the parsed rewrite request and the access right to the searched individual server 103 (S9 of Fig. 8 or 9).

The individual server 103 which has received the rewrite request and the access right from the resource managing server 102 rewrites the content included in the rewrite request to the in-house resource based on the access right.

When the rewrite operation is successfully performed, the notification of the success of the rewrite operation is returned from the individual server 103 to the client machine 301, and the rewrite process is completed (S10 of Fig. 8 or 9).

The relay agent 401 executed by the client machine 301 automatically terminates its process, if the amount of elapsed execution time exceeds the expiry date set within the relay agent 401 itself.