WebTrac 10.3 Planning Guide - connect001.rectrac.comconnect001.rectrac.com/help-tomcat6/Content/Resources/Misc Docs... · All VSI application software is developed using 4GL Progress

WebTrac 10.3 Planning Guide

Table of Contents INTRODUCTION .............................................................................................................................................. 1

CURRENT APPLICATION SOFTWARE PRODUCTS ..................................................................................................... 1 WEBTRAC INTEGRATED WEB SOFTWARE .............................................................................................................. 2 WEBTRAC FEATURES .......................................................................................................................................... 2 WEBTRAC DEPLOYMENT ..................................................................................................................................... 3 WEBSPEED & OPENEDGE ENVIRONMENT ............................................................................................................. 3

WebSpeed Architecture ..................................................................................................................... 3 WebSpeed Components .................................................................................................................... 4

WebSpeed Workshop ................................................................................................................. 4 WebSpeed Transaction Server ................................................................................................... 4 WebSpeed Messenger ............................................................................................................... 5 NameServer ............................................................................................................................... 5 Language support ....................................................................................................................... 5

MINIMUM SYSTEM REQUIREMENTS WEBSPEED & OPENEDGE TRANSACTION SERVER ............................................... 5 MINIMUM HARDWARE REQUIREMENTS WEBSPEED & OPENEDGE TRANSACTION SERVER .......................................... 6 WEBSPEED REQUEST ROUND-TRIP ...................................................................................................................... 6 SUPPORTED WEBTRAC CONFIGURATIONS ............................................................................................................. 9 PROGRESS WEBSPEED SUPPORTED WEB SERVERS & BROWSERS ....................................................................... 11

Supported Web servers ................................................................................................................... 11 Supported Web browsers and preference settings .......................................................................... 11

INSTALLATION PLANNING ......................................................................................................................... 12

INSTALLING A DEPLOYMENT ENVIRONMENT .......................................................................................................... 12 UNDERSTANDING YOUR WEB SERVER ................................................................................................................ 12 BANDWIDTH BETWEEN WEB SERVER AND TRANSACTION SERVER ......................................................................... 13

Internet Connection Bandwidth Comparison Chart .......................................................................... 14 Latency versus Bandwidth…What is it? ........................................................................................... 16

VSI RESPONSIBILITIES ...................................................................................................................................... 17 CUSTOMER (USER) RESPONSIBILITIES ................................................................................................................ 18 CREDIT CARD AUTHORIZATION OPTIONS ............................................................................................................. 20

For More Information ....................................................................................................................... 20

APPENDIX A: SECURITY AND FIREWALLS .............................................................................................. 22

GENERAL SECURITY ISSUES ............................................................................................................................... 22 AUTHENTICATION .............................................................................................................................................. 22 ENCRYPTION .................................................................................................................................................... 22 FIREWALLS ....................................................................................................................................................... 23

One Firewall or Two? ....................................................................................................................... 24

Vermont Systems, Inc. 01/04/11 i


ii 01/04/11 Vermont Systems, Inc.

WebSpeed Firewall Architecture ...................................................................................................... 24 Setting the Firewall Rules for a WebSpeed Application ................................................................... 26

ADDING AND TESTING YOUR WEBSPEED SPECIFIC RULES .................................................................................... 27

SPECIFIC CUSTOMER REQUIREMENTS FOR A WEB SERVER HOSTED BY VSI .................................. 30

© 2010 by Vermont Systems, Inc.

This document is the property of Vermont Systems, Inc. and is provided in conjunction with software by means of a licensed contract agreement between the customer and VSI. The document(s) and software referred to in this publication may not be copied, distributed, electronically transmitted, posted on the web or altered in any way without the express written consent of Vermont Systems, Incorporated. The information contained in this document is subject to change without notice.

Vermont Systems, Inc.

12 Market Place

Essex Junction, VT 05452

www.vermontsystems.com

Introduction Vermont Systems, Inc. is a privately owned Vermont corporation with headquarters located at 12 Market Place, Essex Junction, Vermont. The company was founded on July 1, 1985 by Bob Willey and son, Giles Willey, and since 1988, has specialized in developing fresh software products for managing recreation and parks operations VSI markets and supports this software on a worldwide basis.

The primary application software products are RecTrac, GolfTrac, CYMTrac, MainTrac, FinTrac, WebTrac and PayTrac, each of which consists of multiple integrated software modules for managing recreation and parks operations.

All VSI application software is developed using 4GL Progress OpenEdge software, which enables it to operate on many hardware platforms utilizing multiple operating systems, such as Windows, Linux, and UNIX. The Progress RDBMS (database) is imbedded with our applications.

Current Application Software Products The RecTrac recreation tracking software is the primary VSI application software product with over 1000 installations, mostly in the U.S. The total number of GolfTrac users now exceeds 235. Our MainTrac software is becoming a major product for VSI with over 60 installations. The FinTrac financial software user list now includes over 40 customers. Currently, over 400 customers have installed the WebTrac software with excellent results, and more are implementing the system monthly. The WebTrac browser user interface enables your customers to the use the RecTrac, GolfTrac, CYMS, and MainTrac software through the Internet.

RecTrac 10.3 has been developed using the Progress OpenEdge Development software and deployed using Progress OpenEdge Deployment software that includes Client Networking; Web Client; Query and Results; Load Balancer; Personal, Workgroup, and Enterprise RDBMS (embedded database) with RDBMS support for 4GL, SQL, ODBC, JDBC, and Enterprise Cluster Manager Integration; and, OpenEdge Application Server, Basic and Enterprise Editions with Replication.

Although the applications can operate single user, most customers operate client/server with OpenEdge-certified operating systems, such as Windows XP Pro, and Vista Pro clients, along with Windows 2003, Windows Server 2008 R2 (Progress 10.1C and above), Windows 7 (Progress 10.1C and above), UNIX, and Linux servers.

Vermont Systems, Inc. 01/04/11 1


WebTrac Integrated Web Software VSI has designed and developed WebTrac real-time Internet software utilizing the Progress OpenEdge Version10 development environments. WebSpeed and OpenEdge enable VSI to develop Web-enabled, next-generation applications purposely for deployment on the Internet. As previously mentioned, this requires changes to the existing applications, since the logic and the user interface are separated. Further, technology shifts in design, development, and deployment are required.

WebTrac 10.3 allows our customers to offer their patrons real-time capability to:

• self-register into classes/programs,

• register and renew pass memberships,

• reserve courts, facilities, golf tee times and personal trainer times,

• reserve sites or rental items graphically

• reserve locker rentals

• register for trips via the Web,

• purchase tickets,

• purchase venue graphical seating tickets,

• query the program listings,

• view league schedules and standings, update league scores,

• view/update their household and family member data,

• change their PIN, and

• other inquiries.

• After they reserve and/or register for items, they may pay by credit card or e-check.

• WebTrac gathers statistics including site-usage, demographics and registration/referral codes for enrollments.

WebTrac is gradually being integrated with the MainTrac software to enable department employees and the public to initiate work requests inquire and print work requests. The staff will be able to log work orders, enter inspection data, and schedule jobs.

