Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 1 of 15 PageID #: 225
`
`(12)
`
`United States Patent
`Ilnicki et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,751,677 B1
`Jun. 15, 2004
`
`US006751677B1
`
`(54) METHOD AND APPARATUS FOR
`ALLOWING A SECURE AND TRANSPARENT
`COMMUNICATION BETWEENA USER
`
`6,088,796 A * 7/2000 Cianfrocca et a1. ....... .. 713/152
`6,154,775 A * 11/2000 Coss et a1. ................ .. 709/225
`6,161,139 A * 12/2000 Win et al.
`709/225
`
`6,272,492 B1 * 8/2001 Kay . . . . . . . . . . . . . . .
`
`. . . . .. 707/10
`
`
`
`ggggglggggggggioj glgggggggsg A GATEWAY
`
`
`
`B1 * 6,356,930 B2 * 3/2002 Garg ........................ .. 709/201
`
`(75) Inventors: Slawomir K. Ilnicki, Los Altos, CA
`James P Rice Menlo Park CA
`
`.
`
`'
`
`’
`
`’
`
`*
`
`'
`'t d b
`C1 6
`y exammer
`P
`y E
`_N ElH dy
`Assistant Examiner—Jungwon Chang
`(57)
`ABSTRACT
`
`rim/1r
`
`xaminer
`
`.
`
`a
`
`A method of allowing a secure and transparent communi
`cation between a user device and servers of a data access
`network system via a ?rewall and a gateway is described.
`Th
`hd' ld h
`fd' '
`l
`l'
`f
`e met 0 inc u es t e step 0 esignatmg a p ura 1ty o
`ports in the ?rewall for the gateway, each corresponding to
`one of a number of ports in the gateway. Each of the gateway
`ports can be dynamically assigned to correspond to the port
`of one of the servers. The method also includes a step of
`proXifying an object reference used in a user request for a
`target server from the user device in order to establish secure
`connection between the user device and the target server.
`This step is ?rst performed by replacing the IP address and
`the port number of the target server of the user request with
`a dynamically assigned gateway port and the IP address of
`the gateway. Then the dynamically assigned gateway port
`and the gateway’s IP address are mapped to the port of and
`IP address of the target server such that the user request is
`not required to expose the IP address and port number of the
`target Server at the gateway‘
`
`11 Claims, 8 Drawing Sheets
`
`(73) Assignee: Hewlett-Packard Development
`Company, L.P., Houston, TX (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`USC154(b)b 0d
`.
`.
`.
`y
`ays.
`
`Aug- 24’ 1999
`
`(21) App1_ NO; 09/379,755
`_
`(22) Flled:
`(51) Int Cl_7
`(52) U S C] iiiiiiiiiiiiiiiiiiii
`58
`F: I'd
`iiiiii
`"""" ii
`(
`)
`1e
`
`0
`
`’
`
`’
`
`’
`
`’
`
`G061; 9/54
`707/103 R
`769/201 225
`152 767/10’
`’ 103 R’
`
`’
`
`(56)
`
`.
`References Clted
`US. PATENT DOCUMENTS
`395/187 01
`5 623 601 A
`4/1997 V
`5,781,550 A
`7/1998 Templin et al. ........... .. 370/401
`5,898,830 A * 4/1999 Wesinger, Jr. et al. .... .. 713/201
`5,907,621 A * 5/1999 Bachman et a1. ......... .. 713/155
`
`u ...................... ..
`
`.
`
`,
`
`,
`
`USER
`TERMINAL
`
`GATEWAY
`
`TARGET
`SERVER
`
`Proxify IOR
`
`E
`
`Proxi?ed lOR
`
`E
`
`TCP connect to gateway
`
`_
`
`E
`
`Authenticate client
`
`SSL Hello message to target E
`
`TCP connect to target
`
`Authenticate target
`
`_
`
`E
`
`Forward SSL Hello message _
`
`E
`
`Complete SSL handshake
`
`Invoke target object
`
`_
`
`_
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 2 of 15 PageID #: 226
`Case 4:17-cv-OOl41-ALM Document 17-4 Filed 05/19/17 Page 2 of 15 PagelD #: 226
`
`US. Patent
`
`Jun. 15, 2004
`
`Sheet 1 0f 8
`
`US 6,751,677 B1
`
`SERVERS
`
`FIREWALL
`
`FIGURE1 (PRIORART)
`
`12
`
`13
`
`
`
`
`11
`
`
`TERMINAL
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 3 of 15 PageID #: 227
`
`U.S. Patent
`
`Jun. 15,2004
`
`Sheet 2 of 8
`
`US 6,751,677 B1
`
`mmm>m mm 1
`
`mm
`
`mm
`
`K
`
`52 EQEV m MEDGE
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 4 of 15 PageID #: 228
`
`U.S. Patent
`
`Jun. 15,2004
`
`Sheet 3 of 8
`
`US 6,751,677 B1
`
`wok,
`
`mag,
`
`
`
`Ally can
`
`I I'HI [\l
`
`momm \
`
`whmom
`
`
`mwIPO m0»
`Km
`wmm>mmm A
`
`|---| |
`
`L
`
`r
`
`w l
`
`.
`
`. C
`
`m MEDQE
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 5 of 15 PageID #: 229
`
`U.S. Patent
`
`Jun. 15,2004
`
`Sheet 4 of 8
`
`US 6,751,677 B1
`
`mm .\ 5% 20:63am,‘
`
`8 \ Ex: “58
`
`a \ 52.. 568 mm 8%
`
`w MEDQI
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 6 of 15 PageID #: 230
`
`Case 4:17-cv-OOl41-ALM Document 17-4 Filed 05/19/17 Page 6 of 15 PagelD #: 230
`
`USER
`TERMINAL
`
`GATEWAY
`
`TARGET
`SERVER
`
`9 .
`
`03
`w
`
`a(
`
`D
`E.
`
`?
`.=
`.01
`3’c
`4k
`
`g
`31
`3
`
`IaLL9‘ISL‘9sn
`
`Proxify IOR
`
`Proxified lOR
`
`TCP connect to gateway
`
`Authenticate client
`
`SSL Hello message to target
`
`Invoke target object
`
`TCP connect to target
`Authenticate target
`
`Forward SSL Hello message
`
`Complete SSL handshake
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 7 of 15 PageID #: 231
`
`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 7 of 15 PagelD #: 231
`
`72
` 71
`
`73
`
`
` TCP/IP (lPt ,
`
`TCPIIP (IP91, Portg1)
` GATEWAY
`GATEWAY
`
`POI't 92 = IPt POI'lt
`IPcPortC
`Port 91 =
`POI'tQQ
`
`FIGURE 6
`
`
`
`.111an'S'fl
`
`v00z‘91°unr
`
`8J09133118
`
`13LL9‘ISL‘9sn
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 8 of 15 PageID #: 232
`
`U.S. Patent
`
`Jun. 15,2004
`
`Sheet 7 of 8
`
`US 6,751,677 B1
`
`
`
`mm wmwT mm\.
`
`£2 Q E8 i u a E 58 é “ a :8
`
`ii g n am t8
`
`58 g “ am :8 32 u s 515%
`am a: H 8 Es“: 5:8 n 3 5f
`
`
`am :8 u 6 E16“: @361 mm“: H a :8
`
`N mm 3 @E
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 9 of 15 PageID #: 233
`
`U.S. Patent
`
`Jun. 15,2004
`
`Sheet 8 of 8
`
`US 6,751,677 B1
`
`_ _ _ _ _ _ _ _ _ _ _ _ _
`
`5K 5.5mm
`
`we?
`
`rlll I|ll|_
`
`m MEDQE
`
`mow\,
`
`
`
`8? 55% mm;
`
`A
`
`§ Ewaomm
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 10 of 15 PageID #: 234
`
`US 6,751,677 B1
`
`1
`METHOD AND APPARATUS FOR
`ALLOWING A SECURE AND TRANSPARENT
`COMMUNICATION BETWEEN A USER
`DEVICE AND SERVERS OF A DATA ACCESS
`NETWORK SYSTEM VIAA FIREWALL AND
`A GATEWAY
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention pertains to communication net
`Works. More particularly, this invention relates to providing
`a secure and transparent netWork gateWay that does not
`require complex con?guration to the associated ?reWall.
`2. Description of the Related Art
`In an open-ended netWork system such as Internet, a
`?reWall is typically employed betWeen servers and remote
`accessing clients (e.g., user terminals). The main purpose of
`the ?reWall is to control external accesses to and from the
`servers. This means that the ?reWall alloWs the external
`accesses to the servers to cross the ?reWall in a controlled
`fashion. FIG. 1 shoWs one such prior art arrangement of the
`?reWall.
`In FIG. 1, communication betWeen the user terminal 11
`and the target object servers 12 is conducted using Object
`Request Broker (ORB) transparent protocol over a TCP/IP
`(Transmission Control Protocol-Internet Protocol) commu
`nications protocol. When tie user terminal 11 Wants to access
`a particular object in one of the target object servers 12, the
`terminal 11 uses an Interoperable Object Reference (IOR) to
`issue an object invocation using an object reference of the
`requested object. The object invocation is referred to as the
`user access request beloW. The object reference typically
`includes the TCP/IP port number and IP (Internal Protocol)
`address of the object. The port number and IP address
`specify the target object server that contains the requested
`object.
`The ?reWall 13 has a number of TCP/IP ports and IP
`addresses, each con?gured or opened to correspond to one
`of the servers 12. When the user access request enters the
`?reWall 13, the ?reWall 13 checks if the port and IP address
`speci?ed in the user access request are opened in the ?reWall
`13. If the port and IP address are opened in the ?reWall 13,
`the request passes through the ?reWall 13 and reaches the
`designation target object server. Then a communication
`channel can be established for transferring the requested
`object to the user terminal 11. If the ?reWall 13 does not have
`the corresponding port opened, the ?reWall 13 does not let
`the user access request to pass through it and does not
`establish communication channel for the user access request.
`One disadvantage of this prior art ?reWall is that the
`?reWall has statically con?gured target object ports and IP
`addresses. Adding neW target object servers requires recon
`?guration of the ?reWall. This can only be done by opening
`neW ports and IP addresses. For security reasons, these ports
`and IP addresses cannot be opened ahead of time because it
`creates security loopholes. This means that the ?reWall does
`not have any ?exibility.
`One prior solution to solving the problem of accessing the
`target objects is to employ a CORBA (Common Object
`Request Broker Architecture) gateWay behind the ?reWall,
`as can be seen from FIG. 2. The CORBA gateWay can also
`be implemented as part of the ?reWall. One such prior
`CORBA gateWay is the WonderWall manufactured and sold
`by Iona Technologies PLC from Ireland.
`
`10
`
`15
`
`25
`
`45
`
`55
`
`65
`
`2
`In FIG. 2, the ?reWall 22 is con?gured to have one port
`number and IP address designated to the CORBA gateWay
`23. All user access requests to the servers 24 are forWarded
`to the CORBA gateWay 23 by the ?reWall 22. The CORBA
`gateWay 23 maps all of the servers 24. Each of the target
`object servers 24 has an individual IP address and at least
`one port number. The CORBA gateWay 23 includes a
`mapping lookup table that speci?es the port numbers and IP
`addresses of all the servers 24 connected to the CORBA
`gateWay 23. Each pair of port number and IP address stored
`in the mapping lookup table of the CORBA gateWay 23 can
`be retrieved from the lookup table using an object key. The
`object key is part of the object reference from the user access
`request. Whenever a user access request passes through the
`gateWay 23, the request has to be examined and routed by
`the gateWay 23 according to the content of the object key in
`the user access request.
`In order for a user access request to access a particular
`target object server, the object reference of the access
`request is ?rst proxi?ed at the user terminal (e.g., terminal
`21) using the IOR such that the proxi?ed request points to
`the CORBA gateWay 23, instead of the intended target
`object server. The proxi?cation is done by speci?cally
`replacing the port number and IP address of the object
`reference used by the user access request that point to the
`particular target object server With the port number and IP
`address of the CORBA gateWay 23. To access the target
`object server, a TCP/IP connection betWeen the user termi
`nal (e.g., the terminal 21) and the gateWay 23 must ?rst be
`established. This is done through the ORB protocol in the
`user terminal 21 upon receiving the object reference from
`the client application. In this case, the ?reWall 22 must have
`the IP address and port con?gured in order for the TCP/IP
`connection to go through. Once the TCP/IP connection is
`established, the ORB protocol in the user terminal 21 sends
`the request that contains the object key in the request header.
`At the CORBA gateWay 23, the server port number and IP
`address are extracted from the request header by using the
`object key of the access request to search the mapping
`lookup table in the CORBA gateWay 23. The CORBA
`gateWay 23 establishes another connection (i.e., gateWay
`target object server) and forWards the request over this
`connection to the target object server. This dynamically
`maps the port number and IP address of a particular target
`object server to the CORBA gateWay 23.
`HoWever, disadvantages are associated With the prior
`CORBA gateWay. One disadvantage associated is that the
`gateWay typically does not alloW the ?reWall to provide
`end-to-end security for the communication (e.g.,
`authentication, con?dentiality, and integrity). This means
`that SSL (secure socket layer) protocol cannot be used, for
`example, betWeen the ?reWall 22 and the servers 24 as a
`single session. This is due to the fact that the CORBA
`gateWay requires access to request header in order to extract
`the object key. Connections have to be terminated at the
`?reWall/gateWay and encrypted data have to be decrypted to
`alloW examination of the object reference headers and to
`make ?ltering decisions. If SSL is used, secure communi
`cation can only establishes tWo separate sessions. One of
`Which is betWeen the user terminal and the ?reWall and the
`other is betWeen the ?reWall and the target object servers.
`This means that a single SSL session cannot be established
`betWeen the user terminal and the target object servers. As
`a consequence, encryption of data cannot be preserved from
`end-to-end. There is no direct authentication betWeen the
`user terminal and the target object servers. The gateWay has
`to be trusted to pass client and target object server creden
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 11 of 15 PageID #: 235
`
`US 6,751,677 B1
`
`3
`tials (e.g., identity certi?cate). However, this credential must
`be passed as additional payload. This means that the target
`object server must be modi?ed to manage user credentials.
`Another disadvantage is that the con?guration of access
`control list based on object keys of the prior CORBA
`gateWay is static, complex, and manual. Moreover, the prior
`CORBA gateWay does not provide a mechanism for authen
`ticating clients and target object servers at the ?reWall.
`Depending on security policy, the client authentication may
`be necessary at the ?reWall before commencing traf?c to the
`target object servers. This protection is necessary for mali
`cious outside attacks and the ?reWall creates a ?rst line of
`defense. Authenticating target object servers at the ?reWall
`may be necessary in situations Where security policy
`requires that an authoriZed resource is available at the target
`address, not a Trojan horse. Aclient or user terminal may use
`a Trojan horse to penetrate Internet netWork.
`
`5
`
`15
`
`4
`of the gateWay ports of the second gateWay can also be
`dynamically assigned to correspond to a port of the servers.
`The method also includes a step of proxifying an object
`reference that refers to the target server to be accessed by a
`user object invocation request from the user device in order
`to establish a single end-to-end secure session betWeen the
`user device and the target server. This step is performed by
`(1) replacing the IP address and the port number of the target
`server Within the object reference With a dynamically
`assigned gateWay port and the IP address of the ?rst
`gateWay, (2) mapping the dynamically assigned gateWay
`port and the ?rst gateWay’s address to a dynamically
`assigned gateWay port and the IP address of the second
`gateWay, and (3) mapping the dynamically assigned gateWay
`port and the IP address of the second gateWay to the port and
`IP address of the target server such that the user request is
`not required to carry the IP address and port number of the
`target server. Once the object reference is proxi?ed and
`proper mapping at the gateWay is established, the user then
`may issue an object invocation request using the proxi?ed
`object reference. When the user transmits the object invo
`cation request by the client application in the user terminal,
`a chain of TCP/IP connections (i.e., user terminal-gateWay,
`gateWay-gateWay, gateWay-object) is established from the
`user terminal. Once such chain of TCP/IP connections is
`established, the underlying client application in the user
`terminal establishes over these connections a single SSL
`session With the target object server. After the SSL connec
`tion is established, the user’s object invocation request is
`sent.
`Other features and advantages of the present invention
`Will become apparent from the folloWing detailed
`description, taken in conjunction With the accompanying
`draWings, illustrating by Way of examples the principles of
`the invention.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shoWs a prior art arrangement of netWork com
`munication using a ?reWall.
`FIG. 2 shoWs another prior art arrangement of netWork
`communication using a ?reWall and a CORBA gateWay.
`FIG. 3 shoWs a netWork communication arrangement in
`accordance With one embodiment of the present invention.
`FIG. 4 shoWs various application layers Within the user
`terminal and the gateWay of FIG. 3.
`FIG. 5 shoWs hoW a secure SSL connection betWeen the
`user terminal and the target server is established in the
`arrangement of FIG. 3.
`FIGS. 6 and 7 shoW tWo other arrangement of the present
`invention.
`FIG. 8 shoWs another application of the present invention.
`
`25
`
`35
`
`45
`
`SUMMARY OF THE INVENTION
`
`One feature of the present invention is to provide a secure
`and transparent netWork connection for an open-ended net
`Work system.
`Another feature of the present invention is to provide a
`secure and transparent netWork gateWay that does not
`require complex con?guration to the associated ?reWall.
`A further feature of the present invention is to provide a
`secure and transparent netWork gateWay that simpli?es the
`proxi?cation of Interoperable Object References (IORs) and
`does not expose dynamically assigned ports of the gateWay
`to external client applications.
`Astill further feature of the present invention is to provide
`a secure and transparent netWork gateWay that maps a
`dynamically assigned gateWay port to speci?c destination IP
`and port at the servers.
`A method of alloWing a secure and transparent commu
`nication betWeen a user device and servers of a data access
`netWork system via a ?reWall and a gateWay is described.
`The method includes the step of designating a plurality of
`ports in the ?reWall for the gateWay, each corresponding to
`one of a number of ports in the gateWay. Each of the gateWay
`ports can be dynamically assigned to correspond to the port
`and IP address of one of the servers. The method also
`includes a step of proxifying an object reference that refers
`to a target server of the servers to be accessed by a user
`request from the user device in order to alloW a single
`end-to-end secure session betWeen the user device and the
`target server to be established via the gateWay. This step is
`performed by ?rst replacing the IP address and the port
`number of the target server of the user request With a
`dynamically assigned gateWay port and the IP address of the
`gateWay. Then the dynamically assigned gateWay port and
`the gateWay’s IP address are mapped to the port of and IP
`address of the target server such that the user request is not
`required to expose the IP address and port number of the
`target server and the single end-to-end secure session
`betWeen the user device and the target server is established.
`In a data access netWork system having servers, a client
`access device, a ?reWall, and a ?rst and a second gateWay
`serially coupled betWeen the servers and the ?reWall, a
`method of establishing secure connection betWeen the client
`device and a target server of the servers is described. The
`method includes the step of designating a plurality of ports
`in the ?reWall for the ?rst gateWay, each corresponding to
`one of a number of ports in the ?rst gateWay. Each of the
`gateWay ports of the ?rst gateWay can be dynamically
`assigned to correspond to a port of the second gateWay. Each
`
`55
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`FIG. 3 shoWs a data access netWork system 30 that
`implements an arrangement for establishing secure connec
`tion betWeen a user terminal 31 and target object servers 34
`in accordance With one embodiment of the present inven
`tion. As can be seen from FIG. 3, the data access netWork
`system 30 includes the user terminal 31, a ?reWall 32, a
`gateWay 33, and the target object servers 34. In accordance
`With one embodiment of the present invention, the ?reWall
`32 and the gateWay 33 are con?gured to alloW a secure and
`transparent connection betWeen the user terminal 31 and the
`servers 34 Without requiring the user request from the user
`
`65
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 12 of 15 PageID #: 236
`
`US 6,751,677 B1
`
`5
`terminal 31 to expose the IP (Internet Protocol) address and
`port number of the target server to the gateway 33 once the
`mapping is established (i.e., once the proxi?cation is made).
`As Will be described in more detail beloW, the ?reWall 32
`is con?gured to designate or reserve a number of its ports
`(i.e., the ports 320) for the gateWay 33. Each of the desig
`nated ports 320 corresponds to one of a number of ports (i.e.,
`the ports 330) in the gateWay 33. This means that if one of
`the designated ports 320 of the ?reWall is opened, the
`gateWay 33 is listening on the corresponding gateWay port.
`Each of the gateWay ports 330 of the gateWay 33 can be
`dynamically assigned to correspond to the port and IP
`address of one of the target object servers 34.
`Before establishing the secure connection betWeen the
`user device 31 and one of the servers 34 speci?ed by a user
`object invocation request from the user device 31 via the
`?reWall 32 and the gateWay 33, the user or client application
`in the user terminal 31 needs to proxify the object reference
`used by the user object invocation request to access the
`requested object in the target object server of the servers 34
`at the gateWay 33. This means that the IP address and port
`number of the target server speci?ed in object reference of
`the user object invocation request are replaced With a
`dynamically assigned gateWay port of the gateWay 33 and
`the IP address of the gateWay 33. That dynamically assigned
`gateWay port from the ports 330 is then mapped to the port
`and the IP address of target object server of the servers 34.
`The gateWay 33 keeps the mapping betWeen (1) the original
`IP address and the port number of the target server and (2)
`the dynamically assigned gateWay port of the gateWay 33
`and the gateWay’s IP address. The mapping and dynamical
`assignment are done by a gateWay proxi?cation object
`program (not shoWn in FIG. 3) in the gateWay 33 that Will
`be described in more detail beloW.
`This arrangement alloWs the gateWay 33 to automatically
`map a user object invocation request to the IP address and
`port number of the target server Without requiring the user
`object invocation request to expose the IP address and port
`number of the target server at the gateWay 33. This in turn
`alloWs secure connection to be established betWeen the user
`terminal 31 and the target server of the servers 34 because
`the mapping is done Without requiring the gateWay to
`examine or look at the encrypted payload of the user request.
`This alloWs the user object invocation request to be
`carried over a SSL (Secure Socket Layer) protocol, thus
`providing end-to-end security (e.g., authentication,
`con?dentiality, and integrity). When the SSL protocol is
`used, the user terminal 31 and the requested target server are
`directly mutually authenticated. The con?dentiality and
`integrity is provided from the user terminal 31 to the target
`server via a single SSL session. This means that the gateWay
`33 does not need to access the user object invocation request
`to perform routing as the dynamically assigned port has been
`mapped to the IP address and port of the target object server.
`It also means that data can be encrypted end-to-end (i.e.,
`from the user terminal 31 to the target object server).
`In addition, the proxi?cation of the object reference used
`by the user request is also simpli?ed and does not expose the
`dynamically assigned port of the gateWay 33 to external
`client applications (e.g., the user terminal 31). It provides
`simple access control to the target object server so that only
`traf?c for authoriZed IP addresses and ports are passed
`through the gateWay 33. Depending on the ?reWall model
`and IP address, ports can be dynamically opened and closed
`by authoriZed callers. The present invention Will be
`described in more detail beloW, also in conjunction With
`FIGS. 3 through 7.
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`Referring to FIG. 3, the data access netWork system 30 is
`an open-end, distributed access system. In one embodiment,
`the data access netWork system 30 is an Internet netWork
`system. In another embodiment, the data access netWork
`system 30 is an Intranet netWork system.
`Referring to FIG. 3, the target object servers 34 include a
`number of object servers, each hosting a number of content
`sites for customers. The customers are the oWners of the
`hosted content in the target object servers 34, and thus can
`be referred to as content providers. The content hosted by the
`servers 34 can be accessed by external clients (e.g., the user
`terminal 31). The external clients access the servers 34 using
`the IP addresses and port numbers of the servers 34. This
`means that each of the servers 34 has an IP address and a port
`number.
`The external clients can be external user terminals (e.g.,
`the user terminal 31), or accessing servers (not shoWn). FIG.
`3 only shoWs one external client in the form of user terminal
`31 for illustration purposes only. In practice, many more
`external clients can be connected to the ?reWall 32. The user
`terminal 31 can be a computer system or other type of data
`access and/or processing system. For example, the user
`terminal 31 can be a personal computer, a notebook
`computer, a server computer, a Workstation computer, a
`notepad computer, etc.
`The ?reWall 32 is used in the data access netWork system
`30 to control external access (e.g., from the user terminal 31)
`to the target object servers 34 and/or other data service
`systems (e.g., e-mail servers) of the data access netWork
`system 30. The ?reWall 32 can be implemented using knoWn
`?reWall technologies. The structure and function of the
`?reWall 32 are Well knoWn and thus Will not be described in
`more detail beloW, except for the portions that relate to the
`arrangement of the present invention.
`The ?reWall 32 includes a number of ports (i.e., the ports
`320 and 321). In accordance With one embodiment of the
`present invention, the ports 320 are reserved or designated
`for the gateWay 33 While the other ports 330 are reserved for
`other servers such as e-mail systems, HTTP servers, tele
`phone message centers, etc.
`The gateWay 33 is connected to the ?reWall 32. The
`gateWay 33 is used to route data to and from the servers 34.
`The gateWay 33 can be implemented using knoWn gateWay
`technologies. The gateWay 33 includes a number of ports
`330. Each of the gateWay ports 330 corresponds to one of the
`ports 320 of the ?reWall 32. For example, the port 320a of
`the ?reWall 32 corresponds to the port 330a in the gateWay
`33. This means that if one of the ports 320 (e.g., the port
`320a) is opened for or to receive a user request, its corre
`sponding gateWay port (e.g., the port 330a) is also open.
`As can be seen from FIGS. 3 and 4, the user terminal 31,
`the gateWay 33, and each of the servers 34 use the TCP/IP
`communication protocol for data communication. Each of
`the user terminal 31 and the gateWay 33 employs the
`communication protocol layers 60 through 62, as shoWn in
`FIG. 4. The IP and TCP are collectively shoWn in FIG. 4 as
`the TCP/IP layer 60. Above that layer is the SSL (secure
`socket layer) layer. The SSL layer 61 is used to encrypt data
`for secure communication purposes.
`Above the SSL layer 61 is the application layer 62. In one
`embodiment, the application layer 62 employs CORBA type
`of application. In another embodiment, the application layer
`62 employs the COM (Common Object Model) type of
`application made available by Microsoft Corporation of
`Redmond, Wash. The application layer 62 is used to perform
`external proxi?cation to the user request and conduct com
`munication betWeen the user terminal 31 and the target
`server.
`
`

`

`Case 4:17-cv-00141-ALM Document 17-4 Filed 05/19/17 Page 13 of 15 PageID #: 237
`
`US 6,751,677 B1
`
`7
`Referring now to FIG. 3, each of the gateway ports 330 of
`the gateway 33 can be dynamically assigned to correspond
`to one of the servers 34. When a gateway port of the gateway
`33 is dynamically assigned for one of the servers 34, that
`dynamically assigned port is mapped to the port number of
`the target server of the servers 34. In addition, the IP address
`of the gateway 33 is mapped to the IP address of the target
`server of the servers 34. The mapping is kept or cached in
`the gateway 33 such that when the proxi?ed and returned
`user request is sent from the user terminal 31 to the gateway
`33 to access the target server of the servers 34, the gateway
`33 does not need to examine the header of the user object
`invocation request to obtain the port number and IP address
`information of the target server from the proxi?ed user
`request. Instead, the gateway 33 automatically maps the
`dynamically assigned port to the port and IP address of the
`target server of the servers 34. This allows the gateway 33
`to automatically map a user request to the IP address and
`port of the target server without requiring the user request to
`expose the IP address and port number of the target server.
`This in turn allows secure connection to be established
`between the user terminal 31 and the target server of the
`servers 34 because the mapping is done without requiring
`the user request to contain information of the IP address and
`port number of the target server. This also allows the user
`object invocation request to be transmitted via the SSL (i.e.,
`the SSL 61), thus providing end-to-end security (e.g.,
`authentication, con?dentiality, and integrity). It also means
`that data can be encrypted end-to-end (i.e., from the user
`terminal 31 to the target object server).
`In addition, the proxi?cation of the object reference is also
`simpli?ed and does not expose the dynamically assigned
`port of the gateway 33 to external client applications (e.g.,
`the user terminal 31). It provides simple access control to the
`target object server so that only traf?c for authoriZed IP
`addresses and ports are passed through the gateway 33. Ports
`can be dynamically opened and closed by authoriZed callers.
`This also allows the gateway 33 to be transparent to the
`external clients (e.g., the user terminal 31).
`During operation, each of the servers 34 publishes or
`advertises its IP address and port number in the form of an
`IOR (Interoperable Object Reference) to external clients.
`When the user terminal 31 needs to access one of the servers
`34, it ?rst proxi?es the IOR and then uses the proxi?ed IOR
`to issue a user object invocation request to access the target
`server at the speci?ed IP address and port number. The
`proxi?cation of the IOR means that the IP address and port
`number of the target server in the IOR need to be replaced
`with a dynamically assigned gateway port of the gateway 33
`and the IP address of the gateway 33. This is done by having
`the user terminal 31 accessing a gateway proxi?cation object
`program in the gateway 33. The following is the gateway
`proxi?cation object program in the gateway 33 that performs
`proxi?cation.
`interface LocalObjectGateway {
`//proxify an IOR
`Object proxify (in Object ref)
`throws NotAuthoriZed, PortNotMapped;
`
`interface RemoteObjectGateway {
`// add access to a new service, returning proxy port
`int mapPort (in int IP, in int port)
`throws NotAuthoriZed, InvalidAddress;
`// remove access to a service
`void unmapPort (in int IP, in int port)
`
`8
`throws NotAuthoriZed, PortNotMapped;
`// look up a mapping, returning proxy port
`int resolve (in int IP, in int port)
`throws NotAuthoriZed, PortNotMapped;
`
`FIG. 5 shows the entire process of proxi?cation and
`secure communication using the proxi?ed IOR. As can be
`seen from FIGS. 3—5, the proxi?cation starts when the user
`terminal 31 sends the IOR proxi?cation request with
`unproxi?ed IOR to the gateway 33. The proxi?cation
`request is communicated via the ?rewall 32 to the gateway
`33 at the TCP/IP layer.
`When the ?rewall 32 receives the IOR proxi?cation
`request, the ?rewall 32 communicates the request to the
`gateway 33 so that the gateway proxi?cation object program
`in the gateway 33 dynamically assigns a port for the port of
`the target server contained in the IOR. Once the dynamically
`assigned port of the gateway 33 is determined, its corre
`sponding port at the ?rewall 32 is also determined. In
`addition, the dynamically assigned port of the gateway 33
`and the IP address of the gateway 33 are mapped to the port
`and IP address of the target server of the servers 34.
`Meanwhile, the port number of