Sneak Preview: Stoneware's webNetwork 4.0q Provides Secure Remote Access

It's a portal. It's a VPN. No, it's webNetwork 4.0 from Stoneware. It can't leap tall buildings in a single bound, but it can give local and remote users a single, secure point of access for all Web content and applications. It can even bring third-party portals together. And by leveraging directory services, webNetwork can give customers, partners and employees personalized desktop views of your Web resources.

I tested webNetwork in our Real-World Labs at Syracuse University. A Java application, webNetwork can run on any platform that supports Sun Microsystems' JVM (Java Virtual Machine) 1.3 or higher. I loaded it on a Windows Server 2000 machine with a 1,400-MHz dual Intel processor, 1 GB of RAM and a Gigabit Ethernet connection. ZeroG's InstallAnywhere set up webNetwork along with a JRE (Java Runtime Environment) 1.4.2-b28 without incident using approximately 100 MB of disk space. Once installed, webNetwork executes a loader (server) as a program or service under Windows.

Before you apply console security, you must step through the two wizards that create and configure your webNetwork server and services and then implement directory services as a local XML document database (LocalTree.XML). If you have many users and demand high performance, you should leverage a supported directory service like Active Directory, OpenLDAP (2.1.x) or Novell's eDirectory. The wizards also populate webNetwork objects into a public context in the selected directory and create a relay service, the default entry point into webNetwork.

The relay acts as a proxy on behalf of users and passes requests to other Web services, which means you can run the relay services on a separate server in a DMZ outside your firewall. It will communicate with the webNetwork server and Web resources inside the firewall using the Java RMI (Remote Method Invocation) protocol.

Test SetupRather than use multiple servers for my tests, I put the relay, server and all services onto one box and changed the default entry point from Port 11001 to Port 80. In this configuration, the relay communicates with the server and other webNetwork services through Port 80 of the loopback address (127.0.0.1).

WebNetwork services are applications that translate to features--such as shared forums and calendars, as well as news, alert and information components--for end users. Your users can publish documents using WebDAV (Web-based Distributed Authoring and Versioning) and view them within browsers using document viewers that support popular file formats, such as .doc, .xml and .pdf. Users also can register for services and configure their own interfaces. WebNetwork supports profiling, so you can customize its appearance to the corporate brand or a departmental standard.

Going beyond the basics, webNetwork is integrated and managed through objects in directory services. This leverages your user directory, enables a single sign-on for Web resources and makes management easier than a snap-in console to MMC (Microsoft Management Console). For resources outside the directory and webNetwork, there's a "lockbox" that stores and manages IDs and passwords for legacy systems. WebNetwork also can bring together published documents from all your HTTP sites, Internet file services like CIFS (Common Internet File System), FTP and even NetWare file systems through NetWare Java Client libraries.

I created a virtual private host (VPH) object in the directory to represent a terminal services (TS) host behind the relay server. The VPH object contains the DNS name or IP address of the destination server, the services port (3389) and the port used by the local client when connecting to the host (3389). It also contains the shortcut information for the TS application. The shortcut's command line can support switches to pass to the local application. Once the VPH object is in the directory, you create a link object to put it on the users' desktops.

Link objects restrict their associated resources to users, groups and other directory objects, such as a specific server running the Relay service. I restricted the TS link object to administrators' desktops and limited it to run through the server hosting the relay services.To test my VPC, I logged on to the webNetwork and my personalized desktop. From an Additional Links tab, I selected the TS link.

At this point, a Java applet (VPCApplet) is started on the local machine. If the machine doesn't have J2RE (Java 2 Runtime Edition), version 1.4.2 is downloaded before the applet runs. Once the local machine has the supported JRE, the VPCApplet runs and TS is executed with the parameters specified in the VPH object. The local client executes TS on Port 3389 of the loopback address 127.0.0.1. The client's RDP requests are then redirected through the tunnel created between the VPCApplet and the relay.

I had no problem setting up VNC remote control and telnet to tunnel to servers through the relay on Ports 80 and 443. But when something's amiss, the client may continue to load the applet for an eternity (one to three minutes). In that case, you'll need to return to the server and cull the detailed logs to trace and fix the error.

Mapping ResourcesAnother way to access Web resources through the relay server is to map them. One-to-one, one-to-many and virtual maps let users access Web services running behind the relay over standard HTTP and/or HTTPS protocols. A map provides access by associating a virtual IP address or assigned port number of the relay server with an internal server's address and port inside the network.

A virtual map was developed for version 4.0 to allow access to Web resources through Port 80 or 443 while requiring only one IP address. To test this new function, I put the server in a virtual host mode and created a virtual map object to point to an internal Apache server. After I enabled a link on the desktop, the relay service piped all my requests to the internal server through Port 80. I could even set up rules to search and replace text and images as Web pages were returned to my Web browser through the relay--very useful if your Web administrator needs to update thousands of pages quickly.

You can distribute webNetwork services across multiple servers and set up services in redundant mode. Failover is supported. WebNetwork also can synchronize Web pages across all relays using a relay central service, and it provides extensive logging capabilities for all services, as well as standard reports. Customizable reports can be created from any ODBC/ JDBC data source.

Sean Doherty is a technology editor and lawyer based at our Syracuse University Real-World Labs. Write to him at [email protected].