WebTrac Features Typically, new patrons will register with the recreation department in person, or via mail, telephone, email, or fax, in order to enter Household/Family Member data into the RecTrac database and obtain a User ID and Password to allow access to the system for online registrations and other functions. Some organizations might allow new participants to enter this data using the WebTrac software, as a pre-requisite to the on-line registration process, while others might require that they provide this data in advance of the registration process.

Participants can query the on-line brochure, enroll in classes/activities and pay for their registrations by credit card or electronic checks.

Each organization has the option to allow customers to update their household and family member data online. Additionally, you have the option to require a full payment or a partial payment based on a minimum percent. If partial payments are allowed, an organization can require full payment within a specified number of days, in order to avoid an automatic cancellation. If partial payments are allowed, any

2 01/04/11 Vermont Systems, Inc.

Planning Guide WebTrac 10.3

accounts receivable payments can use standard RecTrac payment types in person, or pay by credit card or e-check online.

WebTrac Deployment Purchase WebTrac and Progress OpenEdge WebSpeed Software - The VSI WebTrac deployment requires purchasing the software licenses and annual maintenance support by application, along with the installation and training services. VSI also offers installment purchase payment plans.

WebSpeed & OpenEdge Environment

WebSpeed Architecture

The WebSpeed environment is similar to the OpenEdge AppServer™ environment. A transaction server, which consists of brokers and agents, execute requests from a client. The unique piece of the WebSpeed environment, the WebSpeed Messenger, is a process that runs on your Web server capturing and redirecting client requests. Figure 1–1 illustrates the complete architecture for a WebSpeed deployment environment.

FIGURE 1-1: WEBSPEED DEPLOYMENT ARCHITECTURE



The dashed arrows in Figure 1–1 indicate connections that do not occur in all WebSpeed configurations. The WebSpeed agents might not have direct access to a database or a dataserver. Depending on how you architect your application, the procedure that the agent runs in response to a Web request might call another procedure over an AppServer to process database requests.

Note: The Progress NameServer might not be used in all configurations.

WebSpeed Components

The components of the WebSpeed environment are the WebSpeed Workshop, the WebSpeed Messengers, and the WebSpeed Transaction Server. The WebSpeed environment can also include a NameServer, which can support both AppServer and WebSpeed transactions. A default WebSpeed installation provides one predefined WebSpeed broker and one predefined NameServer. You can use these predefined components as templates from which you create and configure additional instances of the WebSpeed broker and, if needed, the NameServer.

WebSpeed Workshop

The WebSpeed WorkShop contains the tools that you use to develop and test WebSpeed applications. The default WebSpeed Workshop installation also includes a version of the WebSpeed Transaction Server scaled to support a single developer’s activities. The Workshop includes the following:

• AppBuilder — The AppBuilder is a multi-purpose application development environment that supports a broad, integrated range of application and development options. You can use it as a visual programming environment to create character- or GUI-based client/server applications. In addition, you can use the AppBuilder for WebSpeed to create HTML-based Web applications. The AppBuilder only runs in Windows platforms. You can configure it to work with a WebSpeed Transaction Server installed on a separate UNIX machine.

• WebTools — You use the browser-based WebTools to access information on your server, such as the status of CGI Variables. You can also access database information, use the WebSpeed File tools, and access virtual system table data. You can use the Scripting Lab to write and test WebSpeed code, such as HTML that includes Embedded SpeedScript, and send operating system commands. With the Editor WebTool, you can create, open, save, and print files; check syntax; and compile code.

• PRO*Tools — PRO*Tools is a set of utility programs that are useful for developing and running OpenEdge applications. For example, one of the PRO*Tools allows you to edit your PROPATH. The Color Changer, Screen Scaling Utility, and ProtoGen PRO*Tools do not apply to WebSpeed.

WebSpeed Transaction Server

The WebSpeed Transaction Server consists of the processes that handle the server-side activity of your WebSpeed applications:

• WebSpeed agent — An application process that can execute Web objects, perform database transactions, and dynamically merge data into HTML format. The agent is the standard character ABL client running in batch mode. An AppServer agent is a single AVM instance running on the AppServer.

Note: The agent process is inherently stateless. This means that the agent is only busy when a request is being processed. It will be idle at all other times.

• WebSpeed broker — An application that can do the following:

o Register with a NameServer the application services that it provides to fulfill requests from HTML clients. For information on running WebSpeed from a client other than the HTML client (for



example, an ActiveX page or a Java application), see the PSDN WebSpeed library at http://www.psdn.com/library/index.jspa.

o Manage connections between clients and a pool of WebSpeed Agents.

o Maintain the status of each agent in its pool and dynamically scale the number of agents according to changing demand.

Note: If you start a WebSpeed broker without specifying a username, the Broker inherits the account that the AdminServer is using. This is generally the system account, which might not have access to network drives.

WebSpeed Messenger

The WebSpeed Messenger listens for WebSpeed requests coming in to the Web server. The Messenger asks the NameServer where to send each request. Alternately, the Messenger can bypass the NameServer as described in the “NameServer” section on page 1–4. The Messenger then handles the transfer of data between the Web server and the WebSpeed Agent. There are Messengers for use on different Web servers: a CGI Messenger, an ISAPI Messenger, and an NSAPI Messenger.

There is also a Messenger that works with Microsoft’s Active Server Pages, the WSASP Messenger. Using the WSASP Messenger, you can call out of an Active Server Page to a WebSpeed application.

The WebSpeed Messenger always resides on the same machine with your Web server. Because the Messenger is not itself an OpenEdge application, it is sometimes the only part of the WebSpeed environment installed on a Web server machine. This is sometimes incorrectly described as a “Messenger-only deployment.” Your WebSpeed applications cannot run without a WebSpeed Transaction Server. “Messenger-only installation” is a more appropriate term for this setup.

NameServer

The NameServer is a basic part of the OpenEdge architecture. It maintains a list of available AppServers and WebSpeed Transaction Servers. Those servers register the application services that they provide with the NameServer. The NameServer can then direct client connection requests to a broker that supports a requested application service. This provides scalability and location transparency to your applications.

The NameServer can also provide load balancing and fault tolerance for OpenEdge server applications. Load balancing allows you to balance client workload among multiple brokers that support the same application service (that is, the same set of procedures and resources). This ability makes the NameServer very useful in deployed applications that handle large volumes of requests. The NameServer works through the UDP network protocol.

Language support

The WebSpeed development environment also includes a programming language, SpeedScript, and a number of pre-coded conveniences, such as global variables, preprocessors, and APIs, to simplify your development.

Source: OpenEdge Getting Started: WebSpeed Essentials

Minimum System Requirements WebSpeed & OpenEdge Transaction Server

VSI develops its application software using the Progress OpenEdge Development software and deploys using Progress OpenEdge Deployment software that includes Client Networking; Web Client; Query/Results; Load Balancer; Personal, Workgroup, & Enterprise RDBMS (embedded database) with



RDBMS support for 4GL, SQL, ODBC, JDBC, & Enterprise Cluster Manager Integration; and, OpenEdge Application Server, Basic and Enterprise Editions, Replication.

Contact Vermont Systems Customer Support for a copy of the Certified Operating Systems document or download a copy from the Vermont Systems web page www.vermontsystems.com.

