CA2394479C - Secure gateway having routing feature - Google Patents
Secure gateway having routing feature Download PDFInfo
- Publication number
- CA2394479C CA2394479C CA2394479A CA2394479A CA2394479C CA 2394479 C CA2394479 C CA 2394479C CA 2394479 A CA2394479 A CA 2394479A CA 2394479 A CA2394479 A CA 2394479A CA 2394479 C CA2394479 C CA 2394479C
- Authority
- CA
- Canada
- Prior art keywords
- gateway
- server
- proxy server
- identifier
- client computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/30—Types of network names
- H04L2101/33—Types of network names containing protocol addresses or telephone numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
Abstract
A computer system provides authenticated access for a client computer (18) over an insecure, public network (26) to one of a plurality of destination servers (28) on private, secure network, through the use of a client-side X.509 digital certificate.
A firewall (32) is disposed between the insecure, public network (26) and the private network. A demilitarized zone (DMZ) proxy server (34) intercepts messages destined for the destination servers (28), and forwards the intercepted messages through the firewall (32) to a gateway (38) on the private network. The gateway (38) is configured to create a cookie, based on the selection of one of several applications (30) available on the private network. The cookie contains an identifier sufficient to identify the destination server (28) corresponding to the selected application (30). Messages from the client computer include the cookie. The gateway (38) processes the cookie and appends the identifier on a destination URL portion of the messages for routing. An alternate computer system authenticates a user of a remote client computer on the insecure network site (26) of the firewall (32) using a user identification and password.
A firewall (32) is disposed between the insecure, public network (26) and the private network. A demilitarized zone (DMZ) proxy server (34) intercepts messages destined for the destination servers (28), and forwards the intercepted messages through the firewall (32) to a gateway (38) on the private network. The gateway (38) is configured to create a cookie, based on the selection of one of several applications (30) available on the private network. The cookie contains an identifier sufficient to identify the destination server (28) corresponding to the selected application (30). Messages from the client computer include the cookie. The gateway (38) processes the cookie and appends the identifier on a destination URL portion of the messages for routing. An alternate computer system authenticates a user of a remote client computer on the insecure network site (26) of the firewall (32) using a user identification and password.
Description
SECURE GATEWAY HAVING ROUTING FEATURE
TECHNICAL FIELD
The present invention relates generally to communications systems 1o and networks, and, more particularly, to a secure gateway for providing access from a client computer over an insecure public network to one of a plurality of destination servers on a secure private network.
BACKGROUND
Computer networks are known generally as including a wide variety of computing devices, such as client computers and servers, interconnected by various connection media. In particular, it is commonplace for an institution, such as a corporation, to provide such a network. Such network may include a multiplicity of servers executing a corresponding number of application programs ("applications"). The corporation's employees may use one or more of these applications to carry out the business of the corporation. Such a network may be characterized as a private, secure network, since it is accessible under normal, expected operating conditions only by suitably authorized individuals.
It has become increasingly popular, and in many instances a business necessity, for users ("clients") to remotely access the private network.
While the remote access is sometimes accomplished through dedicated, secure lines, it is increasingly done through the global communications network known as the Internet. Computer networks, particularly the Internet, can be vulnerable
TECHNICAL FIELD
The present invention relates generally to communications systems 1o and networks, and, more particularly, to a secure gateway for providing access from a client computer over an insecure public network to one of a plurality of destination servers on a secure private network.
BACKGROUND
Computer networks are known generally as including a wide variety of computing devices, such as client computers and servers, interconnected by various connection media. In particular, it is commonplace for an institution, such as a corporation, to provide such a network. Such network may include a multiplicity of servers executing a corresponding number of application programs ("applications"). The corporation's employees may use one or more of these applications to carry out the business of the corporation. Such a network may be characterized as a private, secure network, since it is accessible under normal, expected operating conditions only by suitably authorized individuals.
It has become increasingly popular, and in many instances a business necessity, for users ("clients") to remotely access the private network.
While the remote access is sometimes accomplished through dedicated, secure lines, it is increasingly done through the global communications network known as the Internet. Computer networks, particularly the Internet, can be vulnerable
-2-to security breaches. In particular, the Internet is generally considered insecure, in view of its widespread access and use by the public at-large. Accordingly, a problem arises as to how to securely allow the client access to the resources available on the private, secure network (e.g., the applications) over a generally insecure public network, such as the Internet.
One general approach taken in the art has been to employ various encryption schemes. For example, a protocol known as a Secure Sockets Layer (SSL) protocol protects information transmitted across the insecure Internet using encryption. Another known authentication scheme involves the use of a so-lo called digital certificate, which also uses encryption. As used, the digital certificate can be attached to an electronic message to verify to the recipient that the sender is who the sender claims to be. A well-known and widely accepted standard for digital certificates is ITU X.509=
While the above-described techniques are effective for what they purport to accomplish, providing access to a private, secure network over an insecure network such as the Internet requires a comprehensive combination of many security features. Accordingly, it is also known in the art to securely provide remote access by way of a gateway architecture. One known gateway architecture includes a firewall, a web server, an information collector (IC), an application message router (AMR), and an authorization handler.
The firewall is between the private, secure network and the public, insecure network. The web server and the information collector are on the insecure, public network side of the firewall. The web server communicates with the information collector using the well-known Gateway Interface (CGI), the specification for transferring information between a web server and a CGI
program. The AMR and the authorization handler are on the private, secure network side of the firewall. The IC and AMR communicate through the firewall by way of an interprocess communication (IPC) mechanism. In this known gateway architecture, a user wishing to gain access to an application on the private network first accesses the web server using a conventional web browser.
The user authenticates him or herself by providing a digital certificate.
One general approach taken in the art has been to employ various encryption schemes. For example, a protocol known as a Secure Sockets Layer (SSL) protocol protects information transmitted across the insecure Internet using encryption. Another known authentication scheme involves the use of a so-lo called digital certificate, which also uses encryption. As used, the digital certificate can be attached to an electronic message to verify to the recipient that the sender is who the sender claims to be. A well-known and widely accepted standard for digital certificates is ITU X.509=
While the above-described techniques are effective for what they purport to accomplish, providing access to a private, secure network over an insecure network such as the Internet requires a comprehensive combination of many security features. Accordingly, it is also known in the art to securely provide remote access by way of a gateway architecture. One known gateway architecture includes a firewall, a web server, an information collector (IC), an application message router (AMR), and an authorization handler.
The firewall is between the private, secure network and the public, insecure network. The web server and the information collector are on the insecure, public network side of the firewall. The web server communicates with the information collector using the well-known Gateway Interface (CGI), the specification for transferring information between a web server and a CGI
program. The AMR and the authorization handler are on the private, secure network side of the firewall. The IC and AMR communicate through the firewall by way of an interprocess communication (IPC) mechanism. In this known gateway architecture, a user wishing to gain access to an application on the private network first accesses the web server using a conventional web browser.
The user authenticates him or herself by providing a digital certificate.
-3-The web server forwards the particulars of the digital certificate to the IC according to a CGI script. The information collector, in turn, forwards the digital certificate through the firewall to the AMR via the IPC mechanism. The AMR, also via an IPC mechanism, queries the authorization handler to authenticate the user. The authorization handler's response is sent back to the AMR. If the user is successfully authenticated, access is permitted. There are, however, several shortcomings to this approach.
First, the information collector and application message router are custom programmed software applications. Accordingly, they must be ported for io each new platform used. This platform dependence results in increased costs (and delays) when implemented on new platforms.
Second, the known gateway has throughput limitations. The CGI
interface is relatively slow, as is the IC-to-AMR link because, among other things, the IPC mechanism is single-threaded.
Third, certain data (e.g., static HTML, graphics, etc.) is more vulnerable to security breaches (i.e., being "hacked") because it is maintained on the web server, on the Internet (insecure) side of the private network firewall.
This situation is undesirable.
Another known gateway for providing access to a private network over an insecure network involves a two-level client-side digital certificate authentication mechanism. One proxy server is provided for every application on the private network, which are disposed on the Internet side of the firewall.
One of the proxy servers performs a first level check of the digital certificate, and then passes the digital certificate data through the firewall via HTTPS for the second-level check by an authorization server. While this configuration addresses some of the shortcomings described above, routing in this approach is relatively inefficient for multiple applications (i.e., requires multiple proxy servers).
In addition, some applications on the private network do not require digital certificate strength authentication. In these situations for known gateway architectures there is no authentication of the user outside of the firewall (i.e., the gateways described above authenticate, at least at some level, before allowing further access across the firewall for complete authentication).
First, the information collector and application message router are custom programmed software applications. Accordingly, they must be ported for io each new platform used. This platform dependence results in increased costs (and delays) when implemented on new platforms.
Second, the known gateway has throughput limitations. The CGI
interface is relatively slow, as is the IC-to-AMR link because, among other things, the IPC mechanism is single-threaded.
Third, certain data (e.g., static HTML, graphics, etc.) is more vulnerable to security breaches (i.e., being "hacked") because it is maintained on the web server, on the Internet (insecure) side of the private network firewall.
This situation is undesirable.
Another known gateway for providing access to a private network over an insecure network involves a two-level client-side digital certificate authentication mechanism. One proxy server is provided for every application on the private network, which are disposed on the Internet side of the firewall.
One of the proxy servers performs a first level check of the digital certificate, and then passes the digital certificate data through the firewall via HTTPS for the second-level check by an authorization server. While this configuration addresses some of the shortcomings described above, routing in this approach is relatively inefficient for multiple applications (i.e., requires multiple proxy servers).
In addition, some applications on the private network do not require digital certificate strength authentication. In these situations for known gateway architectures there is no authentication of the user outside of the firewall (i.e., the gateways described above authenticate, at least at some level, before allowing further access across the firewall for complete authentication).
-4-There is therefore a need to provide an improved gateway that minimizes or eliminates one or more of the shortcomings as set forth above.
SUMMARY
A computer system according to the present invention provides an improved mechanism for routing. Client computers are provided access over the Internet to one of several applications on the private network via a proxy server on the Internet side of a firewall and a gateway on the private network side.
The 1o proxy server is configured to forward messages to the gateway, which handles the routing functions to all of the destination applications, in substitution of the multiple proxy servers required by known gateway systems. Thus, a reduced number of proxy servers are needed for providing access to multiple applications, reducing cost and complexity.
A computer system is provided according to the present invention that allows access from a client computer over an insecure public network to a selected one of a plurality of destination servers on a secure private network each executing a corresponding application. The computer system includes a proxy server, and a gateway. The proxy server is configured to establish a secure connection with the client computer over the insecure, public network. The gateway is disposed between the proxy server and the private network.
According to the invention, the gateway includes means for appending, prior to routing, an identifier to a message received from the client computer destined for the selected destination server. The identifier is associated with the selected destination server. In addition, the gateway further includes means for routing the message to the selected destination server as a function of the identifier.
In a preferred embodiment, the identifier comprises a character string associate with the application to which the user of the remote client computer is provided access. The gateway is configured to create a cookie containing the identifier wherein subsequent requests made by the client computer also include the cookie containing the identifier. Through the foregoing, the identification of the selected application is known by the gateway.
SUMMARY
A computer system according to the present invention provides an improved mechanism for routing. Client computers are provided access over the Internet to one of several applications on the private network via a proxy server on the Internet side of a firewall and a gateway on the private network side.
The 1o proxy server is configured to forward messages to the gateway, which handles the routing functions to all of the destination applications, in substitution of the multiple proxy servers required by known gateway systems. Thus, a reduced number of proxy servers are needed for providing access to multiple applications, reducing cost and complexity.
A computer system is provided according to the present invention that allows access from a client computer over an insecure public network to a selected one of a plurality of destination servers on a secure private network each executing a corresponding application. The computer system includes a proxy server, and a gateway. The proxy server is configured to establish a secure connection with the client computer over the insecure, public network. The gateway is disposed between the proxy server and the private network.
According to the invention, the gateway includes means for appending, prior to routing, an identifier to a message received from the client computer destined for the selected destination server. The identifier is associated with the selected destination server. In addition, the gateway further includes means for routing the message to the selected destination server as a function of the identifier.
In a preferred embodiment, the identifier comprises a character string associate with the application to which the user of the remote client computer is provided access. The gateway is configured to create a cookie containing the identifier wherein subsequent requests made by the client computer also include the cookie containing the identifier. Through the foregoing, the identification of the selected application is known by the gateway.
-5-Other objects, features, and advantages of the present invention will become apparent to one skilled in the art from the following detailed description and accompanying drawings illustrating features of this invention by way of example, but not by way of limitation.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will now be described by way of example, with reference to the accompanying drawings, in which:
Figure 1 is a simplified block diagram view of a first computer system according to the present invention;
Figure 2 is a simplified block diagram of the system of Figure i, showing the communications in greater detail;
Figure 3 is a more detailed block diagram of a message passed between the proxy server and the gateway of Figure 1;
Figure 4A is a more detailed block diagram of cookies created by the system of the present invention;
Figure 4B is a more detailed block diagram of a mechanism for routing messages to one of multiple applications;
Figure 5 is a simplified flow chart diagram showing the operation of a gateway proxy server of Figure 1;
Figure 6 is a block diagram showing the steps in obtaining a digital certificate for use with the system of Figure 1;
Figure 7 is a simplified block diagram of a second computer system in accordance with the present invention; and, Figure 8 is a simplified flow chart diagram showing the operation of the second system of Figure 7.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will now be described by way of example, with reference to the accompanying drawings, in which:
Figure 1 is a simplified block diagram view of a first computer system according to the present invention;
Figure 2 is a simplified block diagram of the system of Figure i, showing the communications in greater detail;
Figure 3 is a more detailed block diagram of a message passed between the proxy server and the gateway of Figure 1;
Figure 4A is a more detailed block diagram of cookies created by the system of the present invention;
Figure 4B is a more detailed block diagram of a mechanism for routing messages to one of multiple applications;
Figure 5 is a simplified flow chart diagram showing the operation of a gateway proxy server of Figure 1;
Figure 6 is a block diagram showing the steps in obtaining a digital certificate for use with the system of Figure 1;
Figure 7 is a simplified block diagram of a second computer system in accordance with the present invention; and, Figure 8 is a simplified flow chart diagram showing the operation of the second system of Figure 7.
-6-DETAILED DESCRIPTION
Referring now to the drawings wherein like reference numerals are used to identify identical components in the various views, Figure 1 is a simplified block diagram of a computer system useful for authenticating a user 18, namely, computer system 20, a first embodiment of the present invention. In the illustrated, first embodiment, authentication of the user 18 occurs through the use of digital certificates, such as ITU X.5o9 digital certificates. It should be understood that such digital certificates may be transferred to other client 1o computers 22. It is the user 18 that is being authenticated, not the client computer 22.
Computer system 20 is configured generally to provide access by user 18 of a client computer 22 to one of a plurality of software applications 241, 242,..., 243= Such access is over an insecure network 26, such as the publicly used Internet, to a private, secure network where applications 241, 242, ..., 243 reside.
Each application 241, 242, ..., 243 includes a respective web server (hereinafter "destination server") 281, 282, ..., 283, and an application program 301, 302, ..., 303. Computer system 20 includes a firewall system 32, a proxy server 34 with a plug-in 36, an application gateway 38 comprising a gateway proxy server 40 with a plug-in 42 and a gateway web server 44, and an authorization server 46. Also shown in Figure 1 is an Information Security block 48, a certificate authority 50, a first secure connection 52, a second secure connection 54, and a third secure connection 56.
Computer system 20 overcomes many of the shortcomings of prior gateway systems by providing a platform independent implementation via the use of commercial-of-the-shelf (COTS) components, as well as enhanced throughput via the use of SSL-based hypertext transfer protocol (HTTPS) for secure and fast messaging across the firewall. In addition, sensitive data is maintained on the secure, private network side of the firewall 32, not on the insecure, public network side of firewall, reducing the opportunity for hackers to breach security.
Referring now to the drawings wherein like reference numerals are used to identify identical components in the various views, Figure 1 is a simplified block diagram of a computer system useful for authenticating a user 18, namely, computer system 20, a first embodiment of the present invention. In the illustrated, first embodiment, authentication of the user 18 occurs through the use of digital certificates, such as ITU X.5o9 digital certificates. It should be understood that such digital certificates may be transferred to other client 1o computers 22. It is the user 18 that is being authenticated, not the client computer 22.
Computer system 20 is configured generally to provide access by user 18 of a client computer 22 to one of a plurality of software applications 241, 242,..., 243= Such access is over an insecure network 26, such as the publicly used Internet, to a private, secure network where applications 241, 242, ..., 243 reside.
Each application 241, 242, ..., 243 includes a respective web server (hereinafter "destination server") 281, 282, ..., 283, and an application program 301, 302, ..., 303. Computer system 20 includes a firewall system 32, a proxy server 34 with a plug-in 36, an application gateway 38 comprising a gateway proxy server 40 with a plug-in 42 and a gateway web server 44, and an authorization server 46. Also shown in Figure 1 is an Information Security block 48, a certificate authority 50, a first secure connection 52, a second secure connection 54, and a third secure connection 56.
Computer system 20 overcomes many of the shortcomings of prior gateway systems by providing a platform independent implementation via the use of commercial-of-the-shelf (COTS) components, as well as enhanced throughput via the use of SSL-based hypertext transfer protocol (HTTPS) for secure and fast messaging across the firewall. In addition, sensitive data is maintained on the secure, private network side of the firewall 32, not on the insecure, public network side of firewall, reducing the opportunity for hackers to breach security.
-7-Before proceeding to a detailed description of computer system 20, a general overview of the operation established by the invention will be set forth, as viewed by user 18 of client computer 22. Initially, user 18 of client computer 22 enters the destination URL into a web browser portion of client computer 22.
The web browser then issues an HTI'P request across insecure network 26, which is routed to proxy server 34. The user 18 may then be presented with a "popup"
message that a secure network connection is about to be established. The message may also ask which X.5o9 digital certificate user 18 wishes to use for authentication. The user-selected X.5o9 digital certificate is then sent to proxy 1o server 34. At this point, a first level authentication is conducted, outside the firewall, by proxy server 34 (e.g., checks to see whether the X.5o9 certificate has been issued by a predetermined preapproved certificate authority). If authenticated at this level, proxy server 34 then sends the information contained in the client's digital certificate through firewall system 32 to gateway 38 to be authenticated at a second, more substantive level. The second level authentication involves examining the particulars of the X.5o9 digital certificate using the data stored on authorization server 46. If user 18 is authorized to access multiple applications, the next item after the "popup" message to be displayed to user 18 is an "options page", presenting the multiple choices.
Once a particular application is selected, the next item to be displayed for user 18 is a welcome page of the selected application. Secure, authenticated remote access is complete. In accordance with the present invention, computer system 20 provides an efficient mechanism for routing the remote user 18 of client computer 22 to the selected application being served by one of the destination servers.
With continued reference to Figure 1, client computer 22 may be any one of a plurality of conventional computing devices, such as, for example only, a personal computer (PC) running a Microsoft Windows operating system (e.g., Windows 95, Windows NT, Windows 2000), a Macintosh computer (Apple Computer) or a UNIX workstation. Client computer 22 is preferably configured to include a web browser, such as, for example only, Netscape Communicator Version 4.7, commercially available from Netscape Communications Corporation.
The web browser portion of client computer 22 preferably includes the *
Trade Mark
The web browser then issues an HTI'P request across insecure network 26, which is routed to proxy server 34. The user 18 may then be presented with a "popup"
message that a secure network connection is about to be established. The message may also ask which X.5o9 digital certificate user 18 wishes to use for authentication. The user-selected X.5o9 digital certificate is then sent to proxy 1o server 34. At this point, a first level authentication is conducted, outside the firewall, by proxy server 34 (e.g., checks to see whether the X.5o9 certificate has been issued by a predetermined preapproved certificate authority). If authenticated at this level, proxy server 34 then sends the information contained in the client's digital certificate through firewall system 32 to gateway 38 to be authenticated at a second, more substantive level. The second level authentication involves examining the particulars of the X.5o9 digital certificate using the data stored on authorization server 46. If user 18 is authorized to access multiple applications, the next item after the "popup" message to be displayed to user 18 is an "options page", presenting the multiple choices.
Once a particular application is selected, the next item to be displayed for user 18 is a welcome page of the selected application. Secure, authenticated remote access is complete. In accordance with the present invention, computer system 20 provides an efficient mechanism for routing the remote user 18 of client computer 22 to the selected application being served by one of the destination servers.
With continued reference to Figure 1, client computer 22 may be any one of a plurality of conventional computing devices, such as, for example only, a personal computer (PC) running a Microsoft Windows operating system (e.g., Windows 95, Windows NT, Windows 2000), a Macintosh computer (Apple Computer) or a UNIX workstation. Client computer 22 is preferably configured to include a web browser, such as, for example only, Netscape Communicator Version 4.7, commercially available from Netscape Communications Corporation.
The web browser portion of client computer 22 preferably includes the *
Trade Mark
-8-capabilities of transmitting, receiving, and verifying digital certificates, such as ITU X.5o9 digital authentication certificates. In addition, the web browser portion preferably includes the capability of establishing first secure connection 52 with proxy server 34 via, for example, the publicly available Secure Sockets Layer (SSL) protocol, Version 3.0, available from Netscape Communications Corp. As illustrated in Figure 1, first secure connection 52 is designated an "HTTPS" connection, indicating the use of the SSL protocol. Of course, other mechanisms for establishing a secure connection, such as the S-HTTP protocol may also be used; provided, however, that both ends are compatible with such to other protocol. Connection 52 may be based on a TCP/IP, network connection protocol.
Applications 24,, 242,..., 243, particularly programs 301, 302, ..., 303 thereof, exist independently of computer system 20. That is, no modifications to programs 301, 302, ..., 303, are required for use with computer system 20. For example, applications 241, 242, ..., 243, may involve Carrier Access Billing, Subscription Services (e.g., long distance carriers), and the like.
Destination servers 281, 282,..., 283, are preferably compatible with the ubiquitous HyperText Transfer Protocol (HTTP 1.1), which is employed over connections 58, 6o, and 62. Destination servers 281, 282, ..., 283 interface computer system 20 with respective programs 301, 302, ...,303- In effect, remote user 18 provides the web browser, and the application being accorded secure access provides the destination server. Computer system 20 provides the remainder of the needed connectivity and security.
Firewall system 32 is disposed between insecure public network 26 and the secure, private network on which the applications 241, 242,...,243, reside and execute. Firewall system 32 may be implemented in software, hardware, or both. Firewall system 32 is configured to examine all messages destined for, or exiting from, the private, secure network, and to block those that do not meet predetermined security criteria. One criteria involves the destination location on the private network for incoming messages. In this regard, firewall system 32 restricts communication originating from the insecure network 26, only allowing passage of messages destined for application gateway 38 on the private network
Applications 24,, 242,..., 243, particularly programs 301, 302, ..., 303 thereof, exist independently of computer system 20. That is, no modifications to programs 301, 302, ..., 303, are required for use with computer system 20. For example, applications 241, 242, ..., 243, may involve Carrier Access Billing, Subscription Services (e.g., long distance carriers), and the like.
Destination servers 281, 282,..., 283, are preferably compatible with the ubiquitous HyperText Transfer Protocol (HTTP 1.1), which is employed over connections 58, 6o, and 62. Destination servers 281, 282, ..., 283 interface computer system 20 with respective programs 301, 302, ...,303- In effect, remote user 18 provides the web browser, and the application being accorded secure access provides the destination server. Computer system 20 provides the remainder of the needed connectivity and security.
Firewall system 32 is disposed between insecure public network 26 and the secure, private network on which the applications 241, 242,...,243, reside and execute. Firewall system 32 may be implemented in software, hardware, or both. Firewall system 32 is configured to examine all messages destined for, or exiting from, the private, secure network, and to block those that do not meet predetermined security criteria. One criteria involves the destination location on the private network for incoming messages. In this regard, firewall system 32 restricts communication originating from the insecure network 26, only allowing passage of messages destined for application gateway 38 on the private network
-9-(e.g., gateway proxy server 40). Firewall system 32 may comprise conventional apparatus known to those of ordinary skill in the art. For example, firewall system 32 may comprise commercially available apparatus referred to as a CheckPoint One firewall, from Check Point Software Technologies, Inc., Redwood City, California, USA.
Proxy server 34 is disposed on the insecure public network side of firewall system 32, in a so-called Demilitarized Zone (DMZ). A DMZ is located between the insecure network 26 (e.g., the Internet) and the private network's first line of defense, for example, firewall system 32. DMZ proxy server 34 is io disposed between client computer 22 and the real servers associated with the substantive applications, namely, destination servers 281, 282, ..., 283.
Proxy servers in general may be characterized as providing both mapping and data caching functions. In the context of the present invention, DMZ proxy server is provided principally for mapping purposes.
DMZ proxy server 34 is further configured to establish first secure connection 52 with client computer 22, particularly the web browser portion thereof. The HTTPS connection 52 provides for the encryption of the information passing between client computer 22 and DMZ proxy server 34. It should be understood that other suitably secure connection protocols may be used, for example, secure HTTP (S-HTTP); provided, however, that both ends are compatible with such other protocol.
DMZ proxy server 34 is still further configured to perform a first level authentication of the user of client computer 22. In one embodiment DMZ
proxy server 34 is programmed to examine the X.5o9 digital certificate provided by client computer 22 to determine whether it issued from a predetermined, preapproved Certificate Authority. DMZ proxy server 34, in this embodiment, does not compare the particulars of the X.5o9 digital certificate with information on file for authentication. This is because the information required to conduct such a comparison is safely stored behind firewall system 32 on authorization server 46 on the private network. DMZ proxy server 34 may comprise conventional hardware and software known to those in the art. For example,
Proxy server 34 is disposed on the insecure public network side of firewall system 32, in a so-called Demilitarized Zone (DMZ). A DMZ is located between the insecure network 26 (e.g., the Internet) and the private network's first line of defense, for example, firewall system 32. DMZ proxy server 34 is io disposed between client computer 22 and the real servers associated with the substantive applications, namely, destination servers 281, 282, ..., 283.
Proxy servers in general may be characterized as providing both mapping and data caching functions. In the context of the present invention, DMZ proxy server is provided principally for mapping purposes.
DMZ proxy server 34 is further configured to establish first secure connection 52 with client computer 22, particularly the web browser portion thereof. The HTTPS connection 52 provides for the encryption of the information passing between client computer 22 and DMZ proxy server 34. It should be understood that other suitably secure connection protocols may be used, for example, secure HTTP (S-HTTP); provided, however, that both ends are compatible with such other protocol.
DMZ proxy server 34 is still further configured to perform a first level authentication of the user of client computer 22. In one embodiment DMZ
proxy server 34 is programmed to examine the X.5o9 digital certificate provided by client computer 22 to determine whether it issued from a predetermined, preapproved Certificate Authority. DMZ proxy server 34, in this embodiment, does not compare the particulars of the X.5o9 digital certificate with information on file for authentication. This is because the information required to conduct such a comparison is safely stored behind firewall system 32 on authorization server 46 on the private network. DMZ proxy server 34 may comprise conventional hardware and software known to those in the art. For example,
-10-DMZ proxy server 34 may comprise Netscape proxy server software, commercially available from Netscape Communications Corporation.
Plug-in 36 is associated with DMZ proxy server 34, and is configured to provide enhanced functionality. As will be described in greater detail below, in a preferred embodiment, plug-in 36 is configured to capture the particular details of the X.5o9 digital certificate, and forward those details across firewall system 32 to gateway proxy server 40. Through this functionality, the user i8 of client computer 22 can be safely authenticated on the private network side of firewall system 32.
Application gateway 38 is disposed on the private network side of firewall system 32, between DMZ proxy server 34 and applications 241, 242, ..., 243. Gateway 38 includes gateway proxy server 4o and gateway web server 44.
Gateway proxy server 40 is configured to establish second secure connection 54 across firewall system 32 with DMZ proxy server 34. In one embodiment, secure connection 54 comprises an HTTPS connection, although other secure protocols may be employed as described above; provided, however, that both ends are compatible with such other protocol. In response to DMZ proxy server 34's request to establish secure connection 54, gateway proxy server 40 presents its X.5o9 digital certificate, and requests that DMZ proxy server 34 present its X.509 digital certificate by a return message. This handshaking is well understood in the art, and will not be elaborated on in any further detail. It is described, however, to emphasize that the X.5o9 digital certificate being presented to gateway proxy server 4o belongs to DMZ proxy server 34, not the user 18 of client computer 22. The commercially available software on DMZ proxy server 34 does not have built-in capabilities to perform this information forwarding step according to the invention. Accordingly, as described above, plug-in 36 is provided as part of the solution to this problem. The other part of the solution, authorization plug-in 42, is configured, among other things, to extract the data embedded in the message from DMZ proxy server 34 corresponding to the data in the client's certificate. Plug-in 36 (capture and embed) and plug-in 42 (extract and parse) work hand-in-hand in passing the information in the client's digital certificate across firewall system 32 for authentication.
Plug-in 36 is associated with DMZ proxy server 34, and is configured to provide enhanced functionality. As will be described in greater detail below, in a preferred embodiment, plug-in 36 is configured to capture the particular details of the X.5o9 digital certificate, and forward those details across firewall system 32 to gateway proxy server 40. Through this functionality, the user i8 of client computer 22 can be safely authenticated on the private network side of firewall system 32.
Application gateway 38 is disposed on the private network side of firewall system 32, between DMZ proxy server 34 and applications 241, 242, ..., 243. Gateway 38 includes gateway proxy server 4o and gateway web server 44.
Gateway proxy server 40 is configured to establish second secure connection 54 across firewall system 32 with DMZ proxy server 34. In one embodiment, secure connection 54 comprises an HTTPS connection, although other secure protocols may be employed as described above; provided, however, that both ends are compatible with such other protocol. In response to DMZ proxy server 34's request to establish secure connection 54, gateway proxy server 40 presents its X.5o9 digital certificate, and requests that DMZ proxy server 34 present its X.509 digital certificate by a return message. This handshaking is well understood in the art, and will not be elaborated on in any further detail. It is described, however, to emphasize that the X.5o9 digital certificate being presented to gateway proxy server 4o belongs to DMZ proxy server 34, not the user 18 of client computer 22. The commercially available software on DMZ proxy server 34 does not have built-in capabilities to perform this information forwarding step according to the invention. Accordingly, as described above, plug-in 36 is provided as part of the solution to this problem. The other part of the solution, authorization plug-in 42, is configured, among other things, to extract the data embedded in the message from DMZ proxy server 34 corresponding to the data in the client's certificate. Plug-in 36 (capture and embed) and plug-in 42 (extract and parse) work hand-in-hand in passing the information in the client's digital certificate across firewall system 32 for authentication.
-11-Gateway proxy server 40 further performs well-known mapping functions, and, in accordance with the present invention, efficiently routes messages destined for various applications 241, 242, ..., 243 to the appropriate one of the destination servers 281, 282, ..., 283. Gateway proxy server 40 may comprise conventional apparatus known to those of ordinary skill in the art, such as, for example, Netscape proxy server software running on conventional hardware.
Gateway proxy server 40 is further configured to establish third secure connection 56 within gateway 38 with web server 44. Connection 56 may 1o be established as described above with respect to secure connection 54.
Web server 44 is configured to store various HTML files and graphics, which will be served to client computer 22. In particular, the HTML
and graphic files associated with computer system 20 authentication and authorization administration are resident on application gateway server 38.
More particularly, web server 44 is configured to provide an "options page" to client computer 22 when user 18 is authenticated and authorized for more than one of applications 241, 242, ..., 243= It should be understood that the use of the word "web" server should not necessarily be limited by any one or more of the meanings ascribed in the art, but rather, only by the appended claims. It is important to note that this data is stored on the secure, private network side of firewall 32, reducing the opportunity for hackers to breach security and access or destroy this data.
Authorization server 46 is preferably disposed on the private network side of firewall system 32. This arrangement minimizes the risk of unauthorized access to or destruction of the sensitive data maintained thereon, since a would-be hacker would have to penetrate the firewall for such activities to occur. In one embodiment, gateway proxy server 4o and authorization server 46 conduct messaging between each other in accordance with a so-called Lightweight Directory Access Protocol (LDAP). Accordingly, authorization server 46 comprises an LDAP-capable server. The information maintained by authorization server 46 includes the particulars of the X.5o9 digital certificate tendered by the user 18 of client computer 22, the identification of applications
Gateway proxy server 40 is further configured to establish third secure connection 56 within gateway 38 with web server 44. Connection 56 may 1o be established as described above with respect to secure connection 54.
Web server 44 is configured to store various HTML files and graphics, which will be served to client computer 22. In particular, the HTML
and graphic files associated with computer system 20 authentication and authorization administration are resident on application gateway server 38.
More particularly, web server 44 is configured to provide an "options page" to client computer 22 when user 18 is authenticated and authorized for more than one of applications 241, 242, ..., 243= It should be understood that the use of the word "web" server should not necessarily be limited by any one or more of the meanings ascribed in the art, but rather, only by the appended claims. It is important to note that this data is stored on the secure, private network side of firewall 32, reducing the opportunity for hackers to breach security and access or destroy this data.
Authorization server 46 is preferably disposed on the private network side of firewall system 32. This arrangement minimizes the risk of unauthorized access to or destruction of the sensitive data maintained thereon, since a would-be hacker would have to penetrate the firewall for such activities to occur. In one embodiment, gateway proxy server 4o and authorization server 46 conduct messaging between each other in accordance with a so-called Lightweight Directory Access Protocol (LDAP). Accordingly, authorization server 46 comprises an LDAP-capable server. The information maintained by authorization server 46 includes the particulars of the X.5o9 digital certificate tendered by the user 18 of client computer 22, the identification of applications
-12-241, 242, ===, 243 to which access by the user 18 has been authorized by an application trustee, and a gateway user identification (ID).
Information Security 48 is an entity that, in one embodiment, updates authorization server 46 with data obtained from both a trustee of an application and certificate authority 50. This process will be described in greater detail in connection with Figure 6. An administrative interface (not shown) is provided on authorization server 46, and allows any individual classified as an "admin" user to execute certain functions. These functions fall into three main categories: (i) user administration; (ii) application administration; and, (iii) 1o reports. For example, "admin" users may add or delete users, provide for user update/maintenance, provide user searches, add an application, attend to application maintenance, provide login access reports, provide inactive and/or expired user reports, and provide a user list report. The foregoing is exemplary only. Application administration is generally done by a respective application administration support group. However, application trustees are "admin" users and may access this interface as well.
Certificate authority 5o receives applications for X.5o9 digital certificates from potential users requesting access to applications on the private network. Certificate authority 50 issues an encrypted X.5o9 digital certificate containing the user's public key and a variety of other information. The particulars of the issued X.5o9 digital certificate are provided to authorization server 46 for authentication purposes. In one embodiment, a special purpose certificate authority is used to provide digital certificates for authenticating users 18. DMZ proxy server 34, in the described embodiment, only recognizes digital certificates from this special purpose certificate authority. However, it should be understood that other, commercially available certificate authorities, may be substituted for the special purpose certificate authority and remain within the spirit and scope of the present invention. In this case DMZ proxy server 34 may be reconfigured to accept digital certificates issued from other than the special purpose Certificate Authority. Known commercially available certificate authorities include GTE CyberTrust and VeriSign.
Information Security 48 is an entity that, in one embodiment, updates authorization server 46 with data obtained from both a trustee of an application and certificate authority 50. This process will be described in greater detail in connection with Figure 6. An administrative interface (not shown) is provided on authorization server 46, and allows any individual classified as an "admin" user to execute certain functions. These functions fall into three main categories: (i) user administration; (ii) application administration; and, (iii) 1o reports. For example, "admin" users may add or delete users, provide for user update/maintenance, provide user searches, add an application, attend to application maintenance, provide login access reports, provide inactive and/or expired user reports, and provide a user list report. The foregoing is exemplary only. Application administration is generally done by a respective application administration support group. However, application trustees are "admin" users and may access this interface as well.
Certificate authority 5o receives applications for X.5o9 digital certificates from potential users requesting access to applications on the private network. Certificate authority 50 issues an encrypted X.5o9 digital certificate containing the user's public key and a variety of other information. The particulars of the issued X.5o9 digital certificate are provided to authorization server 46 for authentication purposes. In one embodiment, a special purpose certificate authority is used to provide digital certificates for authenticating users 18. DMZ proxy server 34, in the described embodiment, only recognizes digital certificates from this special purpose certificate authority. However, it should be understood that other, commercially available certificate authorities, may be substituted for the special purpose certificate authority and remain within the spirit and scope of the present invention. In this case DMZ proxy server 34 may be reconfigured to accept digital certificates issued from other than the special purpose Certificate Authority. Known commercially available certificate authorities include GTE CyberTrust and VeriSign.
-13-Figure 2 shows the messaging that occurs between client computer 22, DMZ proxy server 34, gateway proxy server 4o and gateway web server 44.
User 18, via client computer 22, through its web browser, initiates a request for authenticated secure access to one of the destination servers on the private network, which is received by DMZ proxy server 34. Messages 66, 68 and 70 represent the handshaking involved with establishing the secure connection 52.
It bears emphasizing that user 18/client computer 22 only knows the Uniform Resource Locator (URL) of DMZ proxy server, not of the gateway proxy server or destination servers. DMZ proxy server 34 responds to the request 64 by 1o transmitting a return message 66.
Message 66 will be used to authenticate the identity of DMZ proxy server 34 to client computer 22. For example, DMZ proxy server 34 may send client computer 22 its digital certificate. The web browser portion of client computer 22 is configured to analyze such certificate, and to authenticate DMZ
proxy server 34. Message 66 will also contain a request to tender information sufficient to authenticate the user 18 of client computer 22 to the private network containing the applications 241, 242,...,243- In this regard message 66 may cause a "popup" list to be presented to user 18 of client computer 22, soliciting the user's selection of a X.5o9 digital certificate.
The X.5o9 digital certificate so selected is transmitted in a message 68 back to DMZ proxy server 34. If the tendered X.5o9 digital certificate meets certain minimum, first level authentication requirements, further handshaking may occur, designated at message 70, as required to establish the secure connection 52, shown in Figure 1. Further messages between client computer 22 and DMZ proxy server 34 are encrypted in accordance with a session key known to both client computer 22 and DMZ proxy 34. In one embodiment, DMZ proxy server 34 checks to see whether the digital certificate has been issued by a preapproved, certificate authority.
A second level authentication is commenced with a message 72.
3o This authentication is done by comparing data from the digital certificate provided by client computer 22 with predetermined data about the certificate on authorization server 46. To secure the transfer of the digital certificate across
User 18, via client computer 22, through its web browser, initiates a request for authenticated secure access to one of the destination servers on the private network, which is received by DMZ proxy server 34. Messages 66, 68 and 70 represent the handshaking involved with establishing the secure connection 52.
It bears emphasizing that user 18/client computer 22 only knows the Uniform Resource Locator (URL) of DMZ proxy server, not of the gateway proxy server or destination servers. DMZ proxy server 34 responds to the request 64 by 1o transmitting a return message 66.
Message 66 will be used to authenticate the identity of DMZ proxy server 34 to client computer 22. For example, DMZ proxy server 34 may send client computer 22 its digital certificate. The web browser portion of client computer 22 is configured to analyze such certificate, and to authenticate DMZ
proxy server 34. Message 66 will also contain a request to tender information sufficient to authenticate the user 18 of client computer 22 to the private network containing the applications 241, 242,...,243- In this regard message 66 may cause a "popup" list to be presented to user 18 of client computer 22, soliciting the user's selection of a X.5o9 digital certificate.
The X.5o9 digital certificate so selected is transmitted in a message 68 back to DMZ proxy server 34. If the tendered X.5o9 digital certificate meets certain minimum, first level authentication requirements, further handshaking may occur, designated at message 70, as required to establish the secure connection 52, shown in Figure 1. Further messages between client computer 22 and DMZ proxy server 34 are encrypted in accordance with a session key known to both client computer 22 and DMZ proxy 34. In one embodiment, DMZ proxy server 34 checks to see whether the digital certificate has been issued by a preapproved, certificate authority.
A second level authentication is commenced with a message 72.
3o This authentication is done by comparing data from the digital certificate provided by client computer 22 with predetermined data about the certificate on authorization server 46. To secure the transfer of the digital certificate across
-14-firewall 32, DMZ proxy server 34 and gateway proxy server 4o establish second secure connection 54, shown in Figure 1. It bears emphasizing that DMZ proxy server 34 only knows the URL of application gateway proxy server 40, not the URL of the destination servers. Only the mapping information for the gateway proxy server 40, which is kept in a local configuration file (behind the firewall), provides the URL/addresses of the destination servers.
One challenge, as described above, pertains to how the user of client computer's digital certificate is passed through firewall 32 for authentication.
Plug-in 36 associated with DMZ proxy server 34 is configured to extract the 1o digital certificate from the incoming message and pass it to gateway proxy server 40 in an HTTP header, as part of an HTTPS message 72.
Gateway proxy server 40 in turn passes information from the digital certificate tendered by the user of client computer 22 to authorization server 46, preferably in accordance with the LDAP protocol. Authorization server 46 returns authentication data indicative of whether the provided digital certificate successfully authenticates the user of client computer 22, as well as the identification of the applications 241, 242, ..., 243 to which access by the user 18 has been authorized. This information is returned, in a manner to be described in greater detail below, to DMZ proxy server 34 by gateway proxy server 4o by message 74. When the user is authorized for multiple applications, the user's browser is redirected to server 44.
Client computer 22 requests, by way of message 76, resources from gateway web server 44. Gateway web server 44 serves up the requested resource, namely an "options page", to client computer 22 in message 78. The "options page" presents a list of authorized applications 241, 242, ..., 243 for selection by user 18 of client computer 22.
The selection of one of the applications presented on the "options page" results in a message 8o being sent to DMZ proxy server 34. Message 8o is an HTTP command (over secure connection 54, thus HTTPS) that includes a composite URL comprising a base URL and an appended identifier. DMZ proxy server 34 routes message 80, based on the composite URL, to gateway proxy
One challenge, as described above, pertains to how the user of client computer's digital certificate is passed through firewall 32 for authentication.
Plug-in 36 associated with DMZ proxy server 34 is configured to extract the 1o digital certificate from the incoming message and pass it to gateway proxy server 40 in an HTTP header, as part of an HTTPS message 72.
Gateway proxy server 40 in turn passes information from the digital certificate tendered by the user of client computer 22 to authorization server 46, preferably in accordance with the LDAP protocol. Authorization server 46 returns authentication data indicative of whether the provided digital certificate successfully authenticates the user of client computer 22, as well as the identification of the applications 241, 242, ..., 243 to which access by the user 18 has been authorized. This information is returned, in a manner to be described in greater detail below, to DMZ proxy server 34 by gateway proxy server 4o by message 74. When the user is authorized for multiple applications, the user's browser is redirected to server 44.
Client computer 22 requests, by way of message 76, resources from gateway web server 44. Gateway web server 44 serves up the requested resource, namely an "options page", to client computer 22 in message 78. The "options page" presents a list of authorized applications 241, 242, ..., 243 for selection by user 18 of client computer 22.
The selection of one of the applications presented on the "options page" results in a message 8o being sent to DMZ proxy server 34. Message 8o is an HTTP command (over secure connection 54, thus HTTPS) that includes a composite URL comprising a base URL and an appended identifier. DMZ proxy server 34 routes message 80, based on the composite URL, to gateway proxy
-15-server in a message 82. The identifier is sufficient for gateway proxy server 40 to route message 82 to the selected application 241, 242,...,243-Figure 3 shows a simplified representation of message 72 that includes the data from the digital certificate of user 18 of client computer 22.
Message 72 includes an HTTPS header 84, a plurality of HTTP headers 86, and a data portion 88. Note that DMZ proxy server 34 and gateway proxy server 40 message using secure connection 56, for example, using the SSL protocol (i.e., HTTPS). Accordingly, an HTTPS header 84 is used, while the payload, namely the HTTP headers 86 and the data portion 88, is encrypted. Plug-in 36 io associated with DMZ proxy server 34 is configured to capture the X.5o9 digital certificate tendered by the user 18 via client computer 22, and form one or more HTTP headers that, collectively, convey the data contained in the digital certificate as a whole to gateway proxy server 40. In one embodiment, plug-in may be implemented using standard application programming interfaces (API), for example, Netscape APIs (NSAPI) when Netscape proxy server software is used to implement DMZ proxy server 34.
Figure 4A shows several "cookies" created by gateway proxy server 40: an authentication cookie 90, an applications list cookie 92, and a selected-application cookie 94. A cookie message is given to a client (e.g., a web browser) by a server. The client will cache the cookie, and store the cookie in a file on the client computer 22 if the cookie is a so-called "persistent" cookie. In one embodiment, the cookies are non-persistent and are therefore only cached in memory, not stored in a file on client computer 22. A part of the message is a description of the range of URL's for which that cookie is valid, and a time for which the cookie will persist (again, for "persistent" cookies only). Any future HTTP requests by the client which fall within that range will include the current value of the cookie (e.g., state object) to the server. Since HTTP is a stateless protocol (i.e., each HTTP command is executed by the server independently, without any knowledge of the commands that came before it), the "cookie" is a mechanism to carry forward information.
As described above, authorization server 46 returns authentication data to gateway proxy server 40 indicative of whether the tendered digital
Message 72 includes an HTTPS header 84, a plurality of HTTP headers 86, and a data portion 88. Note that DMZ proxy server 34 and gateway proxy server 40 message using secure connection 56, for example, using the SSL protocol (i.e., HTTPS). Accordingly, an HTTPS header 84 is used, while the payload, namely the HTTP headers 86 and the data portion 88, is encrypted. Plug-in 36 io associated with DMZ proxy server 34 is configured to capture the X.5o9 digital certificate tendered by the user 18 via client computer 22, and form one or more HTTP headers that, collectively, convey the data contained in the digital certificate as a whole to gateway proxy server 40. In one embodiment, plug-in may be implemented using standard application programming interfaces (API), for example, Netscape APIs (NSAPI) when Netscape proxy server software is used to implement DMZ proxy server 34.
Figure 4A shows several "cookies" created by gateway proxy server 40: an authentication cookie 90, an applications list cookie 92, and a selected-application cookie 94. A cookie message is given to a client (e.g., a web browser) by a server. The client will cache the cookie, and store the cookie in a file on the client computer 22 if the cookie is a so-called "persistent" cookie. In one embodiment, the cookies are non-persistent and are therefore only cached in memory, not stored in a file on client computer 22. A part of the message is a description of the range of URL's for which that cookie is valid, and a time for which the cookie will persist (again, for "persistent" cookies only). Any future HTTP requests by the client which fall within that range will include the current value of the cookie (e.g., state object) to the server. Since HTTP is a stateless protocol (i.e., each HTTP command is executed by the server independently, without any knowledge of the commands that came before it), the "cookie" is a mechanism to carry forward information.
As described above, authorization server 46 returns authentication data to gateway proxy server 40 indicative of whether the tendered digital
-16-certificate successfully authenticated the user 18 of client computer 22, as well as an identification of applications 241, 242, ..., 243 for which access is authorized.
In response thereto, gateway proxy server 4o builds authentication cookie 90, and applications list cookie 92. Authentication cookie 9o may include information such as timestamp information indicating a time of successful authentication. Applications list cookie 92 may include an identification of the particular applications for which client computer 22 is authorized. If only one application is authorized, selected application cookie 94 is built containing a description of that application. If there are a plurality of authorized applications, io however, creation of the selected-application cookie 94 is deferred until after user 18 actually selects one of the applications from the "options page". The authentication cookie 9o and the application list cookie 92 are sent with message 74 to client computer 22 via DMZ proxy server 34, with a redirect to web server 44.
Cookies 9o and 92 are, in turn, provided (from client computer 22) with message 76 to gateway web server 44. Gateway web server 44, in turn, generates the "options page", using the information from applications list cookie 92. The HTML defining the "options page" is sent in message 78 to client computer 22.
Referring to Figure 4B, each listed application available for selection on the "options page" includes a respective composite URL 96 comprising a base URL 98 and an identifier loo. For example, base URL 98, as an example only, may be HTTPS://url-of-dmz-server. Identifier loo may be selected to identify or describe a particular one of the plurality of applications, but need not do so technically. For example, for a particular application 241, 242, ..., 243 involving billing, identifier loo, as an example only, may be "/billing" - - a character string symbolic of the application, including a "slash" character as prefix. The identifier 100, as a whole, is preferably appended to the base URL
as a suffix. The composite URL is sent in message 8o from client computer 22 through insecure network 26 to DMZ proxy server 34. DMZ proxy server 34 then maps the composite URL so as to route the incoming message 82 to gateway proxy server 40. This mapping may be a simple domain name replacement
In response thereto, gateway proxy server 4o builds authentication cookie 90, and applications list cookie 92. Authentication cookie 9o may include information such as timestamp information indicating a time of successful authentication. Applications list cookie 92 may include an identification of the particular applications for which client computer 22 is authorized. If only one application is authorized, selected application cookie 94 is built containing a description of that application. If there are a plurality of authorized applications, io however, creation of the selected-application cookie 94 is deferred until after user 18 actually selects one of the applications from the "options page". The authentication cookie 9o and the application list cookie 92 are sent with message 74 to client computer 22 via DMZ proxy server 34, with a redirect to web server 44.
Cookies 9o and 92 are, in turn, provided (from client computer 22) with message 76 to gateway web server 44. Gateway web server 44, in turn, generates the "options page", using the information from applications list cookie 92. The HTML defining the "options page" is sent in message 78 to client computer 22.
Referring to Figure 4B, each listed application available for selection on the "options page" includes a respective composite URL 96 comprising a base URL 98 and an identifier loo. For example, base URL 98, as an example only, may be HTTPS://url-of-dmz-server. Identifier loo may be selected to identify or describe a particular one of the plurality of applications, but need not do so technically. For example, for a particular application 241, 242, ..., 243 involving billing, identifier loo, as an example only, may be "/billing" - - a character string symbolic of the application, including a "slash" character as prefix. The identifier 100, as a whole, is preferably appended to the base URL
as a suffix. The composite URL is sent in message 8o from client computer 22 through insecure network 26 to DMZ proxy server 34. DMZ proxy server 34 then maps the composite URL so as to route the incoming message 82 to gateway proxy server 40. This mapping may be a simple domain name replacement
-17-function (e.g., replace url-of-dmz-server with url-of-gateway-server, so as to end up with HUPS:/%url-of-gateway-server identifier. Authorization plug-in 42 is configured to recognize the identifier (e.g.,"/billing"), and to create in response thereto the selected-application cookie 94.
Figure 5 is flow chart diagram showing the operation of authorization plug-in 42 associated with gateway proxy server 40.
In step 100, authorization plug-in 42 begins execution.
In step 102, authorization plug-in 42 checks to determine whether the incoming message contains a valid authentication cookie 9o. Validity 1o requires that the user's digital certificate has in-fact authenticated the user of the client computer 22, and, that the timestamp meets predetermined timing criteria (i.e., it must not be too old). In particular, the presence of authentication cookie go itself is indicative of a successful authentication. Because of the non-persistent nature of cookie 9o, cookie 9o does not come from a stored file, but only as a result of a successful authentication. Then, the remaining requirement is that the timing criteria be satisfied. In one embodiment, a cookie 9o older than, preferably, 12 hours is considered "invalid". In another embodiment, a cookie go older than 4 hours is considered "invalid". The length of time may be selected based on expected maximum session duration by user 18. If the answer is "NO", then the method branches to step 104.
In step 104, authorization plug-in 42 extracts and parses the user's X.5o9 digital certificate from message 72, shown in simplified form in Figure 3.
The method proceeds to step 1o6.
In step 106, authorization plug-in 42 associated with gateway proxy server 4o queries authorization server 46 for authentication of the user 18.
Plug-in 42 provides the X.5o9 digital certificate particulars in a message to authorization server 46. In step 1o8, authorization plug-in 42 determines the applications for which access by the user 18 is authorized, all through messaging with authorization server 46. In step, 11o, gateway proxy server 46 obtains an overall gateway user identification (ID) for the user. This gateway user ID
may facilitate access to and usage of the plurality of applications 241, 242, ..., 243. For example, the overall gateway user ID may be passed to the application, which
Figure 5 is flow chart diagram showing the operation of authorization plug-in 42 associated with gateway proxy server 40.
In step 100, authorization plug-in 42 begins execution.
In step 102, authorization plug-in 42 checks to determine whether the incoming message contains a valid authentication cookie 9o. Validity 1o requires that the user's digital certificate has in-fact authenticated the user of the client computer 22, and, that the timestamp meets predetermined timing criteria (i.e., it must not be too old). In particular, the presence of authentication cookie go itself is indicative of a successful authentication. Because of the non-persistent nature of cookie 9o, cookie 9o does not come from a stored file, but only as a result of a successful authentication. Then, the remaining requirement is that the timing criteria be satisfied. In one embodiment, a cookie 9o older than, preferably, 12 hours is considered "invalid". In another embodiment, a cookie go older than 4 hours is considered "invalid". The length of time may be selected based on expected maximum session duration by user 18. If the answer is "NO", then the method branches to step 104.
In step 104, authorization plug-in 42 extracts and parses the user's X.5o9 digital certificate from message 72, shown in simplified form in Figure 3.
The method proceeds to step 1o6.
In step 106, authorization plug-in 42 associated with gateway proxy server 4o queries authorization server 46 for authentication of the user 18.
Plug-in 42 provides the X.5o9 digital certificate particulars in a message to authorization server 46. In step 1o8, authorization plug-in 42 determines the applications for which access by the user 18 is authorized, all through messaging with authorization server 46. In step, 11o, gateway proxy server 46 obtains an overall gateway user identification (ID) for the user. This gateway user ID
may facilitate access to and usage of the plurality of applications 241, 242, ..., 243. For example, the overall gateway user ID may be passed to the application, which
-18-may use it to look up in its local database user profile information describing what functions the user is allowed to perform in the particular application. A
gateway user ID cookie may be set to implement this information passing. Steps 106 - no may be performed sequentially, or as a composite request, or in any other way known in the art.
In step 112, authorization plug-in 42 builds authentication cookie 90, and applications list cookie 92, as described above.
In step 114, plug-in 42, through gateway proxy server 40, transmits cookie 90 (authentication cookie) and 92 (applications list) to client computer 22 1o through DMZ proxy server 34 via message 74. Message 74 also causes the web browser to be redirected to web server 44 via connection 56.
In step 116, the method ends.
However, if, in step 102, the answer is "YES", then the user/client computer 22 has already been authenticated. The method then branches to step 118.
In step 118, a test is performed to determine whether the composite, URL 96 associated with the incoming message includes the appended identifier 100. If "YES", then this means that the user 18 of the remote client computer has just selected an application from the "options page". The "options page"
is the only originating location that would generate a message bearing identifier 100. Subsequent messages originating from client computer 22 during use of a particular application would not be expected to have the appended identifier, since neither the applications 241, 242, ..., 243 nor the browser are normally programmed to include such an identifier. If the answer to decision step 118 is "YES" then the method branches to step 120.
In step 120, the selected-application cookie 94 is built, using the identifier loo. Cookie 94 includes information corresponding to identifier 100.
In step 122, a gateway user identification cookie (i.e., an HTTP
header) is built, using the gateway user ID information obtained in step 110.
In step 124, the incoming message is routed by gateway proxy server 40 to the particular destination server 281, 282, ..., 283 corresponding to
gateway user ID cookie may be set to implement this information passing. Steps 106 - no may be performed sequentially, or as a composite request, or in any other way known in the art.
In step 112, authorization plug-in 42 builds authentication cookie 90, and applications list cookie 92, as described above.
In step 114, plug-in 42, through gateway proxy server 40, transmits cookie 90 (authentication cookie) and 92 (applications list) to client computer 22 1o through DMZ proxy server 34 via message 74. Message 74 also causes the web browser to be redirected to web server 44 via connection 56.
In step 116, the method ends.
However, if, in step 102, the answer is "YES", then the user/client computer 22 has already been authenticated. The method then branches to step 118.
In step 118, a test is performed to determine whether the composite, URL 96 associated with the incoming message includes the appended identifier 100. If "YES", then this means that the user 18 of the remote client computer has just selected an application from the "options page". The "options page"
is the only originating location that would generate a message bearing identifier 100. Subsequent messages originating from client computer 22 during use of a particular application would not be expected to have the appended identifier, since neither the applications 241, 242, ..., 243 nor the browser are normally programmed to include such an identifier. If the answer to decision step 118 is "YES" then the method branches to step 120.
In step 120, the selected-application cookie 94 is built, using the identifier loo. Cookie 94 includes information corresponding to identifier 100.
In step 122, a gateway user identification cookie (i.e., an HTTP
header) is built, using the gateway user ID information obtained in step 110.
In step 124, the incoming message is routed by gateway proxy server 40 to the particular destination server 281, 282, ..., 283 corresponding to
-19-the selected application. Gateway proxy server 40 includes a mapping or routing function responsive to the appended identifier 100, and configured to identify the appropriate destination server 28. Identifier ioo may be omitted from the message that is eventually routed through one of connections 58, 60, and 62, since its purpose (i.e., routing) has already been satisfied. It is important to note that the selected-application cookie 94 now contains the information as to the selected application. Thus, subsequent messages, which include cookie 94, may be routed to the appropriate destination server. The method then proceeds to step 116, wherein the method ends.
If, however, the answer to decision step 118 is "NO", then the method branches to step 126. If the user of the client computer 22 has been authenticated, and no recognizable identifier is appended, then that means that this message is the second or subsequent message to go through the gateway proxy server 40 from the client computer 22 after authentication. As described above, the various application programs 301, 302, ..., 303 are not generally programmed to append routing aids, nor should they be. Computer system 20 should handle the routing function transparently with respect to the various applications. In accordance with the present invention, computer system 20 transparently accomplishes this function in an efficient manner.
In step 126, the selected application cookie 94 is captured, and from which identifier 10o is recovered. For example, the identifier 10o may be "/billing" for a billing-related application.
In step 128, the recovered identifier loo is appended to the URL
specified in the incoming message. In a preferred embodiment, the identifier is appended as a suffix. Accordingly, plug-in 42 includes the means for appending, prior to routing, identifier loo to the URL contained in the incoming message. Other configurations, however, are possible, limited only by the capabilities of the mapping means included in gateway proxy server 40.
In step 130, the composite URL (including the appended identifier loo) is passed to the gateway proxy server's mapping function. This reconstructed composite URL thus contains the same information (i.e., the appended symbolic) in the same format as the initial composite URL originating
If, however, the answer to decision step 118 is "NO", then the method branches to step 126. If the user of the client computer 22 has been authenticated, and no recognizable identifier is appended, then that means that this message is the second or subsequent message to go through the gateway proxy server 40 from the client computer 22 after authentication. As described above, the various application programs 301, 302, ..., 303 are not generally programmed to append routing aids, nor should they be. Computer system 20 should handle the routing function transparently with respect to the various applications. In accordance with the present invention, computer system 20 transparently accomplishes this function in an efficient manner.
In step 126, the selected application cookie 94 is captured, and from which identifier 10o is recovered. For example, the identifier 10o may be "/billing" for a billing-related application.
In step 128, the recovered identifier loo is appended to the URL
specified in the incoming message. In a preferred embodiment, the identifier is appended as a suffix. Accordingly, plug-in 42 includes the means for appending, prior to routing, identifier loo to the URL contained in the incoming message. Other configurations, however, are possible, limited only by the capabilities of the mapping means included in gateway proxy server 40.
In step 130, the composite URL (including the appended identifier loo) is passed to the gateway proxy server's mapping function. This reconstructed composite URL thus contains the same information (i.e., the appended symbolic) in the same format as the initial composite URL originating
-20-from the user's selection from the "options page". The mapping function of proxy server 40, therefore, need not be changed or altered to handle second and subsequent messages as compared to the first message.
In step 132, the incoming message is routed to the destination server corresponding to the selected application (as mapped). The method proceeds to step 116, where the method ends.
In accordance with this aspect of the present invention, an efficient mechanism is provided for providing access from a client computer over an insecure network to a selected one of a plurality of destination servers on a 1o private network. The use of a selected-application cookie 94, in connection with a suitably programmed plug-in 42, configured to append the identifier, operate in concert to effect efficient routing.
Figure 6 shows information flow for a user in obtaining an X.5o9 digital certificate for use in the present invention. Each application 241, 242, ..., 243 has a respective trustee 134, who controls who is allowed to gain access to the application. Initially, a user 18 directs a message 136 to trustee 134, which includes information regarding the user. This communication (e.g., message 136) may be done by telephone. The trustee then provides the user with a user ID/password, with instructions to access the certificate authority 50 using the provided user ID/password. The trustee 134 then sends a message 138 to Information Security 48 that contains the information collected from the user 18, including what application(s) are being requested for remote access.
Information Security 48 may have a direct (e.g., web-based) interface 140 to authorization server 46 for the purpose of, for example, entering the user information forwarded to it by trustee 134.
The user 18 through client computer 22 according to the instructions given by the trustee then logs in to certificate authority 5o using the original user ID and password. After log-in, user 18 then directs a request 142 to certificate authority 50. Request 142 comprises the request for the certificate, which also includes information regarding user 18 and of the desired applications. The certificate authority 50 then provides user 18, perhaps via
In step 132, the incoming message is routed to the destination server corresponding to the selected application (as mapped). The method proceeds to step 116, where the method ends.
In accordance with this aspect of the present invention, an efficient mechanism is provided for providing access from a client computer over an insecure network to a selected one of a plurality of destination servers on a 1o private network. The use of a selected-application cookie 94, in connection with a suitably programmed plug-in 42, configured to append the identifier, operate in concert to effect efficient routing.
Figure 6 shows information flow for a user in obtaining an X.5o9 digital certificate for use in the present invention. Each application 241, 242, ..., 243 has a respective trustee 134, who controls who is allowed to gain access to the application. Initially, a user 18 directs a message 136 to trustee 134, which includes information regarding the user. This communication (e.g., message 136) may be done by telephone. The trustee then provides the user with a user ID/password, with instructions to access the certificate authority 50 using the provided user ID/password. The trustee 134 then sends a message 138 to Information Security 48 that contains the information collected from the user 18, including what application(s) are being requested for remote access.
Information Security 48 may have a direct (e.g., web-based) interface 140 to authorization server 46 for the purpose of, for example, entering the user information forwarded to it by trustee 134.
The user 18 through client computer 22 according to the instructions given by the trustee then logs in to certificate authority 5o using the original user ID and password. After log-in, user 18 then directs a request 142 to certificate authority 50. Request 142 comprises the request for the certificate, which also includes information regarding user 18 and of the desired applications. The certificate authority 50 then provides user 18, perhaps via
-21-client computer 22, a PIN or the like (e.g., a reference number, a challenge phrase, etc.).
Information Security 48 may have a further direct (e.g., web-based) interface 144 to certificate authority 50. Information Security 48 uses interface 144 to monitor requests coming into certificate authority 50. When Information Security 48 sees user 18's request come in, it compares the information entered by user 18 at Certificate Authority 50 with the user information received via the trustee 134. If approved, Information Security 48 sends a reply message 146 indicating approval to certificate authority 50. Certificate authority 50 then 1o notifies (e.g., e-mail) the user 18 that the request has been approved, and that the digital certificate is available. The user 18 then accesses the certificate authority 50, and logs in using the original user ID and password that were provided by trustee 134, and the PIN provided by certificate authority 50. When this information is accepted by authority 50, the digital certificate is sent as shown at 148 to the client computer 22. In one embodiment, the digital certificate is downloaded directly to client computer 22 of user 18 during the retrieval process (i.e., it is not sent later via e-mail). Information Security 48 is then notified of the certificate data from certificate authority 50. In turn, Information Security forwards the certificate data via interface 140 to authorization server 46.
Authorization server 46 is then updated.
In another aspect of the present invention, an improved method for obtaining an X.5o9 certificate is provided. In this aspect of the invention, after the initial user request to trustee 134 (including submission of required user information, identification of selected applications, etc.), the trustee 134 provides the collected data to Information Security 48. Trustee 134 also provides the user of client computer 22 with a user ID/password and PIN. Information Security 48 then updates the authorization server 46 directly. The user of the remote client computer 22 then contacts certificate authority 50, and provides the user ID/password and PIN. The certificate authority 50 pulls the information directly from authorization server 46 (i.e., there is a secure link between certificate authority 5o and authorizations server 46), and issues the digital certificate to the user of client computer 22 immediately. The certificate authority 5o thereafter
Information Security 48 may have a further direct (e.g., web-based) interface 144 to certificate authority 50. Information Security 48 uses interface 144 to monitor requests coming into certificate authority 50. When Information Security 48 sees user 18's request come in, it compares the information entered by user 18 at Certificate Authority 50 with the user information received via the trustee 134. If approved, Information Security 48 sends a reply message 146 indicating approval to certificate authority 50. Certificate authority 50 then 1o notifies (e.g., e-mail) the user 18 that the request has been approved, and that the digital certificate is available. The user 18 then accesses the certificate authority 50, and logs in using the original user ID and password that were provided by trustee 134, and the PIN provided by certificate authority 50. When this information is accepted by authority 50, the digital certificate is sent as shown at 148 to the client computer 22. In one embodiment, the digital certificate is downloaded directly to client computer 22 of user 18 during the retrieval process (i.e., it is not sent later via e-mail). Information Security 48 is then notified of the certificate data from certificate authority 50. In turn, Information Security forwards the certificate data via interface 140 to authorization server 46.
Authorization server 46 is then updated.
In another aspect of the present invention, an improved method for obtaining an X.5o9 certificate is provided. In this aspect of the invention, after the initial user request to trustee 134 (including submission of required user information, identification of selected applications, etc.), the trustee 134 provides the collected data to Information Security 48. Trustee 134 also provides the user of client computer 22 with a user ID/password and PIN. Information Security 48 then updates the authorization server 46 directly. The user of the remote client computer 22 then contacts certificate authority 50, and provides the user ID/password and PIN. The certificate authority 50 pulls the information directly from authorization server 46 (i.e., there is a secure link between certificate authority 5o and authorizations server 46), and issues the digital certificate to the user of client computer 22 immediately. The certificate authority 5o thereafter
-22-updates authorization server 46 with the certificate data of the issued digital certificate. This method has the advantage of avoiding the re-keying of data from the user's perspective who, under the first-described method, entered data for the trustee, and again for the certificate authority. In addition, the improved approach provides a "one-stop" experience for user 18.
In another aspect of the present invention, a secure gateway is provided for allowing authenticated access from a client computer over an insecure public network to a destination server on a private network without the use of digital certificates. In applications where digital certificates are not 1o required, there would be no "first level" authentication on the insecure network side of the firewall, as described above with respect to computer system 20.
It would nonetheless be desirable to perform such authentication, at least on a preliminary level, on the insecure side of the firewall before allowing messages through the firewall to the destination servers.
Figure 7 shows a simplified block diagram of a second embodiment according to the present invention, namely, computer system 200. Unless indicated to the contrary, the same reference numerals are used to identify identical or substantially similar components in the various views. Computer system 200 implements a user identification (ID) and password scheme for authenticating the user of client computer 22. Figure 7 is similar to Figure 1, except that a DMZ web server 210 is provided on the insecure network side of firewall system 32 in lieu of web server 44 on the private-network side.
Although not shown in Figure 7, DMZ proxy server 34 and gateway proxy server 40 include respective plug-ins 36, and 42, as described above with respect to computer system 20.
Figure 8 is a flow chart diagram illustrating the inventive system and method for authenticating a remote client computer 22. The method begins in step 212.
In step 214, DMZ proxy server 34 via programmed plug-in 36 3o determines whether the incoming message contains a valid authentication cookie 90. As described above, the presence of cookie 9o itself, in conjunction with a timestamp that is not too old, may satisfy the requirements for a "valid"
In another aspect of the present invention, a secure gateway is provided for allowing authenticated access from a client computer over an insecure public network to a destination server on a private network without the use of digital certificates. In applications where digital certificates are not 1o required, there would be no "first level" authentication on the insecure network side of the firewall, as described above with respect to computer system 20.
It would nonetheless be desirable to perform such authentication, at least on a preliminary level, on the insecure side of the firewall before allowing messages through the firewall to the destination servers.
Figure 7 shows a simplified block diagram of a second embodiment according to the present invention, namely, computer system 200. Unless indicated to the contrary, the same reference numerals are used to identify identical or substantially similar components in the various views. Computer system 200 implements a user identification (ID) and password scheme for authenticating the user of client computer 22. Figure 7 is similar to Figure 1, except that a DMZ web server 210 is provided on the insecure network side of firewall system 32 in lieu of web server 44 on the private-network side.
Although not shown in Figure 7, DMZ proxy server 34 and gateway proxy server 40 include respective plug-ins 36, and 42, as described above with respect to computer system 20.
Figure 8 is a flow chart diagram illustrating the inventive system and method for authenticating a remote client computer 22. The method begins in step 212.
In step 214, DMZ proxy server 34 via programmed plug-in 36 3o determines whether the incoming message contains a valid authentication cookie 90. As described above, the presence of cookie 9o itself, in conjunction with a timestamp that is not too old, may satisfy the requirements for a "valid"
-23-authentication cookie 9o. A valid or "true" condition indicates that client computer 22 has already been successfully authenticated within the recent past.
In an alternate embodiment, authentication cookie 9o may be configured to provide enhanced information such as status indicator information. The status indicator information may include an authorization boolean operator (e.g., TRUE, FALSE) data indicating whether the user is recognized by authorization server 46, and data indicating that the user is recognized by the authorization server 46, but that the password so provided has expired. If the answer to decision step 214 is "NO", then the method branches to step 216.
In step 216, web server 210 formats a message that is sent via proxy server 34, over secure connection 52, to client computer 22, which causes a "popup" login screen to appear to the user. A user identification (ID) and password is obtained from the user 18 of client computer 22, which is securely messaged back to web server 210 via DMZ proxy server 34.
In step 218, web server 210 formats a message that includes the user ID and password obtained from the user of the remote client computer 22, and sends that message through firewall 32 over secure connection 56 to authorization server 46. Also included in the message is a request for a response indicative of whether the user-provided user ID and password are sufficient to authenticate the user of remote client computer 22. The authorization server may include an authorization daemon, a process configured to perform a lookup query in the authorization LDAP server portion of server 46. The response from server 46 may include authentication data representative of whether the user is authenticated or not, based on the supplied user ID and password. The response may also include an identification of the applications 241, 242, for which access is authorized. Based on the foregoing, web server 210 creates authentication cookie 9o (best shown in Figure 4A).
In step 220, web server 21o determines whether the user is authenticated. This step may simply involve evaluating the response returned from authorization server 46. If the answer is "NO", then the decision step branches to step 222.
In an alternate embodiment, authentication cookie 9o may be configured to provide enhanced information such as status indicator information. The status indicator information may include an authorization boolean operator (e.g., TRUE, FALSE) data indicating whether the user is recognized by authorization server 46, and data indicating that the user is recognized by the authorization server 46, but that the password so provided has expired. If the answer to decision step 214 is "NO", then the method branches to step 216.
In step 216, web server 210 formats a message that is sent via proxy server 34, over secure connection 52, to client computer 22, which causes a "popup" login screen to appear to the user. A user identification (ID) and password is obtained from the user 18 of client computer 22, which is securely messaged back to web server 210 via DMZ proxy server 34.
In step 218, web server 210 formats a message that includes the user ID and password obtained from the user of the remote client computer 22, and sends that message through firewall 32 over secure connection 56 to authorization server 46. Also included in the message is a request for a response indicative of whether the user-provided user ID and password are sufficient to authenticate the user of remote client computer 22. The authorization server may include an authorization daemon, a process configured to perform a lookup query in the authorization LDAP server portion of server 46. The response from server 46 may include authentication data representative of whether the user is authenticated or not, based on the supplied user ID and password. The response may also include an identification of the applications 241, 242, for which access is authorized. Based on the foregoing, web server 210 creates authentication cookie 9o (best shown in Figure 4A).
In step 220, web server 21o determines whether the user is authenticated. This step may simply involve evaluating the response returned from authorization server 46. If the answer is "NO", then the decision step branches to step 222.
-24-In step 222, the user i8 of the remote client computer 22 is presented with an authorization error message, generated by web server 210.
The method proceeds to step 224, where the process ends.
If the answer, however, to decision step 220 is "YES", then the method branches to step 226. In step 226, web server 210 determines whether the number of authorized applications is greater than one. If the answer is "NO", then the method branches to step 228.
In step 228, web server 210 creates (if needed), and sets the selected-application cookie 94. This may involve associating information, such as io identifier ioo, with cookie 94. For purposes of illustration only, identifier 100 may be a character string having a "slash" character as a prefix, such a "/billing"
for a billing-related application.
In step 230, web server 210 sets an application suffix for proxy mapping. In effect, web server 210 is configured with the means for appending identifier ioo to base URL included in the incoming message. Since there is no "options page" for the situation where only one application is authorized, web server 21o appends identifier 10o for the initial message.
In step 232, web server 210 creates an HTTP header (e.g., a "cookie") having the gateway user ID. This may be useful or required by the applications 241, 242 executing on destination servers 281, 282. This feature has been described above.
In step 234, web server 210 sends a redirect message to client computer 22, redirecting the web browser portion of client computer 22 to request resources (e.g., for the initial message, the "Welcome Page") from the destination server 28 corresponding to the authorized application. The method then proceeds to step 224 where the method ends.
If the answer to decision step 226, however, is "YES", then the method branches to step 236.
In step 236, web server 210 generates the "options page" referred to 3o above that lists all of the applications that client computer 22 is authorized to access. Once the user of the remote client computer 22 has made a selection of
The method proceeds to step 224, where the process ends.
If the answer, however, to decision step 220 is "YES", then the method branches to step 226. In step 226, web server 210 determines whether the number of authorized applications is greater than one. If the answer is "NO", then the method branches to step 228.
In step 228, web server 210 creates (if needed), and sets the selected-application cookie 94. This may involve associating information, such as io identifier ioo, with cookie 94. For purposes of illustration only, identifier 100 may be a character string having a "slash" character as a prefix, such a "/billing"
for a billing-related application.
In step 230, web server 210 sets an application suffix for proxy mapping. In effect, web server 210 is configured with the means for appending identifier ioo to base URL included in the incoming message. Since there is no "options page" for the situation where only one application is authorized, web server 21o appends identifier 10o for the initial message.
In step 232, web server 210 creates an HTTP header (e.g., a "cookie") having the gateway user ID. This may be useful or required by the applications 241, 242 executing on destination servers 281, 282. This feature has been described above.
In step 234, web server 210 sends a redirect message to client computer 22, redirecting the web browser portion of client computer 22 to request resources (e.g., for the initial message, the "Welcome Page") from the destination server 28 corresponding to the authorized application. The method then proceeds to step 224 where the method ends.
If the answer to decision step 226, however, is "YES", then the method branches to step 236.
In step 236, web server 210 generates the "options page" referred to 3o above that lists all of the applications that client computer 22 is authorized to access. Once the user of the remote client computer 22 has made a selection of
-25-one of the applications, the client computer 22 sends an HTTP request encapsulated in an HTTPS message that includes a composite URL 96 comprising a base URL 98 and identifier ioo. The method proceeds to step 238.
In step 238, plug-in 42 processing occurs. This processing is the same as described above with respect to computer system 20, and as shown in Figure 5.
In step 240, the incoming message is directed to the destination server 28 corresponding to the selected application 24. The method ends at step 224.
If, however, the answer to the decision step 214 is "YES", then the method branches to step 242, wherein the incoming message is routed by DMZ
proxy server 34, through gateway proxy server 40 to the destination server 28 corresponding to the selected application.
One advantage of computer system 200 is that it authenticates a remote client computer prior to allowing access to the secure, private network.
Computer system 20o achieves authentication where use of digital certificates is either unavailable or undesirable. In addition, the architecture of computer system 200 maintains the sensitive, authentication data on the secure, private network side of the firewall, reducing the likelihood of a successful "hacker"
intrusion.
It is to be understood that the above description is merely exemplary rather than limiting in nature, the invention being limited only by the appended claims. Various modifications and changes may be made thereto by one of ordinary skill in the art which embodies the principles of the invention and fall within the spirit and scope thereof.
In step 238, plug-in 42 processing occurs. This processing is the same as described above with respect to computer system 20, and as shown in Figure 5.
In step 240, the incoming message is directed to the destination server 28 corresponding to the selected application 24. The method ends at step 224.
If, however, the answer to the decision step 214 is "YES", then the method branches to step 242, wherein the incoming message is routed by DMZ
proxy server 34, through gateway proxy server 40 to the destination server 28 corresponding to the selected application.
One advantage of computer system 200 is that it authenticates a remote client computer prior to allowing access to the secure, private network.
Computer system 20o achieves authentication where use of digital certificates is either unavailable or undesirable. In addition, the architecture of computer system 200 maintains the sensitive, authentication data on the secure, private network side of the firewall, reducing the likelihood of a successful "hacker"
intrusion.
It is to be understood that the above description is merely exemplary rather than limiting in nature, the invention being limited only by the appended claims. Various modifications and changes may be made thereto by one of ordinary skill in the art which embodies the principles of the invention and fall within the spirit and scope thereof.
Claims (18)
1. A computer system for providing access from a client computer over an insecure public network to a selected one of a plurality of destination servers on a secure private network each executing a corresponding application, said computer system comprising:
a proxy server configured to establish a secure connection with said client computer over said insecure network; and, a gateway disposed between said proxy server and said private network, wherein said gateway includes means for appending, prior to routing, an identifier to a message received from said client computer destined for said selected destination server, said identifier being associated with a respective application with which said selected destination server is associated, and means for routing said message to said selected destination server as a function of said identifier.
a proxy server configured to establish a secure connection with said client computer over said insecure network; and, a gateway disposed between said proxy server and said private network, wherein said gateway includes means for appending, prior to routing, an identifier to a message received from said client computer destined for said selected destination server, said identifier being associated with a respective application with which said selected destination server is associated, and means for routing said message to said selected destination server as a function of said identifier.
2. The computer system of claim 1 wherein said identifier comprises a character string.
3. The computer system of claim 2 said message comprises a hypertext transfer protocol (HTTP) uniform resource locator (URL), said identifier being appended to said message as a suffix.
4. The computer system of claim 3 wherein said identifier further comprises a slash character prefix.
5. The computer system of claim 1 further comprising:
a firewall system between said insecure network and said private network;
and, an authorization server for authenticating a user of said client system and indicating whether said user is authorized to access said selected destination server;
said proxy server being disposed on said insecure network side of said firewall system, and said gateway, said authorization server and said destination servers are disposed on said private network side of said firewall system.
a firewall system between said insecure network and said private network;
and, an authorization server for authenticating a user of said client system and indicating whether said user is authorized to access said selected destination server;
said proxy server being disposed on said insecure network side of said firewall system, and said gateway, said authorization server and said destination servers are disposed on said private network side of said firewall system.
6. The computer system of claim 1 wherein said client computer has a digital certificate compliant with an X.5~9 standard associated therewith, said proxy server being configured to determine whether said digital certificate was issued from a valid certificate authority.
7. The computer system of claim 6 wherein said proxy server is further configured to insert said digital certificate into a hypertext transfer protocol (HTTP) header, and to transmit said header to said gateway.
8. The computer system of claim 7 wherein said gateway is configured to extract said digital certificate from said HTTP, and to authenticate said user using said extracted digital certificate with said authorization server.
9. The computer system of claim 8 wherein said authorization server comprises a lightweight directory access protocol (LDAP) capable server.
10. The computer system of claim 1 wherein said proxy server comprises a demilitarized zone (DMZ) proxy server, and said gateway includes a gateway proxy server and a gateway web server, said gateway web server being configured to transmit to said client computer a list including a plurality of applications executing on said destination servers for which access by a user of said client computer is authorized.
11. The computer system of claim 10 wherein selection at said client computer of one application from said list defines said selected destination server, said selection being further operative to send a uniform resource locator (URL) to said gateway proxy server, said URL comprising a domain name portion and said identifier appended as a suffix thereto.
12. The computer system of claim 11 wherein said gateway proxy server is configured to receive said URL, extract said identifier, and build a selected-application cookie.
13. The computer system of claim 12 wherein said appending means of said gateway comprises a plug-in associated with said gateway proxy server configured to recognize said selected-application cookie, and in response thereto, append said identifier to said message.
14. A computer system for providing access from a client computer over an insecure public network to a selected one of a plurality of destination servers on a secure private network each executing a corresponding application, said computer system comprising:
a firewall system between said insecure network and said secure private network;
a proxy server disposed on said insecure network side of said firewall system, said proxy server being configured to establish a secure connection over said insecure network to said client computer;
a gateway disposed between said proxy server and said private network on said private network side of said firewall system;
an authorization server for authenticating a user of said client system, and indicating whether said user is authorized to access said selected destination server; and, wherein said gateway includes means for appending, prior to routing, an identifier to a message received from said client computer destined for said selected destination server, said identifier being associated with said selected destination server, and means for routing said message to said selected destination server as a function of said identifier.
a firewall system between said insecure network and said secure private network;
a proxy server disposed on said insecure network side of said firewall system, said proxy server being configured to establish a secure connection over said insecure network to said client computer;
a gateway disposed between said proxy server and said private network on said private network side of said firewall system;
an authorization server for authenticating a user of said client system, and indicating whether said user is authorized to access said selected destination server; and, wherein said gateway includes means for appending, prior to routing, an identifier to a message received from said client computer destined for said selected destination server, said identifier being associated with said selected destination server, and means for routing said message to said selected destination server as a function of said identifier.
15. The computer system of claim 14 wherein said proxy server comprises a demilitarized zone (DMZ) proxy server, and said gateway includes a gateway proxy server and a gateway web server configured to transmit to said client computer a list including a plurality of applications executing on said destination servers for which access by said user is authorized, selection at said client computer of one application from said list being operative to (i) define said selected destination server and (ii) send to said gateway proxy server a uniform resource locator (URL) comprising a domain name portion and said identifier appended as a suffix thereto.
16. The computer system of claim 15 wherein said gateway proxy server is configured to receive said URL, to extract said identifier, and to build a selected-application cookie for transmission to said client computer, and wherein said appending means of said gateway comprises a plug-in associated with said gateway proxy server configured to recognize said selected-application cookie, and in response thereto, append said identifier to said message.
17. A method for providing access from a client computer over an insecure public network to one of a plurality of destination servers on a secure private network each executing a corresponding application, said method comprising the steps of:
(A) determining one or more applications from the plurality of applications executing on the destination servers for which access by a user of the client computer is authorized;
(B) associating a uniform resource locator (URL) having an identifier appended thereto with each determined application;
(C) building an application cookie using the identifier portion of the URL corresponding to a selected one of the applications determined in step (A);
(D) appending the identifier to a message from the client computer destined for the destination server using the application cookie; and, (E) routing the message to one of the plurality of destination servers executing the selected application as function of the appended identifier.
(A) determining one or more applications from the plurality of applications executing on the destination servers for which access by a user of the client computer is authorized;
(B) associating a uniform resource locator (URL) having an identifier appended thereto with each determined application;
(C) building an application cookie using the identifier portion of the URL corresponding to a selected one of the applications determined in step (A);
(D) appending the identifier to a message from the client computer destined for the destination server using the application cookie; and, (E) routing the message to one of the plurality of destination servers executing the selected application as function of the appended identifier.
18. The method of claim 17 wherein said identifier comprises a character string appended as a suffix.
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17068699P | 1999-12-14 | 1999-12-14 | |
US60/170,686 | 1999-12-14 | ||
US09/471,645 US6510464B1 (en) | 1999-12-14 | 1999-12-23 | Secure gateway having routing feature |
US09/471,645 | 1999-12-23 | ||
PCT/US2000/033813 WO2001044951A1 (en) | 1999-12-14 | 2000-12-14 | Secure gateway having routing feature |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2394479A1 CA2394479A1 (en) | 2001-06-21 |
CA2394479C true CA2394479C (en) | 2010-11-23 |
Family
ID=26866351
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2394479A Expired - Lifetime CA2394479C (en) | 1999-12-14 | 2000-12-14 | Secure gateway having routing feature |
Country Status (5)
Country | Link |
---|---|
US (1) | US6510464B1 (en) |
EP (1) | EP1247187B1 (en) |
AU (1) | AU2430801A (en) |
CA (1) | CA2394479C (en) |
WO (1) | WO2001044951A1 (en) |
Families Citing this family (171)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6970933B1 (en) | 1999-07-15 | 2005-11-29 | F5 Networks, Inc. | Enabling application level persistence between a server and another resource over a network |
US7346695B1 (en) | 2002-10-28 | 2008-03-18 | F5 Networks, Inc. | System and method for performing application level persistence |
US7137009B1 (en) * | 2000-01-06 | 2006-11-14 | International Business Machines Corporation | Method and apparatus for securing a cookie cache in a data processing system |
US7954144B1 (en) * | 2000-01-18 | 2011-05-31 | Novell, Inc. | Brokering state information and identity among user agents, origin servers, and proxies |
US7072933B1 (en) * | 2000-01-24 | 2006-07-04 | Microsoft Corporation | Network access control using network address translation |
US7925693B2 (en) * | 2000-01-24 | 2011-04-12 | Microsoft Corporation | NAT access control with IPSec |
FR2804564B1 (en) * | 2000-01-27 | 2002-03-22 | Bull Sa | MULTI-APPLICATION SAFETY RELAY |
US6435164B1 (en) | 2000-12-07 | 2002-08-20 | Ford Global Technologies, Inc. | Fuel weathering method for vehicle evaporative emission system |
US7689696B2 (en) * | 2000-01-31 | 2010-03-30 | Telecommunication Systems, Inc. | System and method for re-directing requests from browsers for communications over non-IP based networks |
US7003571B1 (en) * | 2000-01-31 | 2006-02-21 | Telecommunication Systems Corporation Of Maryland | System and method for re-directing requests from browsers for communication over non-IP based networks |
US8370435B1 (en) | 2000-01-31 | 2013-02-05 | Telecommunication Systems, Inc. | System and method for servers to send alerts to connectionless devices |
US8090856B1 (en) | 2000-01-31 | 2012-01-03 | Telecommunication Systems, Inc. | Intelligent messaging network server interconnection |
US6954799B2 (en) | 2000-02-01 | 2005-10-11 | Charles Schwab & Co., Inc. | Method and apparatus for integrating distributed shared services system |
CA2299824C (en) * | 2000-03-01 | 2012-02-21 | Spicer Corporation | Network resource control system |
US8843617B2 (en) * | 2000-03-01 | 2014-09-23 | Printeron Inc. | Multi-stage polling mechanism and system for the transmission and processing control of network resource data |
CA2301996A1 (en) * | 2000-03-13 | 2001-09-13 | Spicer Corporation | Wireless attachment enabling |
US7209959B1 (en) * | 2000-04-04 | 2007-04-24 | Wk Networks, Inc. | Apparatus, system, and method for communicating to a network through a virtual domain providing anonymity to a client communicating on the network |
US6665721B1 (en) * | 2000-04-06 | 2003-12-16 | International Business Machines Corporation | Enabling a home network reverse web server proxy |
US7111076B2 (en) * | 2000-04-13 | 2006-09-19 | Intel Corporation | System using transform template and XML document type definition for transforming message and its reply |
US8239445B1 (en) * | 2000-04-25 | 2012-08-07 | International Business Machines Corporation | URL-based sticky routing tokens using a server-side cookie jar |
US7640580B1 (en) * | 2000-05-17 | 2009-12-29 | F5 Networks, Inc. | Method and apparatus for accessing a computer behind a firewall |
US7478434B1 (en) * | 2000-05-31 | 2009-01-13 | International Business Machines Corporation | Authentication and authorization protocol for secure web-based access to a protected resource |
US20040073617A1 (en) | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
US6671731B1 (en) * | 2000-06-21 | 2003-12-30 | Mediaone Group, Inc. | Generic proxy service for docsis-enabled set top devices |
US7099933B1 (en) * | 2000-07-11 | 2006-08-29 | Nortel Networks Limited | System and method for regulating web site access |
US6941369B1 (en) * | 2000-07-20 | 2005-09-06 | Unisys Corporation | Gateway CGI and access control manager for secure inter-server communications with system and method for web serving using same |
US7185360B1 (en) * | 2000-08-01 | 2007-02-27 | Hereuare Communications, Inc. | System for distributed network authentication and access control |
US7177945B2 (en) * | 2000-08-04 | 2007-02-13 | Avaya Technology Corp. | Non-intrusive multiplexed transaction persistency in secure commerce environments |
DE10040463C2 (en) * | 2000-08-18 | 2003-10-23 | Tenovis Gmbh & Co Kg | Method for establishing a data connection between a first and a second computing unit and device for exchanging data |
US7089585B1 (en) * | 2000-08-29 | 2006-08-08 | Microsoft Corporation | Method and system for authorizing a client computer to access a server computer |
US7774455B1 (en) | 2000-09-26 | 2010-08-10 | Juniper Networks, Inc. | Method and system for providing secure access to private networks |
US7620719B2 (en) * | 2002-06-06 | 2009-11-17 | Juniper Networks, Inc. | Method and system for providing secure access to private networks |
US20020078076A1 (en) * | 2000-12-15 | 2002-06-20 | Evans David J. | Simulator disposed between a server and a client system |
US20020116637A1 (en) * | 2000-12-21 | 2002-08-22 | General Electric Company | Gateway for securely connecting arbitrary devices and service providers |
FR2819967B1 (en) * | 2001-01-24 | 2003-03-14 | Bull Sa | METHOD AND SYSTEM FOR COMMUNICATING A CERTIFICATE BETWEEN A SECURITY MODULE AND A SERVER |
EP1227639A3 (en) * | 2001-01-30 | 2003-10-29 | AT&T Corp. | Network service for adaptive mobile applications |
US20020133709A1 (en) * | 2001-03-14 | 2002-09-19 | Hoffman Terry George | Optical data transfer system - ODTS; Optically based anti-virus protection system - OBAPS |
US7882555B2 (en) * | 2001-03-16 | 2011-02-01 | Kavado, Inc. | Application layer security method and system |
WO2002076062A1 (en) * | 2001-03-16 | 2002-09-26 | Matsushita Electric Industrial Co., Ltd. | Method and apparatus for setting up a firewall |
US6959336B2 (en) * | 2001-04-07 | 2005-10-25 | Secure Data In Motion, Inc. | Method and system of federated authentication service for interacting between agent and client and communicating with other components of the system to choose an appropriate mechanism for the subject from among the plurality of authentication mechanisms wherein the subject is selected from humans, client applications and applets |
US6839761B2 (en) * | 2001-04-19 | 2005-01-04 | Microsoft Corporation | Methods and systems for authentication through multiple proxy servers that require different authentication data |
US20020161904A1 (en) * | 2001-04-30 | 2002-10-31 | Xerox Corporation | External access to protected device on private network |
US7228438B2 (en) * | 2001-04-30 | 2007-06-05 | Matsushita Electric Industrial Co., Ltd. | Computer network security system employing portable storage device |
US20020176670A1 (en) * | 2001-05-10 | 2002-11-28 | Masao Shinoda | Connector ferrule for connecting optical fibers |
AU2002312381A1 (en) | 2001-06-07 | 2002-12-16 | First Usa Bank, N.A. | System and method for rapid updating of credit information |
US7328336B2 (en) * | 2001-06-26 | 2008-02-05 | Ncipher Corporation Ltd | System and method for small-area system data processing |
US7266839B2 (en) * | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
ATE241820T1 (en) * | 2001-07-12 | 2003-06-15 | Castify Networks Sa | METHOD FOR PROVIDING CUSTOMER ACCESS TO A CONTENT PROVIDING SERVER UNDER THE CONTROL OF A RESOURCE LOCALIZING SERVER |
KR20040019328A (en) * | 2001-08-03 | 2004-03-05 | 마쯔시다덴기산교 가부시키가이샤 | Access control system |
US7062547B2 (en) * | 2001-09-24 | 2006-06-13 | International Business Machines Corporation | Method and system for providing a central repository for client-specific accessibility |
US6970918B2 (en) * | 2001-09-24 | 2005-11-29 | International Business Machines Corporation | System and method for transcoding support of web content over secure connections |
US20030065920A1 (en) * | 2001-10-01 | 2003-04-03 | International Business Machines Corporation | Method and apparatus for using host authentication for automated public key certification |
US7631084B2 (en) * | 2001-11-02 | 2009-12-08 | Juniper Networks, Inc. | Method and system for providing secure access to private networks with client redirection |
US7146403B2 (en) * | 2001-11-02 | 2006-12-05 | Juniper Networks, Inc. | Dual authentication of a requestor using a mail server and an authentication server |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US7150042B2 (en) | 2001-12-06 | 2006-12-12 | Mcafee, Inc. | Techniques for performing malware scanning of files stored within a file storage device of a computer network |
US7093002B2 (en) * | 2001-12-06 | 2006-08-15 | Mcafee, Inc. | Handling of malware scanning of files stored within a file storage device of a computer network |
US7506058B2 (en) * | 2001-12-28 | 2009-03-17 | International Business Machines Corporation | Method for transmitting information across firewalls |
DE60210408T2 (en) * | 2002-01-18 | 2006-10-19 | Stonesoft Corp. | Monitoring the flow of data to improve network security protection |
US20030177390A1 (en) * | 2002-03-15 | 2003-09-18 | Rakesh Radhakrishnan | Securing applications based on application infrastructure security techniques |
EP1488606B1 (en) * | 2002-03-20 | 2006-11-08 | Research In Motion Limited | Mobile access to lightweight directory access protocol (LDAP) |
US7275109B1 (en) * | 2002-04-02 | 2007-09-25 | Nortel Networks Limited | Network communication authentication |
US20030233580A1 (en) * | 2002-05-29 | 2003-12-18 | Keeler James D. | Authorization and authentication of user access to a distributed network communication system with roaming features |
US20030236997A1 (en) * | 2002-06-24 | 2003-12-25 | Paul Jacobson | Secure network agent |
US7801945B1 (en) | 2002-07-03 | 2010-09-21 | Sprint Spectrum L.P. | Method and system for inserting web content through intermediation between a content server and a client station |
US7568002B1 (en) | 2002-07-03 | 2009-07-28 | Sprint Spectrum L.P. | Method and system for embellishing web content during transmission between a content server and a client station |
US7360210B1 (en) | 2002-07-03 | 2008-04-15 | Sprint Spectrum L.P. | Method and system for dynamically varying intermediation functions in a communication path between a content server and a client station |
US8528068B1 (en) | 2002-07-26 | 2013-09-03 | Purple Communications, Inc. | Method of authenticating a user on a network |
US7430755B1 (en) | 2002-09-03 | 2008-09-30 | Fs Networks, Inc. | Method and system for providing persistence in a secure network access |
US8301493B2 (en) * | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
US7305681B2 (en) * | 2003-03-20 | 2007-12-04 | Nokia Corporation | Method and apparatus for providing multi-client support in a sip-enabled terminal |
US7836493B2 (en) * | 2003-04-24 | 2010-11-16 | Attachmate Corporation | Proxy server security token authorization |
US7480254B2 (en) * | 2003-05-28 | 2009-01-20 | Nokia Corporation | System, apparatus, and method for providing multi-application support using a single protocol stack |
US7694021B1 (en) | 2003-05-28 | 2010-04-06 | Cisco Technology, Inc. | Firewall for gateway network elements between IP based networks |
US7356697B2 (en) * | 2003-06-20 | 2008-04-08 | International Business Machines Corporation | System and method for authentication to an application |
US8214884B2 (en) | 2003-06-27 | 2012-07-03 | Attachmate Corporation | Computer-based dynamic secure non-cached delivery of security credentials such as digitally signed certificates or keys |
US8234373B1 (en) | 2003-10-27 | 2012-07-31 | Sprint Spectrum L.P. | Method and system for managing payment for web content based on size of the web content |
US7444678B2 (en) * | 2003-10-28 | 2008-10-28 | Aol Llc | Securing resources from untrusted scripts behind firewalls |
US7146420B2 (en) * | 2003-11-20 | 2006-12-05 | Square D Company | Internet listener/publisher |
US7890995B2 (en) * | 2003-11-26 | 2011-02-15 | Cisco Technology, Inc. | System and method for remote management of communications networks |
EP1697818B1 (en) * | 2003-12-23 | 2018-05-30 | Wells Fargo Bank, N.A. | Authentication system for networked computer applications |
GB0407388D0 (en) * | 2004-03-31 | 2004-05-05 | British Telecomm | Method and apparatus for communicating data between computer devices |
US9172679B1 (en) | 2004-04-14 | 2015-10-27 | Sprint Spectrum L.P. | Secure intermediation system and method |
US7853782B1 (en) | 2004-04-14 | 2010-12-14 | Sprint Spectrum L.P. | Secure intermediation system and method |
US7673049B2 (en) * | 2004-04-19 | 2010-03-02 | Brian Dinello | Network security system |
US7444505B2 (en) * | 2004-04-22 | 2008-10-28 | At&T Intellectual Property I, L.P. | Method, system and software for maintaining network access and security |
US7480700B2 (en) * | 2004-04-27 | 2009-01-20 | Apple Inc. | Method and system for retrieval and usage of remote entry points |
US7797410B2 (en) * | 2004-04-29 | 2010-09-14 | Euro Convergence, Sarl | Reverse IP method and system |
US7422152B2 (en) | 2004-05-13 | 2008-09-09 | Cisco Technology, Inc. | Methods and devices for providing scalable RFID networks |
US20060047832A1 (en) * | 2004-05-21 | 2006-03-02 | Christopher Betts | Method and apparatus for processing web service messages |
US7841005B2 (en) * | 2004-05-21 | 2010-11-23 | Computer Assoicates Think, Inc. | Method and apparatus for providing security to web services |
EP1762197B1 (en) * | 2004-06-18 | 2014-04-16 | Olympus Corporation | Instrument for cutting organism tissue |
US7512973B1 (en) | 2004-09-08 | 2009-03-31 | Sprint Spectrum L.P. | Wireless-access-provider intermediation to facilliate digital rights management for third party hosted content |
JP2006079448A (en) * | 2004-09-10 | 2006-03-23 | Konica Minolta Business Technologies Inc | Data control method, data control device and data control server |
US20060067162A1 (en) * | 2004-09-29 | 2006-03-30 | Blankinship Thomas J | Ultrasonic cement scanner |
US7600011B1 (en) | 2004-11-04 | 2009-10-06 | Sprint Spectrum L.P. | Use of a domain name server to direct web communications to an intermediation platform |
US20060098645A1 (en) * | 2004-11-09 | 2006-05-11 | Lev Walkin | System and method for providing client identifying information to a server |
US8458467B2 (en) * | 2005-06-21 | 2013-06-04 | Cisco Technology, Inc. | Method and apparatus for adaptive application message payload content transformation in a network infrastructure element |
US7509431B2 (en) * | 2004-11-17 | 2009-03-24 | Cisco Technology, Inc. | Performing message and transformation adapter functions in a network element on behalf of an application |
US7664879B2 (en) * | 2004-11-23 | 2010-02-16 | Cisco Technology, Inc. | Caching content and state data at a network element |
US7987272B2 (en) | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US7496750B2 (en) * | 2004-12-07 | 2009-02-24 | Cisco Technology, Inc. | Performing security functions on a message payload in a network element |
US7725934B2 (en) * | 2004-12-07 | 2010-05-25 | Cisco Technology, Inc. | Network and application attack protection based on application layer message inspection |
US8082304B2 (en) * | 2004-12-10 | 2011-12-20 | Cisco Technology, Inc. | Guaranteed delivery of application layer messages by a network element |
US7606267B2 (en) * | 2004-12-10 | 2009-10-20 | Cisco Technology, Inc. | Reducing the sizes of application layer messages in a network element |
US8655957B2 (en) * | 2004-12-16 | 2014-02-18 | Apple Inc. | System and method for confirming that the origin of an electronic mail message is valid |
US7551567B2 (en) * | 2005-01-05 | 2009-06-23 | Cisco Technology, Inc. | Interpreting an application message at a network element using sampling and heuristics |
US20060155862A1 (en) * | 2005-01-06 | 2006-07-13 | Hari Kathi | Data traffic load balancing based on application layer messages |
US7698416B2 (en) * | 2005-01-25 | 2010-04-13 | Cisco Technology, Inc. | Application layer message-based server failover management by a network element |
US7657737B2 (en) * | 2005-02-28 | 2010-02-02 | International Business Machines Corporation | Method for mapping an encrypted https network packet to a specific url name and other data without decryption outside of a secure web server |
WO2007006119A1 (en) * | 2005-04-18 | 2007-01-18 | Research In Motion Limited | System topology for secure end-to-end communications between wireless device and application data source |
US20060282525A1 (en) * | 2005-06-10 | 2006-12-14 | Giles James R | Method and apparatus for delegating responses to conditions in computing systems |
US8266327B2 (en) * | 2005-06-21 | 2012-09-11 | Cisco Technology, Inc. | Identity brokering in a network element |
CA2510626A1 (en) * | 2005-06-23 | 2006-12-23 | Cognos Incorporated | Request routing system for and method of request routing |
CA2518894C (en) | 2005-06-23 | 2014-06-10 | Cognos Incorporated | Request routing system for and method of request routing |
CA2615203C (en) | 2005-07-15 | 2016-09-13 | Accenture Global Services Gmbh | Presentation layer application integration |
US7345585B2 (en) * | 2005-08-01 | 2008-03-18 | Cisco Technology, Inc. | Network based device for providing RFID middleware functionality |
US20070067780A1 (en) * | 2005-08-24 | 2007-03-22 | Samsung Electronics Co., Ltd. | Method and system for asynchronous eventing over the internet |
US20070050630A1 (en) * | 2005-08-24 | 2007-03-01 | Samsung Electronics Co., Ltd. | Authentication method and system for asynchronous eventing over the internet |
US7853791B1 (en) * | 2006-05-16 | 2010-12-14 | Sprint Communications Company L.P. | System and method for certificate based redirection |
US8549295B2 (en) * | 2006-05-31 | 2013-10-01 | Microsoft Corporation | Establishing secure, mutually authenticated communication credentials |
US8566452B1 (en) | 2006-08-03 | 2013-10-22 | F5 Networks, Inc. | Intelligent HTTP based load-balancing, persistence, and application traffic management of SSL VPN tunnels |
US20080059619A1 (en) * | 2006-08-31 | 2008-03-06 | Microsoft Corporation | Configuring a Perimeter Network |
US8312507B2 (en) | 2006-10-17 | 2012-11-13 | A10 Networks, Inc. | System and method to apply network traffic policy to an application session |
US8584199B1 (en) | 2006-10-17 | 2013-11-12 | A10 Networks, Inc. | System and method to apply a packet routing policy to an application session |
US7716378B2 (en) * | 2006-10-17 | 2010-05-11 | A10 Networks, Inc. | System and method to associate a private user identity with a public user identity |
US8838975B2 (en) * | 2006-10-31 | 2014-09-16 | Blackberry Limited | System and method for protecting a password against brute force attacks |
US20080115202A1 (en) * | 2006-11-09 | 2008-05-15 | Mckay Michael S | Method for bidirectional communication in a firewalled environment |
US8812579B2 (en) * | 2006-12-21 | 2014-08-19 | Verizon Patent And Licensing Inc. | Apparatus for transferring data via a proxy server and an associated method and computer program product |
US9137203B2 (en) * | 2007-01-24 | 2015-09-15 | International Business Machines Corporation | Centralized secure offload of cryptographic security services for distributed security enforcement points |
GB0712022D0 (en) * | 2007-06-20 | 2007-10-17 | Still First Ltd | Encrypted communication system |
KR20100133953A (en) * | 2007-12-21 | 2010-12-22 | 코쿤 데이터 홀딩스 리미티드 | System and method for securing data |
US9237167B1 (en) * | 2008-01-18 | 2016-01-12 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing network counter measures |
US8555367B2 (en) * | 2008-03-12 | 2013-10-08 | Yahoo! Inc. | Method and system for securely streaming content |
EP2263348B1 (en) * | 2008-04-07 | 2018-06-27 | Melih Abdulhayoglu | Method and system for displaying verification information indicators for a non-secure website |
US9379895B2 (en) | 2008-07-24 | 2016-06-28 | Zscaler, Inc. | HTTP authentication and authorization management |
US9003186B2 (en) * | 2008-07-24 | 2015-04-07 | Zscaler, Inc. | HTTP authentication and authorization management |
US8352729B2 (en) * | 2008-07-29 | 2013-01-08 | International Business Machines Corporation | Secure application routing |
FR2940695B1 (en) * | 2008-12-30 | 2012-04-20 | Eads Secure Networks | MICRONOYAU GATEWAY SERVER |
US8468585B2 (en) * | 2009-01-05 | 2013-06-18 | International Business Machines Corporation | Management of credentials used by software applications |
US20100309510A1 (en) * | 2009-06-09 | 2010-12-09 | Accipiter Innovations, Llc | Systems, methods and devices for printing from a mobile device |
US9019535B1 (en) | 2009-06-09 | 2015-04-28 | Breezyprint Corporation | Secure mobile printing from a third-party device |
US20110066851A1 (en) | 2009-09-14 | 2011-03-17 | International Business Machines Corporation | Secure Route Discovery Node and Policing Mechanism |
US20110153411A1 (en) * | 2009-12-23 | 2011-06-23 | Kenshoo Ltd. | Method and system for identification of an online purchase without notification of making the purchase |
CN102130791B (en) * | 2010-01-14 | 2013-02-13 | 深圳市深信服电子科技有限公司 | Method, device and gateway server for detecting agent on gateway server |
US8350718B2 (en) | 2010-05-04 | 2013-01-08 | Itron, Inc. | Secure collector diagnostic portal activation |
JP2011258014A (en) * | 2010-06-09 | 2011-12-22 | Fujitsu Ltd | Relay processing method, program and relay device |
KR20120034550A (en) | 2010-07-20 | 2012-04-12 | 한국전자통신연구원 | Apparatus and method for providing streaming contents |
US8826451B2 (en) * | 2010-08-16 | 2014-09-02 | Salesforce.Com, Inc. | Mechanism for facilitating communication authentication between cloud applications and on-premise applications |
EP3327656A1 (en) * | 2010-09-06 | 2018-05-30 | Electronics And Telecommunications Research Institute | Apparatus and method for providing streaming content |
US8970873B2 (en) | 2010-09-17 | 2015-03-03 | Printeron Inc. | System and method for managing printer resources on an internal network |
US8570566B2 (en) | 2010-09-17 | 2013-10-29 | Printeron Inc. | System and method that provides user interface on mobile network terminal for releasing print jobs based on location information |
WO2012071646A1 (en) | 2010-11-30 | 2012-06-07 | Printeron Inc. | System for internet enabled printing |
US9118618B2 (en) | 2012-03-29 | 2015-08-25 | A10 Networks, Inc. | Hardware-based packet editor |
US8977560B2 (en) * | 2012-08-08 | 2015-03-10 | Ebay Inc. | Cross-browser, cross-machine recoverable user identifiers |
US9323412B2 (en) * | 2012-10-26 | 2016-04-26 | Cellco Partnership | Briefing tool having self-guided discovery and suggestion box features |
US9338225B2 (en) | 2012-12-06 | 2016-05-10 | A10 Networks, Inc. | Forwarding policies on a virtual service network |
US9271188B2 (en) * | 2012-12-18 | 2016-02-23 | At&T Intellectual Property I, L.P. | Dynamic in-band service control mechanism in mobile network |
US9298896B2 (en) * | 2013-01-02 | 2016-03-29 | International Business Machines Corporation | Safe auto-login links in notification emails |
US9288215B2 (en) | 2013-03-08 | 2016-03-15 | Itron, Inc. | Utilizing routing for secure transactions |
US9992107B2 (en) | 2013-03-15 | 2018-06-05 | A10 Networks, Inc. | Processing data packets using a policy based network path |
WO2014179753A2 (en) | 2013-05-03 | 2014-11-06 | A10 Networks, Inc. | Facilitating secure network traffic by an application delivery controller |
US9009461B2 (en) * | 2013-08-14 | 2015-04-14 | Iboss, Inc. | Selectively performing man in the middle decryption |
US9356882B2 (en) | 2014-02-04 | 2016-05-31 | Printeron Inc. | Streamlined system for the transmission of network resource data |
DE102014102627B3 (en) * | 2014-02-27 | 2015-07-02 | Fujitsu Technology Solutions Intellectual Property Gmbh | Working method for a system as well as system |
US9942152B2 (en) | 2014-03-25 | 2018-04-10 | A10 Networks, Inc. | Forwarding data packets using a service-based forwarding policy |
US9473466B2 (en) * | 2014-10-10 | 2016-10-18 | Freescale Semiconductor, Inc. | System and method for internet protocol security processing |
US10268467B2 (en) | 2014-11-11 | 2019-04-23 | A10 Networks, Inc. | Policy-driven management of application traffic for providing services to cloud-based applications |
CN107637029B (en) * | 2015-06-10 | 2021-09-14 | 株式会社宙连 | Communication system and communication method for providing wireless terminal with access to IP network |
US10103879B2 (en) * | 2015-09-30 | 2018-10-16 | Verizon Patent And Licensing Inc. | Secure data upload/download service |
US9680801B1 (en) | 2016-05-03 | 2017-06-13 | Iboss, Inc. | Selectively altering references within encrypted pages using man in the middle |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5826014A (en) | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US5872915A (en) * | 1996-12-23 | 1999-02-16 | International Business Machines Corporation | Computer apparatus and method for providing security checking for software applications accessed via the World-Wide Web |
US6144990A (en) * | 1996-12-23 | 2000-11-07 | International Business Machines Corporation | Computer apparatus and method for communicating between software applications and computers on the world-wide web using universal variable handling |
US5923756A (en) | 1997-02-12 | 1999-07-13 | Gte Laboratories Incorporated | Method for providing secure remote command execution over an insecure computer network |
US6167522A (en) * | 1997-04-01 | 2000-12-26 | Sun Microsystems, Inc. | Method and apparatus for providing security for servers executing application programs received via a network |
US5805803A (en) * | 1997-05-13 | 1998-09-08 | Digital Equipment Corporation | Secure web tunnel |
US5991810A (en) | 1997-08-01 | 1999-11-23 | Novell, Inc. | User name authentication for gateway clients accessing a proxy cache server |
US5974443A (en) * | 1997-09-26 | 1999-10-26 | Intervoice Limited Partnership | Combined internet and data access system |
US6357010B1 (en) * | 1998-02-17 | 2002-03-12 | Secure Computing Corporation | System and method for controlling access to documents stored on an internal network |
US6182142B1 (en) | 1998-07-10 | 2001-01-30 | Encommerce, Inc. | Distributed access management of information resources |
US6088796A (en) * | 1998-08-06 | 2000-07-11 | Cianfrocca; Francis | Secure middleware and server control system for querying through a network firewall |
US6205480B1 (en) * | 1998-08-19 | 2001-03-20 | Computer Associates Think, Inc. | System and method for web server user authentication |
US6324648B1 (en) * | 1999-12-14 | 2001-11-27 | Gte Service Corporation | Secure gateway having user identification and password authentication |
-
1999
- 1999-12-23 US US09/471,645 patent/US6510464B1/en not_active Expired - Lifetime
-
2000
- 2000-12-14 AU AU24308/01A patent/AU2430801A/en not_active Abandoned
- 2000-12-14 WO PCT/US2000/033813 patent/WO2001044951A1/en active Application Filing
- 2000-12-14 EP EP00988058.4A patent/EP1247187B1/en not_active Expired - Lifetime
- 2000-12-14 CA CA2394479A patent/CA2394479C/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP1247187B1 (en) | 2016-03-09 |
EP1247187A4 (en) | 2009-04-22 |
WO2001044951A1 (en) | 2001-06-21 |
CA2394479A1 (en) | 2001-06-21 |
AU2430801A (en) | 2001-06-25 |
EP1247187A1 (en) | 2002-10-09 |
US6510464B1 (en) | 2003-01-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2394479C (en) | Secure gateway having routing feature | |
CA2394493C (en) | Secure gateway having user identification and password authentication | |
US8850017B2 (en) | Brokering state information and identity among user agents, origin servers, and proxies | |
EP1368722B1 (en) | Method and system for web-based cross-domain single-sign-on authentication | |
US7287271B1 (en) | System and method for enabling secure access to services in a computer network | |
US9521118B2 (en) | Secure network privacy system | |
US6766454B1 (en) | System and method for using an authentication applet to identify and authenticate a user in a computer network | |
KR100800339B1 (en) | Method and system for user-determined authentication and single-sign-on in a federated environment | |
US8566919B2 (en) | Distributed web application firewall | |
CA2341213C (en) | System and method for enabling secure access to services in a computer network | |
US6092196A (en) | HTTP distributed remote user authentication system | |
US8640202B2 (en) | Synchronizing user sessions in a session environment having multiple web services | |
US7673133B2 (en) | Virtual private network between computing network and remote device | |
US20020184507A1 (en) | Centralized single sign-on method and system for a client-server environment | |
US7290286B2 (en) | Content provider secure and tracable portal | |
US20090013399A1 (en) | Secure Network Privacy System | |
US7334126B1 (en) | Method and apparatus for secure remote access to an internal web server | |
WO2004038565A2 (en) | Centrally controllable instant messaging system | |
WO2002093377A1 (en) | Method and apparatus for serving content from a semi-trusted server | |
WO2005060202A1 (en) | Method and system for analysing and filtering https traffic in corporate networks | |
CA2510647A1 (en) | Signing of web request | |
ES2364658T3 (en) | GET THE SECURE THAT YOU HAVE USER IDENTIFICATION AND PASSWORD AUTHENTICATION. | |
WO2000002348A2 (en) | Secure web-based mail | |
CN115361188A (en) | SSL system for performing one-way and two-way authentication switching according to user attributes | |
Kossakowski et al. | Securing public web servers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKEX | Expiry |
Effective date: 20201214 |