Secure server architecture for Web based data management6606708Abstract A double firewalled system is disclosed for protecting remote enterprise servers that provide communication services to telecommunication network customers from unauthorized third parties. A first router directs all connection requests to one or more secure web servers, which may utilize a load balancer to efficiently distribute the session connection load among a high number of authorized client users. On the network side of the web servers, a second router directs all connection requests to a dispatcher server, which routes application server calls to a proxy server for the application requested. A plurality of data security protocols are also employed. The protocols provide for an identification of the user, and an authentication of the user to ensure the user is who he/she claims to be and a determination of entitlements that the user may avail themselves of within the enterprise system. Session security is described, particularly as to the differences between a remote user's copper wire connection to a legacy system and a user's remote connection to the enterprise system over a "stateless"public Internet, where each session is a single transmission, rather than an interval of time between logon and logoff, as is customary in legacy systems. Claims We claim: Description BACKGROUND OF THE INVENTION
Client Server
ClientHello - - - - - - - ->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<- - - - - - - ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished - - - - - - - ->
[ChangeCipherSpec]
<- - - - - - - -
Finished
Login Data <- - - - - - -> Login HTML
*Indicates optional or situation-dependent messages that are not always
sent.
FIG. 8 is a schematic illustration of a logical message format sent from the client browser to the desired middle tier server for a particular application. As mentioned herein with respect to FIG. 4, the messages created by the client Java software are transmitted to the secure Web Servers 24 over HTTPS. For incoming (client-to-server) communications, the Secure Web servers 24 decrypt a request, authenticate and verify the session information. The logical message format from the client to the Web server is shown as follows: .vertline..vertline.TCP/IP .vertline..vertline.encryption .vertline..vertline.http .vertline..vertline.web header dispatcher header .vertline..vertline.proxy-specific data .vertline..vertline. where ".vertline..vertline." separates a logical protocol level, and protocols nested from left to right. FIG. 8 illustrates a specific message sent from the client browser to the desired middle tier server for the particular application. As shown in FIG. 8, the client message 100 includes an SSL encryption header 110 and a network-level protocol HTTP/POST header 112 which are decrypted by the Secure web Server(s) 24 to access the underlying message; a DMZ Web header 114 which is used to generate a cookie 111 and transaction type identifier 116 for managing the client/server session; a dispatcher header 115 which includes the target proxy identifier 120 associated with the particular type of transaction requested; proxy specific data 125 including the application specific metadata utilized by the target proxy to form the particular messages for the particular middle tier server providing a service; and, the network-level HTTP/POST trailer 130 and encryption trailer 135 which are also decrypted by the secure DMZ Web server 24. Alternately, as illustrated in FIG. 5, an alternate message format may be used, as for example between the client workstation 10 and the RTM web server 52. Referring to FIG. 4, after establishing that the request has come from a valid remote user and mapping the request to its associated session, the request is then forwarded through the firewall 29b over a socket connection 23 to one or more decode/dispatcher servers 26 located within the corporate Intranet 30. The messaging sent to the Dispatcher Server 26 will include the user identifier and session information, the target proxy identifier, and the proxy specific data. The decode/dispatcher server 26 then authenticates the user's access to the desired middle-tier service from cached data previously received from the StarOE server as will be hereinafter described in greater detail in connection with User Identification and Authentication. As shown in FIG. 4, the Secure Web server 24 forwards the Dispatcher header and proxy-specific data to the Dispatcher Server 26 "enriched" with the identity of the user (and any other session-related information) as provided by the session data/cookie mapping, the target proxy identifier and the proxy-specific data. The dispatcher server 26 receives the requests forwarded by the Secure Web server(s) 24 and dispatches them to the appropriate application server or its proxy. The message wrappers are examined, revealing the user and the target middle-tier service for the request. A first-level validation is performed, making sure that the user is entitled to communicate with the desired service. The user's entitlements in this regard are fetched by the dispatcher server from StarOE server 217 at logon time and cached. Assuming that the Requestor is authorized to communicate with the target service, the message is then forwarded to the desired service's proxy. Each of these proxy processes may performs: a validation process for examining incoming requests and confirming that they include validly formatted messages for the service with acceptable parameters; a translation process for translating a message into an underlying message or networking protocol; and, a management process for managing the communication of the specific customer request with the middle-tier server to actually get the request serviced. Data returned from the middle-tier server is translated back to client format, if necessary, and returned to the dispatcher server as a response to the request. It should be understood that the application server proxies can either reside on the dispatcher server 26 itself, or, preferably, can be resident on the middle-tier application server, i.e., the dispatcher front end code can locate proxies resident on other servers. User Identification and Authentication FIG. 6 is an illustrative example of a logon Web page of the present invention. At the time of logon, the SSL protocol handshake has been completed, and the logon object and the HTML logon page 230 are the first items to be downloaded. Typically the logon page includes name 232 and password 234 fields for user to enter. The logon page 230, in addition, may include hyper links 236 to other services such as product and service center, programs and promotions, and questions and answers concerning the system of the present invention. In the preferred embodiment, the invention uses a browser such as the Microsoft Internet Explorers versions 4.0.1 or higher as the default browser for access and Java object distribution. The present invention provides an additional COSecurity module which is downloaded with the logon page and wraps the security functionality of specific browsers available off-the-shelf. Downloading the Java objects presents a problem for the enterprise, since Netscape Communicator.TM., Microsoft Internet Explorer.TM. and Sun's HotJava.TM. employ different techniques for downloading Java applets and classes, and it must be determined which browser the user is using before downloading the Java objects and classes. The browser type is also communicated to assist the enterprise in determining how the Java common objects should be downloaded. Netscape Communicator.TM. and HotJava.TM. download Java objects in one or more JAR files, while Microsoft Internet Explorer presently uses CAB files for the same purpose. Microsoft CAB (cabinet) files are equivalent to JAR files. The CAB files are used in the preferred embodiment of the invention for two reasons. First, for convenience in downloading class files so that they are locally resident on the PC. The browser tools, common objects and application class files are zipped up and downloaded to the java trusted library directory. Only trusted, i.e. signed, applets can make use of these class files. Secondly, signing an applet, and obtaining permission from the user, enables the Java objects to break out of the "sandbox" and get around Java security restrictions, and enable local disk and file access and system I/O such as printing. Signed applets enable the user to verify the applets as being from a trusted source and allow applets to write to the local disk, print, read local files, and connect to a server other than the one that launches the applet. In order for an applet to be signed, the applet requires a digital certificate to be assigned to a JAR (Java ARchive) or equivalent archive file. As discussed previously, this digital certificate may be a software publisher certificate or the certificate used to verify the server as a trusted server during the SSL handshake process. FIG. 7 is a diagram which illustrates a security module design having clean separation from the browser specific implementations. The security module includes the main COSecurity class 402, and the interface COBrowserSecurityInterface 404. The COSecurity object checks browser type upon instantiation. It does so by requesting the "java.vendor" system property. In the preferred embodiment of the invention, Microsoft Internet Explorer.TM. is the default browser, but if the browser is Netscape, for example, the class then instantiates by name the concrete implementation of the Netscape security interface, nmco.security.securityimpls. CONetscape4_0 SecurityImpl 406. Otherwise, it instantiates nmco.security.securityimpls. CODefaultSecurityImpl 408. The COBrowserSecurityInterface 404 mirrors the methods provided by COSecurity 402. Concrete implementations such as CONetscape4_0OSecurityImpl 406 for Netscape Communicator and CODefaultSecurityImpl 408 as a default are also provided. Adding a new implementation 410 is as easy as implementing the COBrowserSecurityInterface, and adding in a new hook in COSecurity. After using "java.vendor" to discover what browser is being used, COSecurity 402 instantiates by name the appropriate concrete implementation. This is done by class loading first, then using Class.newInstance() to create a new instance. The newinstance() method returns a generic object; in order to use it, it must be cast to the appropriate class. COSecurity 402 casts the instantiated object to COBrowserSecurityInterface 404, rather than to the concrete implementation. COSecurity 402 then makes calls to the COBrowserSecurityInterface "object," which is actually a concrete implementation "in disguise." This is an example of the use of object oriented polymorphism. This design cleanly separates the specific implementations which are browser-specific from the browser-independent COSecurity object. Each COApp object may either create their own COSecurity object using the public constructors, or retrieve the CoSecurity object used by the backplane via COBackPlane.getSecurity(). In general, the developer of the applications to be run will use the CoSecurity object whenever the COApp needs privileged access to any local resource, i.e., access to the local disk, printing, local system properties, and starting external processes. The following represents an example of the code generated when using the security object.
// Instantiating COSecurity objectCOSecurity
security = new CoSecurity();
// Now access a privileged resource
try {
String s =
security.getSystemProperty("user.home");
System.out.println(s);
}
catch(COSecurityException cose)
{
// take care in case of security exception
}
Referring back to FIG. 10, once the browser type has been confirmed, the logon applet checks for the name/password entry and instantiates a session object in step 292, communicating the name/password pair to the enterprise system. The session object sends a message containing the name/password to the StarOE server 49 for user validation in step 294. When the user is properly authenticated by the server in step 296, another Web page which launches the backplane object is downloaded in steps 298, 300, 304. This page is referred to as a home page. At the same time, all the remaining application software objects are downloaded in CAB or JAR files as indicated at step 302. If the system of the present invention determines that the backplane and application files have been already downloaded, the steps 300, 302, 304 are not performed. The backplane object is then instantiated in step 306. FIG. 4, as described previously, shows an example of a home page, typically a new Web page having the backplane object. The home page 60 is downloaded after the authentication via the logon page. The home page 60 comprises icons 70 for each of the application services as well as an application tool bar 254 for invoking the services. The application tool bar 254 is different from the icons 70 in that the application tool bar 254 remains on a screen, even when the home page 60 is no longer displayed. The home page also typically comprises HTML links to other services 256. These services may be new information center, features benefits, or a link 259 to the networkMCI Interact support center for the system of the present invention. Referring again to FIG. 10, the backplane communicates with the StarOE server 49 to retrieve the user's entitlements in step 308. The entitlements represent specific services the user has subscribed and has privilege to access. It also describes what entitlements the user may have within any single service. For example, from the COUser context, the backplane can obtain the list of applications that the user is entitled to access. In addition, each COApp holds set of entitlements within that application in COAppEntitlements object. Using the information from the COUser context, the backplane knows which COApps to provide, e.g., which buttons to install in its toolbar. The backplane stores the user specific entitlements in memory for other processes to access. After determining the entitlements, the backplane initiates a new thread and starts an application toolbar in step 310. The application toolbar includes the services to which the remote user has subscribed and may select to run. From the application toolbar, a user is able to select a service to run. Upon user selection, the selection is communicated from the application toolbar to the backplane in steps 312, 314, which then launches the graphical user interface program associated with the selected service. The application toolbar remains on the user display, even after a particular service has been initiated. This is useful when a remote user desires to start up another service directly from having run a previous service because the user then need not retrieve the home page again. If it is determined that the user entered password is not valid in step 290 or step 296, an attempted logon count is incremented in step 316. If the user's attempted logon count is greater than a predefined allowed number of tries as indicated in step 318, a message is conveyed to the user in step 320 and the user must restart the browser. If the user's attempted logon count is not greater than the predefined allowed number of tries, a "failed login" message is conveyed to the user in step 322, and the user is prompted to reenter name/password in step 288. If it is determined that the user password has expired, the user is prompted to change the password in step 324. For example, the user may be required to change the password every 30 days for security reasons. Whenever the user changes the password, the new password is transmitted in real time to a server responsible for updating and keeping the password entry for the user. The user than enters the new password in step 324 and continues with the processing described above in step 290. The present invention includes a user unit for representing a user of a current session. The user unit is generally implemented as a COUser class extending java.lang.Object. The COUser class object typically holds information including a user profile, applications and their entitlements. In order to minimize network traffic, the amount of data carried by the COUser is minimal initially, and becomes populated as requests are processed. The requests are generally processed by retrieving information from the Order Entry service. The profile information is then stored and populated in the COUser object should such information be requested again. A COUser object is created when the user logs in, and holds the username and password of the user as an object in the COClientSession object. The session object is contained within the backplane, which manages the session throughout its lifetime. The code below illustrates how this occurs:
// Within the backplane
COClientSession session = new COClientSession();
try {
Session.logon ("username", "password");
} catch (COClientLogonException e) { . . . };
// Should the User object be required
COUser user = session.getUser();
The logon method of the COClientSession object communicates with the Order Entry server, a back-end authentication mechanism, for authenticating the user. The COUser that may be obtained from the COClientSession immediately after the login process is very sparse. It includes a limited set of information such as username, a list of applications that user is entitled to, for example. The details of each entitlement information are retrieved at the time of actual processing with those information. Session Security As described previously, the SSL protocol includes one level of session security, and may negotiate and change in cipher code between sessions. Additionally, the present invention employs the "cookie" feature set of contemporary browsers to maintain session security, and prevent session hijacking or the use of a name and password obtained by sniffing, spoofing or EMR monitoring. FIG. 11 is a data flow diagram illustrating data flow among the processing modules of the "network MCI Interact" during logon, entitlement request/response, heartbeat transmissions and logoff procedures. As shown in FIG. 11, the client platform includes the networkMCI Interact user 340 representing a customer, a logon Web page having a logon object for logon processing 342, a home page having the backplane object. The Web server 344, the dispatcher server 346, cookie jar server 352, and StarOE server 348 are typically located at the enterprise site. As described above, following the SSL handshake, certain cab files, class files and disclaimer requests are downloaded with the logon Web page as shown at 440. At the logon Web page, the customer 340 then enters a userid and password for user authentication as illustrated at 440. The customer also enters disclaimer acknowledgment 440 on the logon page 342. If the entered userid and password are not valid or if there were too many unsuccessful logon transactions, the logon object 342 communicates the appropriate message to the customer 340 as shown at 440. A logon object 342, typically an applet launched in the logon Web page connects to the Web server 344, for communicating a logon request to the system as shown at 442. The logon data, having an encrypted userid and password, is sent to the dispatcher 346 when the connection is established as shown at 444. The dispatcher 346 then decrypts the logon data and sends the data to the StarOE 348 after establishing a connection as shown at 446. The StarOE 348 validates the userid and password and sends the results back to the dispatcher 346 as illustrated at 446 together with the user application entitlements. The dispatcher 346 passes the data results obtained from the StarOE 348 to the Web server 344 as shown at 444, which passes the data back to the logon object 342 as shown at 442. The customer 340 is then notified of the logon results as shown as 440. When the customer 340 is validated properly, the customer is presented with another Web page, referred to as the home page 350, from which the backplane is typically launched. After the user validation, the backplane generally manages the entire user session until the user logs off the "networkMCI Interact." As shown at 448, the backplane initiates a session heartbeat which is used to detect and keep the communications alive between the client platform and the enterprise Intranet site. The backplane also instantiates a COUser object for housekeeping of all client information as received from the StarOE 348. For example, to determine which applications a current customer is entitled to access and to activate only those application options on the home page for enabling the customer to select, the backplane sends a "get application list" message via the Web server 344 and the dispatcher 346 to the StarOE 348 as shown at 448, 444, and 446. The entitlement list for the customer is then sent from the StarOE 348 back to the dispatcher 346, to the Web server 344 and to the backplane at the home page 350 via the path shown at 446, 444, and 448. The application entitlements for the customer are kept in the COUser object for appropriate use by the backplane and for subsequent retrieval by the client applications. The entitlement information for COUser is stored in a cookie jar 352, maintained in the cookie jar server 32 or the dispatcher server 26 (illustrated in FIGS. 4 and 5). When the Web server receives the entitlement requests from the backplane at the home page 350 or from any other client applications, the Web server 344 makes a connection to the cookie jar 352 and checks if the requested information is included in the cookie jar 352 as shown at 450. The cookie jar 352 is a repository for current customer sessions and the individual session details are included in a cookie including the entitlement information from the OE server 348. During the logon process described above, the OE server 348 may include in its response, the entitlements for the validated customer. The dispatcher 346 transfers the entitlement data to the Web server 344, which translates it into a binary format. The Web server 344 then transmits the binary entitlement data to the cookie jar 352 for storage and retrieval for the duration of a session. Accordingly, if the requested information can be located in the cookie jar 352, no further request to the StarOE 348 may be made. This mechanism cuts down on the response time in processing the request. Although the same information, for example, customer application entitlements or entitlements for corp ids, may be stored in the COUser object and maintained at the client platform as described above, a second check is usually made with the cookie jar 352 via the Web server 344 in order to insure against a corrupted or tampered COUser object's information. Thus, entitlements are typically checked in two places: the client platform 10 via COUser object and the Web server 344 via the cookie jar 352. When a connection is established with the cookie jar 352, the Web server 344 makes a request for the entitlements for a given session as shown at 450. The cookie jar 352 goes through its stored list of cookies, identifies the cookie for the session and returns the cookie to the Web server 344 also shown at 450. The Web server 344 typically converts the entitlements which are received in binary format, to string representation of entitlements, and sends the entitlement string back to the backplane running on the client platform 10. Furthermore, the cookie jar 352 is used to manage heartbeat transactions. Heartbeat transactions, as described above, are used to determine session continuity and to identify those processes which have died abnormally as a result of a process failure, system crash or a communications failure, for example. During a customer session initialization, the cookie jar 352 generates a session id and sets up "heartbeat" transactions for the customer's session. Subsequently, a heartbeat request is typically sent from a process running on a client platform to the Web server 344, when a connection is established, as shown at 448. The Web server 344 connects to the cookie jar 352 and requests heartbeat update for a given session. The cookie jar 352 searches its stored list of cookies, identifies the cookie for the session and updates the heartbeat time. The cookie jar 352 then sends the Web server 344 the updated status heartbeat as shown at 450. The Web server 344 then sends the status back to the client platform process, also as shown at 450. When a customer wants to logoff, a logoff request transaction may be sent to the Web server 344. The Web server 344 then connects to the cookie jar 352 and requests logoff for the session as shown at 450. The cookie jar 352 identifies the cookie for the session and deletes the cookie. After deleting the cookie, the cookie jar 352 sends a logoff status to the Web server 344, which returns the status to the client platform. Other transaction requests are also sent via the Web server 344 and the cookie jar 352 as shown in FIG. 12. FIG. 12 is a data flow diagram for various transactions communicated in the system of the present invention. Typically, when a customer enters a mouse click on an application link as shown at 460, an appropriate transaction request stream is sent to the Web server as shown at 462. The Web server 344 typically decrypts the transaction stream and connects to the cookie jar 352 to check if a given session is still valid as shown at 464. The cookie jar 352 identifies the cookie for the session and sends it back to the Web server 344 as shown at 464. The Web server 344 on receipt of valid session connects to the dispatcher 346 and sends the transaction request as shown at 466. When the dispatcher 346 obtains the request, it may also connect to the cookie jar 352 to validate the session as shown at 468. The cookie jar 352 identifies the cookie for the session and sends it back to the dispatcher 346 as shown at 468. The dispatcher 346, upon receiving the valid session connects to a targeted application server or proxy 354, which may include StarOE, and sends the request transaction to the target as shown at 470. The server or proxy 354 processes the request and sends back the response as stream of data which is piped back to the dispatcher 346 as shown at 470. The dispatcher 346 pipes the data back to the Web server 344 as shown at 466, which encrypts and pipes the data to the client platform as shown at 462, referred to as the home page 350 in FIG. 12. The present invention includes a client communications unit for providing a single interface from which the backplane and the applications may send messages and requests to back-end services. The client communications unit includes a client session unit and a transactions unit. The client session unit and the transactions unit comprise classes used by client applications to create objects that handle communications to the various application proxies and/or servers. Generally, the entire communications processes start with the creation of a client session after a login process. This is started through the login process. The user logs into user's Web page with a username and password. During a login process, a remote client session object of class COClientSession is created, and the COClientSession object passes the username and password information pair obtained from the login process to a system administrative service which validates the pair. The following code instructions are implemented, for example, to start up a session using the COClientSession class.
COClientSession ss = new COClientSession();
try {
ss.setURL(urlString);
ss.logon("jsmith", "myPassword");
} catch (CoClientLogonException e) { . . .
} catch (MalformedURLException e) { . . . };
In addition, the COClientSession object includes a reference to a valid COUser object associated with the user of the current COClientSession object. The client session object also provides a session, where a customer logs on to the system at the start of the session, and if successfully authenticated, is authorized to use the system until the session ends. The client session object at the same time provides a capability to maintain session-specific information for the life/duration of the session. Generally, communications to and from the client takes place over HTTPS which uses the HTTP protocols over an SSL encrypted channel. Each HTTP request/reply is a separate TCP/IP connection, completely independent of all previous or future connections between the same server and client. Because HTTP is stateless, meaning that each connection consists of a single request from the client which is answered by a single reply by a server, a novel method is provided to associate a given HTTP request with the logical session to which it belongs. When a user is authenticated at login via the system administrative server, the client session object is given a session identifier or "cookie," a unique server-generated key which identifies a session. The session key is typically encapsulated in a class COWebCookie, "public COWebCookie (int value)," where value represents a given cookie's value. The client session object holds this key and returns it to the server as part of the subsequent HTTP request. The Web server maintains a "cookie jar" which is resident on the dispatcher server and which maps these keys to the associated session. This form of session management also functions as an additional authentication of each HTTPS request, adding security to the overall process. In the preferred embodiment, a single cookie typically suffices for the entire session. Alternately, a new cookie may be generated on each transaction for added security. Moreover, the cookie jar may be shared between the multiple physical servers in case of a failure of one server. This mechanism prevents sessions being dropped on a server failure. In addition, to enable a server software to detect client sessions which have "died," e.g., the client session has been disconnected from the server without notice because of a client-side crash or network problem, the client application using the client session object "heartbeats" every predefined period, e.g., 1 minute to the Web server to "renew" the session key (or record). The Web server in turn makes a heartbeat transaction request to the cookie jar. Upon receipt of the request, the cookie jar service "marks" the session record with a time stamp indicating the most recent time the client communicated to the server using the heartbeat. The cookie jar service also alarms itself, on a configurable period, to read through the cookie jar records (session keys) and check the time stamp (indicating the time at which the client was last heard) against the current time. If a session record's delta is greater than a predetermined amount of time, the cookie jar service clears the session record, effectively making a session key dead. Any subsequent transactions received with a dead session key, i.e., nonexistent in the cookie jar, are forbidden access through the Firewall. The heartbeat messages are typically enabled by invoking the COClientSession object's method "public synchronized void enableSessionHeartbeat (boolean enableHeartbeat)," where enableHeartbeat is a flag to enable or disable heartbeat for a session. The heartbeat messages are typically transmitted periodically by first invoking the COClientSession object's method "public synchronized void setHeartbeatInterval (long millsecsInterval)," where the heartbeat interval is set in milliseconds, and by the COClientSession object's method "protected int startHeartbeat()," where the heartbeat process starts as soon as the heartbeat interval is reached. Failure to "heartbeat" for consecutive predefined period, e.g., one hour, would result in the expiration of the session key. Enterprise Security Enterprise Security is directed to the security of the enterprise network and the data maintained by the various enterprise applications with respect to the open nature of the Internet, and the various attacks on the system or data likely to result from exposure to the Internet. Usual enterprise security is focused on internal procedures and employees, since this represents the biggest single area of exposure. Strong passwords, unique user Ids and the physical security of the workstations are applicable to both internal employees and external customers and users who will access the enterprise applications. It is noted that many of the previously described features relating to data encryption for communications security and session security are essential parts of enterprise security, and cooperate with enterprise architecture and software infrastructure to provide security for the enterprise. For example, as will be hereinafter described in detail, the present invention uses strong symmetric key encryption for communications through the firewalls to the application servers. This internal symmetric key encryption, when coupled with external public key encryption provides an extra level of security for both the data and the software infrastructure. FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture 10. As shown in FIG. 5, the system is divided into three major architectural divisions including: 1) the customer workstation 10 which includes those mechanisms enabling customer connection to the Secure web servers 24; 2) a secure network area 17, known as the DeMilitarized Zone "DMZ" set aside on MCI premises double firewalled between the public Internet 15 and the MCI Intranet 66 to prevent potentially hostile customer attacks; and, 3) the MCI Intranet Midrange Servers 40 and Legacy Mainframe Systems 20 which comprise the back end business logic applications. As illustrated in FIG. 5, the present invention includes a double or complex firewall system that creates a "demilitarized zone" (DMZ) between two firewalls 29a, 29b. In the preferred embodiment, a hybrid or complex gateway firewall system is used, and the firewalls 29(a),(b) of FIGS. 1, 4 and 5 are illustrative to represent the concept diagrammatically. In the preferred embodiment, they may include port specific filtering routers, which may only connect with a designated port address. For example, router 29(a) may connect only to the addresses set for the HydraWeb.RTM. 45 (or web servers 24) within the DMZ, and router 29(b) may only connect to the port addresses set for the dispatcher server 26 within the network. In addition, the dispatcher server connects with an authentication server, and through a proxy firewall to the application servers. This ensures that even if a remote user ID and password are hijacked, the only access granted is to one of the web servers 24 or to intermediate data and privileges authorized for that user. Further, the hijacker may not directly connect to any enterprise server in the enterprise intranet beyond the DMZ, thus ensuring internal company system security and integrity. Even with a stolen password, the hijacker may not connect to other ports, root directories or application servers within the enterprise system, and the only servers that may be sabotaged or controlled by a hacker are the web servers 24. The DMZ acts as a double firewall for the enterprise intranet because of the double layer of port specific filtering rules. Further, the web servers 24 located in the DMZ never store or compute actual customer sensitive data. The web servers only transmit the data in a form suitable for display by the customer's web browser. Since the DMZ web servers do not store customer data, there is a much smaller chance of any customer information being jeopardized in case of a security breach. In the preferred embodiment, firewalls or routers 29 (a),(b) are a combination of circuit gateways and filtering gateways or routers using packet filtering rules to grant or deny access from a source address to a destination address. All connections from the internal application servers are proxied and filtered through the dispatcher before reaching the web servers 24. Thus it appears to any remote site, that the connection is really with the DMZ site, and identity of the internal server is doubly obscured. This also prevents and direct connection between any external and any internal network or intranet computer. The filtering firewalls 29 (a), (b) may also pass or block specific types of Internet protocols. For example, FTP can be enabled only for connections to the In-Box server 41, and denied for all other destinations. SMTP can also be enabled to the In-Box server, but Telnet denied. The In-box server 41 is a store and forward server for client designated reports, but even in this server, the data and meta-data are separated to further secure the data. As previously described, the customer access mechanism is a client workstation 10 employing a Web browser 14 for providing the access to the networkMCI Interact system via the public Internet 15. When a subscriber connects to the networkMCI Interact Web site by entering the appropriate URL, a secure TCP/IP communications link 22 is established to one of several Web servers 24 located inside a first firewall 29a in the DMZ 17. Preferably at least two web servers are provided for redundancy and failover capability. In the preferred embodiment of the invention, the system employs SSL encryption so that communications in both directions between the subscriber and the networkMCI Interact system are secure. In the present embodiment, the DMZ Secure Web servers 24 are presently DEC 4100 systems having Unix or NT-based operating systems for running services such as HTTPS, FTP, and Telnet over TCP/IP. The web servers may be interconnected by a fast Ethernet LAN running at 100 Mbit/sec or greater, preferably with the deployment of switches within the Ethernet LANs for improved bandwidth utilization. One such switching unit included as part of the network architecture is a HydraWEB.TM. unit 45, manufactured by HydraWEB Technologies, Inc., which provides the DMZ with a virtual IP address so that subscriber HTTPS requests received over the Internet will always be received. The Hydraweb unit 45 implements a load balancing algorithm enabling intelligent packet routing and providing optimal reliability and performance by guaranteeing accessibility to the "most available" server. It particularly monitors all aspects of web server health from CPU usage, to memory utilization, to available swap space so that Internet/Intranet networks can increase their hit rate and reduce Web server management costs. In this manner, resource utilization is maximized and bandwidth (throughput) is improved. It should be understood that a redundant Hydraweb unit may be implemented in a Hot/Standby configuration with heartbeat messaging between the two units (not shown). Moreover, the networkMCI Interact system architecture affords web server scaling, both in vertical and horizontal directions. Additionally, the architecture is such that new secure web servers 24 may be easily added as customer requirements and usage increases. The use of the HydraWEB.TM. enables better load distribution when needed to match performance requirements. There are two ways a web server can be scaled, vertically, within a single machine with large CPU, disk, network I/O, etc., capacity, and, horizontally, distributed across multiple machines giving both scaling and service availability. This architecture has no single point of failure. In horizontally distributed web servers as shown in FIGS. 14 and 15, it is important to maintain a state of a user connection because if a connection is lost the client application can then continue using another Web server. In this architecture any server can pick up a client connection and continue. There are three basic requirements for horizontally distributed web servers: 1. Either a single virtual IP address, eliminating the need for high availability (HA) redundancy in the server pool to provide IP failover, or a pool of addresses that can be drawn from, usually implemented using round robin DNS. 2. Multiple machines that run the same software, allowing a lower entry point to Web based service as long as the machines can handle some excess capacity. 3. Common content storage shared across all the servers. File servers, such as Raid 0+1, NFS and others may be used to provide HA in the event of disk, machine, or interface failure. The administrative overhead is reduced because of commonality of the content, scaling is easy since it is a network resource, and a common cache for customer state. As shown in FIG. 14, a configuration using HydraWEB 45 for virtual IP addressing, multiple Web servers 24, and file servers for content storage 240. The file server is not required to provide content storage, content can be transferred from master copy to Web machines using a mechanism such as FTP or rdist. If a file server is not used then client state information will be maintained through server to server communication. Using a file server gives a security advantage over local disk, content can be mounted read only, so in the event of a web system compromise the content storage will not be corrupted. As shown in FIG. 15, an alternative to using a file server would be to put all content on each server 24. This improves local performance and isolates Web servers from each other. Ideally all Web servers 24 will be updated at once with any changes to Web content. With multiple machines this is possible through a number of schemes. Unix provides rdist, CPIO, FTP and others, which can update content on local disk. As shown in FIG. 5, the most available Web server 24 receives subscriber HTTPS requests, for example, from the HydraWEB.TM. 45 over a connection 35a and generates the appropriate encrypted messages for routing the request to the appropriate MCI Intranet midrange web server over connection 35b, router 55 and connection 23. Via the Hydraweb unit 45, a TCP/IP connection 38 links the Secure Web server 24 with the MCI Intranet Dispatcher server 26. Further as shown in the DMZ 17 is a second RTM server 52 having its own connection to the public Internet via a TCP/IP connection 32. As described in co-pending U.S. Patent application No. 09/159,516, filed Apr. 11, 2001, now U.S. Pat. No. 6,470,386, this server provides real-time session management for subscribers of the networkMCI Interact Real Time Monitoring system. An additional TCP/IP connection 48 links the RTM Web server 52 with the MCI Intranet Dispatcher server 26. With more particularity, as further shown in FIG. 5, the networkMCI Interact physical architecture includes two routers: a first router 55 for routing encrypted subscriber messages from a Secure Web server 24 to the Dispatcher server 26 located inside the second firewall 29b; and, a second router 65 for routing encrypted subscriber messages from the RTM Web server 52 to the Dispatcher server 26 inside the second firewall. In the preferred embodiment, the routers are manufactured by Cisco Systems, Inc. Although not shown, each of the routers 55, 65 may additionally route signals through a series of other routers before eventually being routed to the nMCI Interact Dispatcher server 26. In operation, each of the Secure servers 24 function to decrypt the client message, presentably via the SSL implementation, and unwrap the session key and verify the users session from the COUser object authenticated at Logon. After establishing that the request has come from a valid user and mapping the request to its associated session, the Secure Web servers 24 will re-encrypt the request using RSA encryption and forward it over a second secure socket connection 23 to the dispatcher server 26 inside the enterprise Intranet. FIGS. 13(a) and 13(b) are schematic illustrations showing the message format passed between the dispatcher 26 and the relevant application specific proxy, (FIG. 13(a)) and the message format passed between the application specific proxy back to the Dispatcher 26 (FIG. 13(b)). As shown in FIG. 13(a), all messages between the Dispatcher and the Proxies, in both directions, begin with a common header 150 to allow leverage of common code for processing the messages. A first portion of the header includes the protocol version 165 which may comprise a byte of data for identifying version control for the protocol, i.e., the message format itself, and is intended to prevent undesired mismatches in versions of the dispatcher and proxies. The next portion includes the message length 170 which, preferably, is a 32-bit integer providing the total length of the message including all headers. Next is the echo/ping flag portion 172 that is intended to support a connectivity test for the dispatcher-proxy connection. For example, when this flag is non-zero, the proxy immediately replies with an echo of the supplied header. There should be no attempt to connect to processes outside the proxy, e.g. the back-end application services. The next portion indicates the Session key 175 which is the unique session key or "cookie" provided by the Web browser and used to uniquely identify the session at the browser. As described above, since the communications middleware is capable of supporting several types of transport mechanisms, the next portion of the common protocol header indicates the message type/mechanism 180 which may be one of four values indicating one of the following four message mechanisms and types: 1)Synchronous transaction, e.g., a binary 0; 2) Asynchronous request, e.g., a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) bulk transfer, e.g., a binary 3. Additionally, the common protocol header section includes an indication of dispatcher-assigned serial number 185 that is unique across all dispatcher processes and needs to be coordinated across processes (like the Web cookie (see above)), and, further, is used to allow for failover and process migration and enable multiplexing control between the proxies and dispatcher, if desired. A field 140 indicates the status is unused in the request header but is used in the response header to indicate the success or failure of the requested transaction. More complete error data will be included in the specific error message returned. The status field 140 is included to maintain consistency between requests and replies. As shown in FIG. 13(a), the proxy specific messages 178 are the metadata message requests from the report requester client and can be transmitted via synchronous, asynchronous or bulk transfer mechanisms. Likewise, the proxy specific responses are metadata response messages 180 again, capable of being transmitted via a synchronous, an asynchronous or bulk transfer transport mechanism. It should be understood that the application server proxies can either reside on the dispatcher server 26 itself, or, preferably, can be resident on the middle-tier application servers 40, i.e., the dispatcher front end code can locate proxies resident on other servers. As mentioned, the proxy validation process may include parsing incoming requests, analyzing them, and confirming that they may include validly formatted messages for the service with acceptable parameters. If necessary, the message is translated into an underlying message or networking protocol. If no errors are found, the proxy then manages the communication with the middle-tier server to actually get the request serviced. The application proxy supports application specific translation and communication with the back-end application server for both the Web Server (java applet originated) messages and application server messages. Particularly, in performing the verification, translation and communication functions, the Report Manager server, the Report Scheduler server and Inbox server proxies each employ front end proxy C++ objects and components. For instance, a utils.c program and a C++ components library, is provided for implementing general functions/objects. Various C++ parser objects are invoked which are part of an object class used as a repository for the RM metadata and parses the string it receives. The class has a build member function which reads the string which includes the data to store. After a message is received, the parser object is created in the RMDispatcher.c object which is a file which includes the business logic for handling metadata messages at the back-end. It uses the services of an RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. Invocation occurs in MCIRMServerSocket.C when an incoming message is received and is determined not to be a talarian message. RMSErverSocket.c is a class implementing the message management feature in the Report Manager server. Public inheritance is from MCIServerSocket in order to create a specific instance of this object. This object is created in the main loop and is called when a message needs to be sent and received; a Socket.c class implementing client type sockets under Unix using, e.g., TCP/IP or TCP/UDP. Socket.C is inherited by ClientSocket.C:: Socket(theSocketType, thePortNum) and ServerSocket.C:: Socket(theSocketType, thePortNum) when ClientSocket or ServerSocket is created. A ServerSocket.c class implements client type sockets under Unix using either TCP/IP or TCP/UDP. ServerSocket.C is inherited by RMServerSocket when RMServerSocket is created. An InboxParser.c class used as a repository for the RM Metadata. The class' "build" member function reads the string which includes the data to store and the class parses the string it receives. After a message has been received, the MCIInboxParser object is created in inboxutl.c which is a file which includes the functions which process the Inbox requests, i.e, Add, Delete, List, Fetch and Update. Additional objects/classes include: Environ.c which provides access to a UNIX environment; Process.c which provides a mechanism to spawn child processes in the UNIX environment; Daemon.c for enabling a process to become a daemon; Exception.c for exception handling in C++ programs; and, RMlog.c for facilitating RM logging. In addition custom ESQL code for RM/database interface is provided which includes the ESQC C interface (Informix) stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, and GPL messages. The functions call the stored procedures according to the message, and the response is built inside the functions depending on the returned values of the stored procedures. A mainsql.c program provides the ESQL C interface for messages from the report manager and report viewer. Outgoing (server-to-client) communications follow the reverse route, i.e., the proxies feed responses to the decode/dispatcher server 26 and communicate them to the DMZ Web servers 24 over the socket connection. The Web servers 26 will forward the information to the client 10 using SSL. The logical message format returned to the client from the middle tier service is shown as follows: .vertline..vertline.TCP/IP .vertline..vertline.encryption .vertline..vertline.http .vertline..vertline.web response .vertline..vertline.dispatcher response .vertline..vertline.proxy-specific response .vertline..vertline. where ".vertline..vertline." separates a logical protocol level, and protocols nested from left to right. Application Security Application security relates to the security within the legacy application that determines authorization for command and control, read, write and modify files, and print and report options inherent to the application. Inasmuch as the present invention is intended to link a number of disparate legacy applications to a common interface, a provision must be made at the application server level to satisfy the application security requirements of the legacy application. In the present invention, the user id, the user's password authentication, and the user's application entitlements are stored on the StarOE server 49, as previously described with respect to FIGS. 4 and 5. At log-on, The initial population of COUser object, as indicated at step 308 in FIG. 10, is sparse and initially only represents entitlements to one or more specific applications. When the user logs into a specific application, the application server retrieves specific and detailed user entitlements for that application from the StarOE server 49 in a separate transaction. These entitlements may be different from application to application. Thus, a user may have read and write privileges with respect to one legacy application, only read privileges with respect to another legacy application. A representative example is illustrated in FIG. 16 and will be described with respect to the Toll Free Network Manager application provided through the TFNM server 45 as illustrated in FIGS. 4 and 5. It is understood that this description is representative of application security in general, and that the application level security features may vary from legacy application to legacy application depending on the needs of the legacy application and the functions provided through it. As shown in FIG. 16, when a user 10 logs into the enterprise network over the Internet and selects a specific application 47, the user's logon password and user ID, entered on a user's Web page 230, is verified by StarOE 49. The application 47 calls StarOE 49 asking for the User Security information which includes an Enterprise ID, Corp IDs, and Racf IDs associated with the Corp IDs. The application 47 then calls Netcap 20 (b) for a function level security profile based on Racf ID and Corp ID. If the user has Enterprise level security, Netcap 20(b) is called for the list of Corps for that Enterprise. When the Web page 230 is accessed, the user logs in and a User Common Object is created. At this point, a message is sent via the Dispatcher to the StarOE Server 49 to validate a user. When the user selects the application 47, through Java applets using TCP/IP from the home Web page 230, StarOE 49 validates the user's id and password. If successful, StarOE 49 allows the user into the application 47. The application 47 server will send a SecRequest message to the StarOE server 49 directly requesting a user's security. SecRequest Message contains UserId, Enterprise Id, OEServer Address, OEServer Port. Enterprise Id is obtained from the Common User Object from the Platform. The StarOE server 49 sends a Security response SecRsp. This response contains a flag that marks the user as Production support Update, Production support Read-only or as a regular user. The user security profile, SecProfile, contains the list of Corp Ids that a User is allowed to access within the application 47. The data elements are: Corpld-Corp Id the user has access to within StarOE, DefaultInd-Default CorpId Indicator having `Y` or `N` values, AccessId-User's generated access Id (RACF ID). Once the user 10 logs into the application 47 and the StarOE 49 security message has been received, then a Registry call is made to Netcap 20(b) requesting a User Security Profile. Security from Netcap 20(b) is by Racf Id and Corp Id. For each Corp Id a user has access to, they must have a Racf Id. If a user has Enterprise level security, then the list of Corps under that Enterprise within Netcap have the same security as the Enterprise. While the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.
|
Same subclass Same class | ||||||||||