Note: While the OpenEdge 10 Platform & Product Availability Guide provides the most recent platform certifications for Progress products, Vermont System’s products may NOT share the same platform certifications. Please contact Vermont Systems, Inc. if you should have any questions about your specific platform.

Minimum Hardware Requirements WebSpeed & OpenEdge Transaction Server

Progress WebSpeed Transaction Server – if you are planning to install the VSI WebTrac software, the minimum recommended server configuration is a Intel Dual-Core 1.6GHz or Xeon 3040 Quad Core or greater (or equivalent), 256MB memory for the OS plus 250MB per Agent (25 Agents X 250=6.25GB) for a minimum of 6.25GB of memory to start and 1GB free disk space. VSI currently supports Windows 2003/2008 for the WebSpeed Transaction Server. Please refer to VSI WebTrac Installation Planning Guide for more details. In our testing, each WebSpeed agent consumes upwards of 250 MB memory after a couple days worth of processing, so if you start 25 agents for a heavy registration you would need 25 agents x 250MB/agent = 6.25 GB memory. Please spec your transaction server for peak demand, NOT for everyday demand. This means that much of the time there will be idle resources.

Web Server – Since each active browser accessing the web server uses up to 2MB memory of which 700KB is required for the WebSpeed Messenger, please ensure that you have sufficient memory available to accommodate the maximum number of expected concurrent browser requests. Please discuss your web server configuration with VSI to ensure that it will not become overloaded.

WebSpeed Request Round-Trip Before you begin architecting a WebSpeed application, you should learn how information passes between the components when they process a request. How information passes between the components impacts such considerations as which components are installed together, how you manage session context, and how you apply security.

Before the first request Before the first Web request is processed, the components have to start and pass some basic information. In general, this process runs as follows:

1 Start an AdminServer.

2 Start a database in multi-user mode with properties supplied by the AdminServer from the conmgr.properties file.

3 Start a NameServer with properties supplied by the AdminServer from the ubroker.properties file.

4 Start a WebSpeed broker with properties supplied by the AdminServer from the ubroker.properties file.

5 The broker spawns its WebSpeed agents using the information it received from the AdminServer.

6 The broker registers itself and the application services that it provides with the NameServer. By default, the broker sends a message every 30 seconds to notify the NameServer that it is still available to accept requests. If the NameServer does not get a message, it deletes the broker from its “available” list. These messages are not part of the request process.

7 Start a Web server, which makes its WebSpeed Messenger available to transfer Web requests.


http://www.vermontsystems.com/


FIGURE 1-2: HOW WEBSPEED PROCESSES A WEB REQUEST

The numbered steps of a Web request in Figure 1–2 are explained in the following sequence:

1 The HTML client, running in a Web browser, generates a connection request. The request is in the form of a URL and is sent to a Web server, which forwards it to a WebSpeed Messenger.

2 Messenger sends a request to the NameServer for an available WebSpeed broker that supports the required application service.

Note: In a “No NameServer” configuration, the Messenger is hard-wired with connection information for a single WebSpeed broker. The Messenger passes all Web requests directly to that broker.

3 The NameServer selects a broker, which supports the requested application service, from the pool of brokers that have registered with it. The NameServer sends the broker’s host name or IP address and the broker’s port number to the Messenger.

4 Using these details, the Messenger connects to the broker and requests a WebSpeed agent to process the request. This request is put in a queue by the broker, so requests are not lost in peak load times.

5 If there are requests in the queue, the broker checks for an available agent in its pool. The broker allocates the next available agent to the request and marks that agent as busy. The broker then returns that agent’s port number to the Messenger.

Note: If there are no free agents and the broker’s maximum number of agents has not been reached, the broker starts a new agent to process the request.

6 The Messenger connects to the agent through that port and passes the Web request to the agent.



7 The agent executes the Web request and creates an HTML page that it returns to the Messenger.

8 The agent informs the broker that it is available again.

9 The Messenger passes the HTML page to the Web server, which passes it back to the HTML client.

Step 2 through Step 5 create only small amounts of network traffic, usually less than 500 bytes. The large amounts of data are in the final request and response, Step 6 and Step 7. The data sent from the Messenger to the WebSpeed agent includes all of the environment variables, as well as the input parameters from the URL or HTML form. The environment variables alone can be up to 3000 bytes. When the response comes back from a WebSpeed agent, it could be a simple HTML page of around 1000 bytes, but it also could be a large.ZIP file or similar. With special programming, WebSpeed can send binary files to the Web browser.

All of these components (the Web server, the WebSpeed Messenger, the WebSpeed broker, the WebSpeed agents, and the NameServer) can reside on a single physical machine. However, you can also distribute them on separate machines, with the following restrictions:

• The Web server and the WebSpeed Messenger must reside on the same physical machine.

• The NameServer can reside on any machine, but requires an AdminServer.

• The WebSpeed Transaction Server (the WebSpeed broker and the WebSpeed agents) requires an AdminServer on its machine. The broker and the agents that it supports must reside on the same physical machine. You can have multiple WebSpeed Transaction Servers spread over several machines, but registered with a single NameServer.



Supported WebTrac Configurations The following diagram illustrates the various components of the supported WebTrac configurations (using at minimum one firewall), followed by the 3 options themselves.

WebTrac

WebTransaction Server Ports 3202-3502

InternetConnectionPort 80 (tcp)

or Port 443 (SSL)

`

WebTracUser

Loaded with firewall

software

Secure Zone

Transaction Server *

Notes: Please note that configurations can be quite flexible. This is purely an example.

C – The Transaction Server can also be the machine where both the Name Server (Port 2532 UDP) and AppServer(s) reside and operate.

D – The RecTrac Database Server will also have an instance of Tomcat which is responsible for running the AIA applet (Appserver Internet Adapter) which runs RecTrac within a LAN

A

RecTracDatabase

Server

B

C

Email Server

SMTP or

MAPI

environment using WebClient technology.

Port 2500 (tcp)

Ports 3000-5000

(tcp) Dynamic

Currently Certified

Credit Card Authorization Processors

Port 25 (tcp)

Email via Internet

Firewall Zone (un-secure)

D

Credit Card via Internet

(Ex. Port 443)

E

DMZ

Transaction Server Components *

WebServerComponents *

IIS/CGI/MSG

WebServer *Dynamic Ports

can be narrowed to the number needed for AppServer

and Web Agents

Webspeed

Note: Our experience to date indicates that Option II provides the fastest throughput and is the most cost-effective method. If you select to use Option II, your hardware configuration (memory, CPU speed, etc.) should meet or exceed the minimum hardware requirements specified by Vermont Systems.

** Most common configuration

Option Description Pros Cons

I * B, C, D all on one box; E on a second box

Least expensive since sharing one box

Not secure since all components are in the Firewall Zone. Could be slowest since resources of one box being taxed by all components.

II ** B on one box, C& D on a second box; E on a third box

Most secure; speed dependent on how robust the three boxes, can be fastest

III B, C, D, E each on separate boxes

Most secure; can be the fastest since each box only taxed by its components

Most expensive since each component is allocated its own box



Notes: All three options assume that the Bastion Host (A) will be a separate PC loaded with the firewall software.

Where (D) is designated in the above three options, it represents both the Progress database servers and the credit card authorization software (which can be all on one machine or multiple machines throughout your network).

Customers have the option of making their web server (B) a “secure” web server.

Options II and III are the recommended configurations for open-to-the-internet usage. Your web server should be in the DMZ and a firewall installed between the web server and the data/trans server.

Important Notes!: VSI strongly recommends that Option I be used only in a testing or intranet environment. If you elect to use Option 1 in a production environment, you will be required to sign a waiver that indicates you realize that this option is not supported by Vermont Systems for security reasons. If the web server is not hosted onsite then a VPN must connect it to the data/trans server.



Progress WebSpeed Supported Web Servers & Browsers

Supported Web servers

For WebSpeed application development, you can use any Web server that supports one of the following interfaces:

• CGI 1.1 — For example, Microsoft Internet Information Server (IIS), Apache, Netscape Enterprise, or Fast Track Server.

• ISAPI — For example, Microsoft Internet Information Server (IIS).

• NSAPI — For example, Netscape Enterprise or Fast Track Server.

Supported Web browsers and preference settings

The WebSpeed development environment requires Netscape Navigator (Version 4.5 or later) or Microsoft Internet Explorer (Version 6.0 or later).

Table 2–2 lists the recommended Web browser settings for the WebSpeed Workshop environment.

Table 2-2: Browser preferences and settings

Additional Notes:

You only need the browser to support the features used in the HTML pages generated from the VSI application. To handle all WebTrac features (both early and mature releases), we require:

• ActiveX (payment processor specific).

• WebTrac does not require frames support

• JavaScript must be enabled.

• WebTrac uses cookies



Installation Planning

Installing a Deployment Environment A deployed WebSpeed environment typically consists of the WebSpeed Transaction Server or the WebSpeed Enterprise Transaction Server and the application code. VSI’s application code includes static HTML files as well as compiled Web objects created with WebSpeed tools.

These are the general steps for installing WebSpeed in a testing or deployment environment:

1 Install the WebSpeed Messenger on the machine where your Web server resides.

2 Install the Transaction Server or the Enterprise Transaction Server on the machines where you want WebSpeed Brokers to run.

3 Configure the WebSpeed components on each machine (the web server and the Transaction server).

4 Place the Web objects in the WebSpeed default or working directory on the machine where you installed the Transaction Server.

5 Place the static HTML, graphics, and Java class files required by the VSI application on your Web server machine and make sure that the document root directory of the Web server serving your WebSpeed application is configured to point to their location.

6 Place VSI’s application code and Web objects on the Transaction Server machine.

7 Install and configure RecTrac database engine.

8 Install and configure credit card authorization software.

Understanding Your Web Server The Web server is the backbone of any Web application. The WebSpeed Transaction Server is the engine that drives your Web applications, but it relies on the Web server to receive and pass on requests that users send across the Internet through their browsers. The WebSpeed Messenger resides on your Web server, ready to react to incoming requests for data that a WebSpeed application can fill.

Successfully installing and configuring WebSpeed does not require a Webmaster’s knowledge. However, you must know enough about your Web server so that you can identify it for all WebSpeed components. Likewise, the Web server must be able to find the files that Transaction Server needs so that it can serve the HTML pages to developers’ browsers or, in a deployment environment, find the HTML files that the WebSpeed application needs.

The following table summarizes the information that you must have about your Web server before you can start installing and configuring WebSpeed.

Information Comment

Type of Web Server

You must know whether your Web server is ISAPI-, NSAPI-, or CGI-compatible. These labels refer to the published interface standard that a Web server uses. For example, Microsoft Internet Information Services uses ISAPI; Netscape Enterprise or Fast Track Server uses NSAPI; Apache and O’Reilly use CGI. Although you can use the Messenger for CGI with an ISAPI or NSAPI type Web server, use the Messenger for ISAPI or NSAPI for optimal performance.



Information Comment

Host Name

You must know the name by which your network recognizes the Web server machine. Optionally, you can use the Web server’s domain name, that is, the name by which the Internet recognizes it. Another option is to simply use the IP address of the web server machine.

Document Root Directory

The Web server must be able to locate the static files that Transaction Server or any WebSpeed application requires. To ensure that the Web server can locate the files, you can physically place the files in the Web server’s document root directory or you can configure the Web server so that its document root directory points to the actual location of the files.

Scripts Directory

You must know which directory your Web server expects to find the executables and scripts that it uses to process incoming Web requests. The WebSpeed Messenger executable must reside in this directory (except for the NSAPI Messenger, which resides in install-path/Program Files/WEBSPEED/bin). On some Web servers this directory is a virtual directory that you specify when you configure the Web server.

Starting and Stopping

You must know how to start and stop your Web server. After installing the Messenger, you must restart the ISAPI or NSAPI Web server. For Netscape Web servers, you must also apply the configuration changes you make. You do not have to restart a CGI Web server.

Source: Progress Software Corp.

In preparation for the implementation of WebTrac, we have identified the responsibilities of VSI, as well as those of the RecTrac User (Customer).

Bandwidth Between Web Server and Transaction Server The primary WebTrac installation issue is usually performance (response time), and it often appears, when the web server is not on the same intranet as the transaction server and data server. The following factors can decrease response time:

• Firewalls • Bandwidth • Latency

The rule of thumb with regards to bandwidth between the ISP web server and the transaction server is to equal the bandwidth coming into the web server. For example., if a T1 has been dedicated to incoming browser clients to the web server, then this same bandwidth should be dedicated to the communication between the web server and the transaction server. Even though you may have sufficient bandwidth, you can still experience slow response times because of the latency factor. Ideally, a latency of 10ms or less is desirable.



Internet Connection Bandwidth Comparison Chart

Carrier Technology

Speed Physical Medium

Advantages Considerations

ISDN 64 Kbps to 128 Kbps

Twisted Pair 1. Uses existing local loop/twisted pair cabling

2. 5 times faster than dial-up.

3. ISDN speed is dependant on whether you are using a single channel or dual channel. Single channel will give you speeds up to 64 Kbps. Dual channel ISDN gives you speeds up to 128 Kbps

1. ISDN is considered old technology. There is competition from the newer technologies

2. ISDN is not available in all areas

3. Requires special equipment.

Cable 512 Kbps to 20 Mbps

Coaxial cable: in some cases telephone lines used for upstream requests.

1. Wide Availability

2. 100x faster than a 28.8K modem.

1. Slow download speed during high usage service times – shared connection.

2. Shared bandwidth – speed slowdowns – users privacy concerns.

3. Upload and download speeds may vary.

4. Not intended to support commercial applications or large numbers of users as T1 connections.



Speed Advantages Considerations Carrier Physical Technology Medium

ADSL/DSL 128 Kbps to 8 Mbps

Twisted pair (used as a digital, broadband medium)

1. Dedicated connection, not shared as with cable.

2. Less expensive than cable.

1. Limited availability

2. Only as reliable as your phone line.

3. Upload and download speeds may vary.

4. Not intended to support commercial applications or large numbers of users as T1 connections.

Frame Relay 56 Kbps to 1.544Mbps (or more depending on connection type)

Various 1. Creating long haul, high speed connections may be cheaper than dedicated lines.

1. Potential for jams – no guaranteed bandwidth.

Fractional T1 64 Kbps to 1.544 Mbps

Twisted pair or coaxial cable

1.Upload and download speed are the same.

2. Cheaper than a full T1 Line with the option to grow into a full T1 line.

1.Less throughput than a full T1 that doesn't outweigh the cost savings.

T1 1.544 Mbps Twisted pair or coaxial cable, or optical fiber.

1. Upload and download speed are the same.

2. Used for high bandwidth demands.

1. Can be expensive



Latency versus Bandwidth…What is it?

GreenNet is an Internet Service Provider. The following article appears in the FAQ section on their web site. The link to the article is http://services.greennet.net/FAQs-T1.htm

One of the most commonly misunderstood concepts in networking is speed and capacity. Most people believe that capacity and speed are the same thing. For example, it's common to hear "How fast is your connection", invariably, the answer will be "640K, 1.5M" or something similar. These answers are actually referring to the bandwidth or capacity of the service, not speed.

Speed (latency) and capacity (bandwidth) are two very separate things. The combination of latency and bandwidth give users the perception of how quickly a webpage loads or a file is transferred. It doesn't help that broadband providers keep referring to "get high speed access" when they probably should be saying "get high capacity access". Notice the term "Broadband", it refers to how wide the pipe is, not how fast.

The most common example to compare latency and bandwidth is: Imagine water running through a pipe. The pressure is latency, the width of the pipe is bandwidth. If you have a wide pipe but low pressure, you can move more water through the pipe but at a slower rate. If you have a narrow pipe but high pressure, you can move less water but at a faster rate.

Another example that is sometimes given: Imagine people in an aircraft. In this example, people are the data packets, the size of the aircraft is the bandwidth, and the speed of the aircraft is the latency. A 747 can carry about 400 people but a 707 can carry only 200 people. Both fly at about 500 knots. If both leave New York at the same time, they will arrive in Los Angeles at the same time. Notice that although, the 747 has more capacity (or bandwidth) it is the same speed (latency) as the 707.

Latency is normally expressed in milliseconds. One of the most common methods to measure it is use the utility ping. A small packet of data, typically 32 bytes, is sent to a host and the time is measured. Normally, the RTT (round-trip time it takes for the packet to leave the source host, travel to the destination host and return back to the source host) is measured.

Bandwidth is normally expressed in bits per second. It's the amount of data that can be transferred during a second. Solving bandwidth is easier than solving latency. To solve bandwidth, more pipes are added. For example, in early analog modems it was possible to increase bandwidth by bonding two or more modems. In fact, ISDN achieves 128K of bandwidth by bonding two 64K channels using a data link protocol called multilink-ppp.

The following are typical latencies, to the first hop, by popular circuit types . Please remember however that latency on the Internet is also effected by routing (number of hops) that an ISP may perform (i.e., if your data packet has to travel farther, latencies increase).

Ethernet: 0.3ms Analog Modem: 100-200ms ISDN: 15-30ms DSL/Cable: 10-20ms Satellite: >100ms DS1/T1 ; 2-5ms

Bandwidth and latency are connected. If the bandwidth is saturated then congestion occurs and latency is increased. However, if the bandwidth of a circuit is not at peak, the latency will not decrease. Bandwidth can always be increased but latency cannot be decreased. Latency is the function of the electrical characteristics of the circuit. So, no matter how un-congested the analog modem line is, the latency (speed) will not be reduced (increased).


http://services.greennet.net/FAQs-T1.htm


VSI Responsibilities 1 Development of the WebTrac software using the Progress WebSpeed development environment. This

includes the integration of WebTrac with the RecTrac software.

2 Offer the Users a payment choice with a One Time or Installment Payment Plan License with Annual Maintenance. Refer to # 3 and #4 below for the One Time and Installment License and Annual Maintenance pricing

3 Provide pricing and accept the User’s order for the Progress OpenEdge WebSpeed Transaction Server with a minimum of 25 Agents, which should be sufficient for most users. Pricing is based on the number of users/agents and annual maintenance.

4 Provide pricing and accept the User’s order for the VSI WebTrac software license and maintenance. Pricing is based on the number of users/agents and annual maintenance.

5 Install Progress WebSpeed on the customer’s qualified Web Server and Transaction Server, either at VSI or Customer site.

6 Install VSI WebTrac software on customer database server, either at VSI or Customer site.

7 Customize the WebTrac Home Page to match Customer’s web site look. This styling customization does not include functional changes, but rather cosmetic appearance adjustments, such as logo, background color, and fonts by way of a custom Cascading Style Sheet (.CSS file). Also design the customer’s Splash pages.

8 Train Customer staff to use and manage the WebTrac and WebSpeed software.

9 Provide pricing and accept order for credit/debit card authorization software via External Redirect Interface (ERI) with:

• Plug’n Pay - external redirect IP interface gateway certified for multiple processors to process office client and online credit card payments.

• ETS - external redirect IP interface to process office client credit card and pinpad debit card payments, as well as online credit card payments.

• CyberSource - external redirect IP interface gateway to process online credit card payments, as well as optional IDI interface to process office client credit card payments.

• TouchNet (T-Link), external redirect IP interface gateway, to process online credit card payments.

• Govolution, external redirect IP interface gateway, to process online credit card payments.

• Systems East, external redirect IP interface gateway, to process online credit card payments.

Note: The above list is subject to change as new options become available or as PCI Compliance standards change. Note that existing VSI customers currently using an Internal Direct Interfacing (IDI) to process credit cards must switch to one of ERI options above prior to 7/1/2010. Contact VSI Sales at 877-883-8757 for more information.

The following information relating to Payment Card Industry Data Security Standards has been copied from a VSI document that summarizes the requirements. Please read the complete document for more details.

Prior to the release of VSI’s external redirect card processing concept, all credit card, debit card, gift card, and electronic check interfaces communicated directly with the processor through an internal interface, whereby the credit card data is captured within the application software. To reduce the extensive processing requirements (PCI-DSS) to be levied on merchants (our customers), VSI decided to switch to an external redirect interface (ERI) despite the extra cost and development time for VSI. By choosing this route you, as Merchants, would not be subject to the 200 plus setup and training requirements associated with our Payment Application Best Practices (PABP) certificate. The three principal requirements that would force a PABP audit are entry, transmission, or storage of card



data. The External Redirect Interface (ERI) eliminates the VSI RecTrac, GolfTrac, WebTrac & PayTrac software applications from PABP requirements, since no card data is entered, transmitted, or stored within a VSI application. This External Redirect concept appropriately transfers the PABP requirements to the processor. In addition, this new approach will allow VSI to focus on improving our recreation applications rather than focusing on card processing functions, thus minimizing the resources required to become PCI-DSS compliant. (As of 2008, PABP is now known as PA-DSS (Payment Application Data Security Standard).

According to the PCIDDS schedule, effective July 1, 2008 new merchant accounts cannot be issued to a merchant that is not using PA-DSS accredited software (or at least queued to have a PA-DSS audit). The two VSI prototype ERI’s that have been developed for release in RecTrac version 10.1k are both PA-DSS certified. Existing customers (merchants) will have until July 1, 2010 to convert from their current VSI internal direct interface to one of the VSI ERI options, and in most cases, will be able to continue with their current processors. Additional ERI interfaces will be developed, as needed, as we evaluate each request to determine its viability. Please note that each merchant (VSI customer) will be subject to PCI-DSS requirements and must perform an annual self-assessment accreditation based on their merchant classification. To determine your Payment Card Industry (PCI) category and the resulting assessment form, you can visit www.pcisecuritystandards.org.

A detailed description of the PCI DSS compliance validation procedures for Merchants, Service Providers, and Payment Applications vendors, including the latest PCI Data Security Standard (1.2, released 01 Oct 2008) can be found at https://www.pcisecuritystandards.org/.

Customer (User) Responsibilities 1 License and install Web Browser software for in-house testing.

2 Install a properly configured in-house Web Server computer with Firewall Protection (for example: http://www.yourdomain.org) or order a hosted web service from a third party vendor.

3 Some organizations purchase a Secure Socket Layer (SSL) Web Server encryption certificate, in addition to the built-in security provided by the selected ERI. Some sources include THAWTE (http://www.thawte.com), VeriSign (http://www.verisign.com) and GeoTrust (http://www.geotrust.com).

Install the SSL Web Server certificate on the Web Server with Firewall Protection where any or all WebTrac pages may reside (for example: https://www.yourdomain.org).

4 License and install Web server software, such as Microsoft IIS or Apache. VSI will verify connection prior to our on-site visit. If web server is non-Intel/NT, install Progress-certified level of JDK with VSI assistance and documentation.

5 License the Progress WebSpeed Transaction Server software with 25 Agents and participate with VSI Trainer to install it.

6 License the VSI WebTrac software. Participate with the VSI Trainer to install and configure.

7 Arrange with a VSI certified processor to process credit/debit card payments via the Internet. If you are currently processing RecTrac and GolfTrac credit card payments using Plug n’Pay or ETS, you will be able to use the same option for WebTrac. If you are not currently processing RecTrac and GolfTrac credit card payments, but do plan to offer this capability with WebTrac, then you can also select any one of the online only processors. Discuss with VSI.

Important Note for Existing RecTrac Users Considering the Purchase of WebTrac:

If you plan to use a credit card processor to process WebTrac transaction payments, you need only to license the appropriate ERI Interface from VSI. VSI provides installation instructions and telephone support to assist you to configure the VSI software for each interface, while each processor coordinates the implementation. Thus, the set up is quite easy.


http://www.pcisecuritystandards.org/

https://www.pcisecuritystandards.org/

http://www.yourdomain.org/

http://www.geotrust.com/


In selecting a processor, please ensure that the processor offers all of the features that you wish to utilize, such as GUI and/or online IP credit card/non-pinpad debit card, GUI pinpad debit card, or online IP credit card only (ecommerce). Discuss other needed capabilities with VSI or review the VSI Features document that lists capabilities offered by vendor.

If you use the same processor for RecTrac and WebTrac, you will need one or more merchants (toggled to non-E-Commerce) for RecTrac and a separate merchant for WebTrac E-Commerce use.

8 Design and develop a Web Page (unless you already have one), which will have a hyperlink to the WebTrac Home Page. (VSI will provide you with the text for that link.)

9 Provide a training environment that enables both Intranet and Internet transaction processing.

10 VSI strongly suggests that you conduct thorough WebTrac Intranet and Internet staff testing and training prior to allowing the public access through the Internet.

11 The Transaction server must be able to perform an OS copy to the receipt location specified in RecTrac static parameters so receipts created by WebTrac transactions can be copied to this location.

12 Have an SMTP mail server accessible from the transaction server somewhere on the LAN. When using SMTP, relaying must be allowed from the Transaction Server IP address. This will allow the User to take advantage of some WebTrac features like email notification of forgotten passwords, receipts, and sending comments to the webmaster.

13 The Web Server, Transaction Server and Database Server should reside in-house at the customer site, unless communications performance among different server locations enables multi-site operations. We suggest discussing the configuration options with VSI.

Note: If loading the WebSpeed messenger at an ISP (i.e., the web server does not reside in house with the transaction server), the connection between the ISP and transaction server must be secure! The data between the web server and the transaction server is NOT encrypted, so a VPN must be set up. The VPN setup is the responsibility of the customer—not VSI.

IMPORTANT INSTALLATION PLANNING – prior to scheduling VSI to provide on-site WebTrac installation and training services, be sure to complete the installation of all hardware, network software, firewall, etc.

• If you do NOT modify the configuration after the Trainer has successfully completed the WebTrac software installation and departed, one trip should be sufficient.

• However, if you modify the configurations, then a second chargeable trip might be required, or chargeable telephone support must be scheduled. Standard VSI telephone support does NOT cover reinstallation issues.



Credit Card Authorization Options Current Customer Options - using a current IDI (Internal Direct Interface):

1 If the current IDI payment solution is also available as an ERI (External Redirect Interface) payment solution and the capabilities needed are not changing, then you can switch to the VSI ERI by contacting VSI to make arrangements. These can include Plug n’Pay, ETS, CyberSource, Systems East, Govolution, and TouchNet (T-Link). If you are currently using Verifone PCCharge, then we suggest switching to one of the ERI options or upgrading to Payware PC or Payware Transact. Be sure to discuss with VSI to ensure that your selection will meet your needs and to obtain a quote for software and hardware.

New Customer Options:

1 Discuss options with VSI, review ERI documents, and contact potential vendors for consideration. After reviewing vendor services, fees, and references, decide on option that best fits your operational needs at competitive prices.

For More Information

For more detailed installation information, refer to the WebTrac Installation and Configuration document.



PAGE LEFT BLANK FOR DOUBLE-SIDED PRINTING


Planning Guide WebTrac 10.3 Appendix B

Appendix A: Security and Firewalls Progress Software Corp has written several technical papers on internet security and firewall protection for WebSpeed applications. Here are some of the highlights:

General Security Issues Network security topics usually address these three security risks:

• How to keep outsiders from entering the organization and accessing sensitive data;

• How to monitor and control internal employee access to the same; and

• How to make sure unauthorized corporate data never leaves the network.

Developing a Security Policy is the first step to handling these security risks. There is usually a balance to be struck between the benefits of shared information and the risks listed above. In developing a security policy, you’ll need to perform a network security assessment from the outside-in (the external hacker’s perspective of the infrastructure), across the intranet (the internal user’s perspective of the infrastructure) and from the keyboard-out (again, an internal perspective from the actual operating systems of the internal machines).

Once you’ve assessed your risk, you’ll need to determine an appropriate firewall technology, set it up and test to see that it is performing well. Remember that traffic that can circumvent a firewall (by modem or an internal access point) can have free reign if no other internal controls are in place.

Authentication Authentication procedures validate the authenticity of any user or client machine. There are several authentication mechanisms including:

• Transparent User Authentication, which is a one step connection request to a final destination rather than through a firewall gateway. This method is only supported by applications that have integrated authentication (such as http, ftp and telnet).

• Non-Transparent User Authentication where the user requests a connection to a firewall and the firewall communicates to the final destination. This method is only supported by applications that have integrated authentication (such as http, ftp and telnet).

• Client Authentication, which is a semi-transparent method where the client requests a connection to a firewall and once granted, the client communicates directly to the final destination. It does not require any additional software on the client machine, but it is not as secure and the two above methods.

Encryption Encryption is the transformation of data into some unreadable form. In order to ensure privacy, some of the tools used for this purpose are:

• Private and Public Keys

• Digital Signatures

• Digital Certificates

• VPN - Virtual Private Network (also known as Encrypted Tunnel)

• Secure Socket Layers (SSL)

Most e-commerce web sites forego the client-side requirements and use SSL to pass credit card information between the browser and web server, which then decrypts it and passes it to the server-side payment software.


Planning Guide WebTrac 10.3 Appendix A


Firewalls A well-setup firewall acts as a perimeter defense of your corporate/organization’s network. Some firewall technologies include:

• Packet Filters (usually implemented on routers) filter user-defined packets of information such as IP addresses. They are not the most effective if used alone, since they cannot understand the context of what they are filtering.

• Proxies/Application Layer Gateways bring context information into the filtering process. They require two connections, one from the client to the firewall and another from the firewall to the server. Some proxy -based firewalls provide generic proxies to support services that don’t have customized proxy support.

• Stateful Inspection does not require two connections between the client/server like the Proxy-based firewall does. Instead it intercepts packets and inspects them via an inspect engine for future examination.

Technology Pros Cons Packet Filters Application

independence Good performance Good scalability

Poor security No screening above network layer (no state or application-context information)

Proxies/Application Layer Gateways

Good security Full application-layer awareness

May provide poor performance Limited application support Poor scalability

Stateful Inspection Good security Good performance Extensibility Good scalability Transparency

Operating systems are not hardened Limited content understanding


WebTrac 10.3 Planning Guide Appendix B

One Firewall or Two?

One Firewall Two Firewalls

Pro: Provides for more accurate and centralized management of firewall resources, logging, and reporting.

Pro: Lower implementation cost due to less software, less hardware, and less time to implement.

Pro: Ability to create additional firewall segments (e.g., create another segment to locate the databases behind the firewall).

Con: Rules may be more complex or lengthy, depending on vendor-specific products.

Con: If firewall is shut down, access to the development environment is lost.

Pro: Simpler rules; each firewall only needs rules to address one access point into the network environment.

Pro: If one of the firewalls is shut down, access to the environment is available via the other firewall.

Con: Does not provide accurate and centralized management of firewall resources, logging, and reporting. There are some products that claim central management but often each firewall has to be addressed individually.

Con: More costly to implement.

Con: Can not create additional fire walled segments without the use of additional firewalls.


WebSpeed Firewall Architecture

The recommended WebSpeed firewall architecture is a variation of the screened subnet architecture. The architecture designed is also sometimes called a three-legged architecture in that it has three main networks to deal with: the outside network (least secure), the inside network (most secure), and the DMZ (medium security).

The best solution when building a firewall is seldom a single technique. It is usually a combination of techniques implemented to solve the user requirements at a particular site. When designing architecture for protecting your WebSpeed applications, you might have to make compromises to suit the needs of your particular users.

Recognizing this fact, we have developed a recommended architecture that is as robust as possible, but that still provides the best firewall security strategy. This robustness is built into the architecture through the use of network switches/hubs and network routers placed at various locations. Adding network switches/hubs will allow you to reconfigure your firewall system as the need arises and limits the number of changes that will be required when this time comes. For example, site security policies might require you to add another machine to the DMZ network. If you have a network switch/hub in place on your DMZ network, you can simply add the other machine to the switch/hub and no other rewiring or configuration is necessary. Adding network routers adds additional security measures as well. This is primarily because most of them come with software that allows you to add access rules and to notify a system administrator about potential attacks. This architecture also gives you a depth to your firewall; that is, it has several points where security checks can be done so that a single failure won’t leave you wide open to hackers.

This architecture also should be implemented with diversity of defenses in mind. It is not only important to use a number of different systems for your firewall defense, but also to vary the vendor’s hardware and software as well. The reason for doing this is simple: if there is a bug in a particular vendor’s hardware or software that might compromise your system, having systems from different vendors reduces the risk of your whole system being open to someone who uses that bug to compromise your system. For example, use a router from one vendor on your line to the Internet (your external router), but use another router from another vendor on the line to your inside network (your internal router). If someone gains access from the outside by exploiting a router bug in your outside Internet line, they won’t be able to exploit the same bug to gain access to the inside LAN, which has a router by a different vendor.



The following diagram shows the recommended firewall configuration for WebSpeed. This configuration is outlined with all of the WebSpeed 3.X components placed in their proper locations:

Note: The IP addresses used in this diagram are not valid. They are only included as examples to make the diagram and firewall rules easier to follow.

The first thing you notice is that this is a variation on the screen subnet architecture outlined in the previous section. It still has the three main components of the screened subnet architecture: outside network, DMZ, and inside network. This architecture is superior to the typical router based screened subnet architecture because with this model, the firewall software is performing the role of both the interior router and the exterior router.

Why is this better? Well, primarily because today’s firewall software products provide much better protection than the software typically used on a standard router. In the WebSpeed Firewall Architecture (WFA), a host based PC or UNIX workstation is used to host the firewall software. This allows Web sites that cannot afford a lot of expensive hardware to implement this architecture effectively. However, if your internal network is more complicated, you might want to add the optional routers to the WFA, which is an outstanding way to add more levels of defense.

One of the most important features of the WFA is the DMZ. Its job is to provide a medium security zone from which the Web Server and the WebSpeed messengers can be accessed from the outside network. Internet users can access these portions of the WebSpeed application, but cannot proceed to access the main portion of your WebSpeed application without using these components. If someone does get into your DMZ machine, your WebSpeed application data is safe on the inside network. The firewall is configured so that only the WebSpeed messengers themselves are allowed to talk with the inside network. This DMZ area is protected by the firewall, but doesn’t expose ports used to communicate to the inside (most secure) network to the outside (least secure) world.

The remainder of the WebSpeed application resides on the inside network. In the diagram, they all reside on one host machine. The WebSpeed NameServer can be moved to another host on the inside network, but be sure it remains on the inside network. The unified broker, agents, and applications should all reside on the inside network to gain the maximum amount of protection from the firewall.




Setting the Firewall Rules for a WebSpeed Application

So far, we have talked extensively about the firewall protecting the DMZ from the outside network and the DMZ protecting the inside network. But how is this done? The answer is that a set of rules must be developed that you give to the firewall software to give your WebSpeed application this protection. Each firewall system (hardware or software) will have different ways to set up these rules. Check the manuals for the product you are using. However, the rules that you need to configure so that the WebSpeed components in the WFA can communicate with each other are listed below. The port numbers used are the defaults for the unified broker (WSRTLIVE), as defined in the WebSpeed ubroker.properties file.

In the diagram above, some example IP addresses have been added to make tracking of the rules as close to reality as possible. Each firewall product will have a different user interface for setting up rules; some graphical and some command-line. Consult the documentation that comes with your firewall product on the tools and format to use for setting up your firewall rules.

The following is a list of rules that you will need to setup with your firewall software in order to allow your WebSpeed components to talk with each other:

1 Allow outside users to have HTTP access to the Web Server on the DMZ machine. If you use the default Web Server HTTP port of 80, your rule will look something like this:

• 123.111.22.3/ 456.444.55.6/TCP/80 (using optional router)

OR

• 0.0.0.0/456.444.55.6/TCP/80 (without router)

Depending on your SSL, you may need to open port 443 for security verification.

2a Open up a two-way TCP message for the WebSpeed messengers on the DMZ to talk with the WebSpeed Live Transaction Broker on the inside network. If you use the VSI default broker port of 2533 for WSRTLIVE, your rule will look something like this:

• 456.444.55.6/789.777.88.9/TCP/2533 (using optional interior router)

OR


2b Open up a two-way TCP message for the WebSpeed messengers on the DMZ to talk with the WebSpeed Demo Transaction Broker on the inside network. If you use the VSI default broker port of 2534 for WSRTDEMO, your rule will look something like this:

• 456.444.55.6/789.777.88.9/TCP/2534 (using optional interior router)

OR


3a Open up a two-way TCP message for the Live and Demo Agents to communicate with the messengers. If you have a 25 agent license and use the VSI default port range of 2701-2751, your rule will look like this:

• 456.444.55.6/789.777.88.9/TCP/2701-2751 (using optional interior router)

OR

• 456.444.55.6/100.100.10.1/TCP/2701-2751 (without router)



The Raptor firewall product did not allow one rule to open a wide range of TCP ports from the DMZ to the inside network. It considers this a potential area for sloppiness on the part of the firewall administrator. The rules for some firewall products (like Raptor) for this step might have to be done port by port:

• 456.444.55.6/789.777.88.9/TCP/2701 (Using the optional interior router)

• 456.444.55.6/789.777.88.9/TCP/2702

• 456.444.55.6/789.777.88.9/TCP/2703

• 456.444.55.6/789.777.88.9/TCP/2704

• 456.444.55.6/789.777.88.9/TCP/2705 et cetera

OR


• 456.444.55.6/100.100.10.1/TCP/2702

• 456.444.55.6/100.100.10.1/TCP/2703

• 456.444.55.6/100.100.10.1/TCP/2704

• 456.444.55.6/100.100.10.1/TCP/2705 et cetera

4 If you have selected to place the transaction server in a DMZ, you will need to open ports between the Transaction server and the RecTrac database server. If you are using VSI standard port numbers, the ports that need to be open are 2600, 2603, and 3202 thru 3502.

There are a few other rules that are not required, but you will find useful to define in your firewall software. These rules should be added to the firewall rule database before you apply any of the WebSpeed application rules listed above.

The best way to set up your firewall is to start up the firewall software with absolutely no rules defined. You can then begin the step-by-step process of adding the rules and testing each rule as it is added. When the firewall is initially started and there are no rules defined, you shouldn’t be able access any host machine from the outside network. This means that the firewall is working.

Most firewall products require you to configure DNS. DNS is a name server that normally runs on virtually all host machines that translates the IP address associated with a machine to a logical name. It is recommended (but not required) to do this so you don’t have to repeatedly type those 111.222.33.44 IP addresses. Read and execute the section on starting DNS in your firewall documentation.

Adding and Testing Your WebSpeed Specific Rules Once you have configured DNS, or even if you skip this step, you are ready to define your rules. There are a variety of ways to test generic rules for applications including (HTTP, FTP, TELNET, etc.).

For example, the first rule you set up allows access from the outside network to the Web Server on the DMZ machine (rule #1 listed above). Once you have set up this rule, you can test it by simply starting a Web browser on the outside network and typing the IP address (or if you started DNS, the name of the machine the Web server is running on) of the DMZ machine. If the Web server on the DMZ returns a page, you are on your way. If not, recheck your rules in the firewall rules database.

Testing the WebSpeed application rules is simple if you use the WebSpeed SpeedStart utility that comes as part of your standard installation. This utility is installed with the WebSpeed messengers, so when you install your WebSpeed components, you will have access to it. Consult the WebSpeed documentation on how to use the WebSpeed SpeedStart utility. The basic idea of SpeedStart is that it allows you to test all the run-time components of your WebSpeed installation, one by one. When installed properly, you can test each component of WebSpeed by just clicking a button.



Begin adding the rules (#2–3 above) and after each one, use WebSpeed SpeedStart to test your configuration. The order of the rules in this white paper allow you to follow the SpeedStart component testing utility from top to bottom, and test every component in order. If the connection does not work as expected, make sure your rules have been applied to the firewall properly and try again.

Note: In our testing with Raptor, you need to save and reconfigure after adding each rule or the rule is not applied and it could be confusing.

Once you have supplied these rules to your firewall software, you will be able to test your WebSpeed application components together.

Remember, all firewall products keep extensive log files. If you make a mistake, the log files will tell you which components are trying to use ports that the firewall does not allow access to. Use the log files to debug problems and be sure to close any ports you accidentally might have opened when you defined your rules. If left open, these holes can be exploited by a hacker.




PAGE LEFT BLANK FOR DOUBLE-SIDED PRINTING


Planning Guide WebTrac 10.3 Appendix B

Specific Customer Requirements for a Web Server Hosted by VSI

Under certain circumstances, Vermont Systems will host the Web Server portion of your WebTrac configuration.

The following list presents important facts of which the Customer (you) should be aware prior to deciding whether to utilize the option of having VSI host the Web Server. Please contact VSI Sales (877-883-8757 x3200) with any questions.

1 The Customer (you) must allow traffic from the VSI-hosted Web Server to your RecTrac Database/Transaction Server. VSI will provide port numbers and the IP Address of the Web Server.

2 The VSI-hosted Web Server is for the WebTrac application only. No other recreation/city/department functions/pages will run on this Web Server.

3 The VSI-hosted Web Server is remote, so transaction speed can vary significantly depending on internet traffic.

4 The VSI-hosted Web Server will require periodic maintenance which could result in an interruption of the WebTrac site for short periods of time. VSI will do everything in its power to give you ample advance notice of any scheduled down time.

5 VSI will provide the SSL for the VSI-hosted Web Server.

6 Data between the VSI-hosted Web Server and your Transaction Server is encrypted. However, VSI is not responsible for any data loss beyond its direct control.

7 You are responsible for configuring and maintaining firewall rules on your network.

8 Standard VSI Support hours apply:

• Toll Free telephone support with standard maintenance agreement 08:00am – 08:00pm on weekdays.

• Chargeable after hours pager service 08:00pm – 10:00pm on weekdays, and 08:00am – 05:00pm on weekends and VSI Holidays.

9 VSI requires ½ Day (4 Hours) of chargeable training time to set up and configure the VSI-hosted Web Server.


Documents

WebTrac 10.3 Planning Guide - connect001.rectrac.comconnect001.rectrac.com/help-tomcat6/Content/Resources/Misc Docs... · All VSI application software is developed using 4GL Progress