Forum Systems Support Blog

Forum Systems 256x Hardware EOL Announcement

2011-08-17T16:58:00.000-07:00

Forum Systems has announced the scheduled end of life for the 2563 and 2564 hardware models. This announcement applies only to legacy 2563 and 2564 models which are no longer available for sale, this notice does not apply to 356x and 456x hardware models. Full year Service and Maintenance contracts for existing 2563 and 2564 devices can be renewed up until December 31, 2011.

Customers are encouraged to migrate to Forum Systems latest hardware platform. For customers currently running 2563 devices, the new model is 4563. For customers currently running 2564 devices, the new model is 4564. All features provided on the legacy 256x series devices are fully supported on the 456x series devices. All policies and rules defined and deployed on the 256x devices can be transferred over to the 456x devices through simple policy import/export process. Forum Systems will provide migration assistance as needed to ensure a timely and seamless transition.

For more information please see: http://www.forumsys.com/EndOfLifePolicy.php

For upgrade inquiries, please contact your account manager or email support@forumsys.com.

Forum Sentry SNMP Monitoring with MIB Browser

2011-08-04T10:31:00.000-07:00

MIB Browser from iReasonings has been confirmed to work for SNMP monitoring of the Forum Sentry, STS, WAF, and Presidio appliances.

With the Forum appliances,SNMP management supports read-only access via v1, v2c and v3. Using SNMP requires the system Management IP address, the Forum private MIB files and an SNMP client application.

While Forum Systems does not officially recommend any specific SNMP client application, we have confirmed that the MIB Browser tool from iReasonings works well with the Forum appliances.

MIB browser is an easy to use SNMP monitoring application that supports SNMP v1, v2c, and v3. Note that the free edition does not support v3. MIB Browser can also be used to capture incoming SNMP traps from Forum Sentry.

For more information on MIB Browser see: http://ireasoning.com/mibbrowser.shtml

For detailed information on configuring SNMP monitoring in Sentry, please refer to the Sentry Monitoring and Reporting Guide or contact Forum Systems Support. To obtain the Sentry documentation please click here (registration required).

Triggering the "Invalid HTTP Message" IDP rule in Forum Sentry

2011-07-22T10:05:00.000-07:00

A request or response message might trigger the "Invalid HTTP Message" IDP rule in Sentry resulting in the "No Matching Request Filter" error. This is a very common support issue that is easily identified and resolved.

By default, WSDL and XML policies in Sentry are configured to allow a specific Content-Type HTTP Header and a specific HTTP Method. The Content-Types and HTTP Methods allowed are both defined in the HTTP Request Filters enabled for the policies. These can be accessed from the Virtual Directory page of a WSDL or XML policy.

For a SOAP 1.1 service the default "SOAP 1.1 Filter" is typically used. This allows for a Content-Type of text/xml and an HTTP Method of POST.

For a SOAP 1.2 service the default "SOAP 1.2 Filter" is typically used. This allows for a Content-Type of application/soap+xml and an HTTP Method of POST.

With WSDL policies, the specific HTTP Request Filters are derived from the WSDL itself and therefore are editable but new HTTP Request Filters cannot be created.

With XML policies, the user can choose from the default list of HTTP Request Filters or create their own and enable as many HTTP Request Filters as necessary.

If a request comes into Sentry that has the wrong Content-Type or is using the wrong HTTP Method, the processing fails with the following error being logged to the System log:

Error Code 0600D:

IDP Rule: 'Invalid HTTP Message', IDP Group 'System Group', Associated Policy: System, Triggered 1 time(s) on Request, Policy: Test WSDL Policy, Client IP: 10.1.2.3, User: -. No matching request filter.

The following SOAP Fault (or something similar depending on your custom error templates) is returned to the calling client application:

To see the Content-Type and Method being used by the client, you can enable DEBUG level logging for the Sentry System log and look for the following entry which shows the incoming HTTP Headers for the request message:

Logging Code 09140:

Received an HTTP request:

Protocol: HTTP/1.1
Scheme: http
Method: POST
Client: 10.1.2.3
Request URL: http://10.1.2.4/testPolicy/test.asmx
Listener Policy: TestPolicyListener
Virtual Directory: /testPolicy/test.asmx/*
Auth Type:
Cookies:
Header Info:
User-Agent: Crosscheck Networks SOAPSonar
Content-Type: text/xml;charset=utf-8
SOAPAction: "http://testSentry/testPolicy/echo"
Host: 10.1.2.3
Content-Length: 362
Connection: keep-alive

To resolve the problem, ensure that the client is specifying the correct Content-Type HTTP Header and/or using the appropriate HTTP Method. Alternatively you can adjust the HTTP Request Filters defined for the policy.

JXplorer - A helpful tool while configuring LDAP policies in Forum Sentry

2011-07-08T09:46:00.000-07:00

The JXplorer LDAP browser is a helpful tool to validate the LDAP policy settings configured in Forum Sentry.

LDAP Policies in Sentry are used as access control groups, for either run-time or admin users. If these users are already stored in an LDAP repository in the environment, Sentry administrators can create LDAP polices to read from the LDAP repositories to validate credentials.

While configuring LDAP policies in Sentry there may be a need to validate the settings necessary to connect to the LDAP server (or to view user, objects, attributes, etc in the LDAP repository). An LDAP Browser is ideal for this testing.

JXplorer is a free open source LDAP browser that works well for validating the settings necessary to configure an LDAP policy in Forum Sentry.

http://jxplorer.org/

You can find more information on configuring LDAP policies in Forum Sentry here (registration required).

Retrieving a WSDL from a Sentry WSDL Policy

2011-06-12T16:44:00.000-07:00

A WSDL Policy in Sentry defines the URI endpoint that the client applications will use to communicate with the services you are protecting with Sentry.

As part of the security Sentry provides, the client will never have access to the application server hosting your web services - the client will access Sentry and Sentry will communicate with the application server. Therefore, the Sentry administrator will need to provide a WSDL that contains the Sentry endpoint to the clients. The WSDL file contains the IP, port number, and full path information that the client uses when sending a request.

This post will describe the multiple ways in which the Sentry administrator can provide the correct WSDL to the clients.

1. URI WSDL Retrieval: There is an option on the Virtual Directory page of the WSDL Policy in Sentry named "Enable WSDL Access". If this option is enabled, Sentry will serve the WSDL to any client that connects with an HTTP GET using the full request URI with the addition of the ?WSDL syntax.

For instance, to obtain the WSDL for a service with the virtual URI:
http://10.1.2.3:80/qaservice/qaservice.asmx

The following URI can be used:
http://10.1.2.3:80/qaservice/qaservice.asmx?WSDL

Note that a web browser can be used to retrieve the WSDL via URI or a web services testing client tool such as SOAPSonar can retrieve and parse a WSDL via URI or file.

2. Manual WSDL Export: When viewing a WSDL Policy, there is an "Export WSDL" button on the top right of the page. This feature allows the administrator to download a WSDL file manually, while choosing to include all operations or operations based on ACLs (access control lists). This allows the admin to provide different WSDL files (with different operations defined) to different clients.

3. Publish the WSDL: When viewing a WSDL Policy, there is a "Publish WSDL" button on the top right of the page. This feature allows the admin to publish the WSDL to a UDDI directory while adding specific information about the business and service. This feature also includes an option to publish all operations or operations based on ACLs.

No matter how the client retrieves the WSDL generated by Sentry, the endpoint will point to the Virtual URI as shown when viewing a WSDL Policy. The Virtual URI consists of the IP and port of the HTTP listener policy and the virtual path specified on the Virtual Directory page of the WSDL Policy.

Automatically Backup the Forum Configuration File

2011-05-10T16:28:00.000-07:00

The Forum appliances (all products) provide a mechanism for automatically exporting and FTPing the configuration file (.FSX file) on a daily basis. This routine ensures that there is always a current configuration backed up for safe keeping.

The automated configuration backup routine is enabled in the Forum CLI. Here are the steps to configure, enable, and test this routine.

1. Access the Forum CLI via SSH or Serial Console. Enter enable mode, so that the ForumOS# prompt is displayed.

2. Run the "system config backup-wizard" command to configure the routine. You will now be prompted to enter the following items:

time of day the backup takes place
the IP address of the FTP server to post the file to
the directory on the FTP server to post the file to
the FTP transfer mode (active or passive)
the FTP server username and password
the configuration file password (the password used to encrypt the file and used when importing the file)

3. Run the "system config backup-test" command to test the settings entered during the wizard. This will export a configuration file (.fsx) and attempt to FTP the file to the server/directory indicated during the wizard.

4. If the test succeeds, run the "system config backup-enable" command to enable the daily backup routine.

To import a saved configuration, simply navigate to the System>>Configuration>>Import/Export screen of the WebAdmin interface and browse to the FSX file. The password to use with the import is the file password entered into the backup wizard. This screen also includes a feature to do a one time export of the configuration file.

Gathering Diagnostic Information with the Forum Sentry XML Gateway

2011-04-13T18:05:00.000-07:00

This article describes methods of reviewing and collecting various diagnostic information from the Forum Sentry XML Gateway. These methods are also applicable to the Forum Presidio FTP Security Gateway, the Forum WAF Gateway and the Forum STS Gateway.

When reporting a technical issue to Forum Systems Support, please provide the version of the product as shown on the General Info page of the WebAdmin interface and the diagnostic information outlined below.

Diagnostic Information Available in the WebAdmin Interface:

With Forum Sentry versions 7.3 and 8.0 there are three types of logs available through the WebAdmin interface on the Diagnostics>>Logging>>Internal Logs page: the Audit logs, the System logs, and the Access logs.

Audit Logs: Audit logs track the changes made to the Sentry configuration by an administrator. This log contains a comprehensive view of user activities and policy additions, modifications or deletions.

System Logs: System logs show information about the actual traffic going through the device. This log captures the changes that occur in the life of a document as well as changes in movement for
a document. As a request is received by the system and the document passes through various
processes, tracking messages are written to the System log.

Access Logs: The Access logs are primarily for the STS Gateway and track authenticated sessions.

Notes on the Internal Logs:

Each log can be downloaded in the following formats: XML, Plain Text, and HTML.
Each log can be downloaded with the following compression formats: ZIP and GNU ZIP.
Additional logging settings including: max log file size, display preferences, and days to keep the logs can be found on the Diagnostics>>Logging>>Settings page of the WebAdmin interface.
You can configure Sentry to always log specific error message based on specific error codes.
The default logging level is INFO for both the Audit and System logs. This is the logging level recommended for the System log in production environments. Forum Systems only recommends using DEBUG logging when there are reported issues in need of troubleshooting.
The internal logs can also be sent off of the system via a Remote Syslog Policy.

More information on the logging available with Sentry, including a listing of error codes and information on the Remote Syslog policies, can be found in the Sentry v7.3 Logging Guide.

Diagnostics Information Available in the Forum CLI:

To view the Internal Logs via the CLI run the "show log" command and follow the onscreen instructions.

The following CLI commands can also be useful in troubleshooting issues:

show general
show connections
show interfaces
show listeners
show max-threads
show routes
show arp

With Sentry version 7.3 there is a new CLI diagnostics command that can only be run from a CLI connection established with HyperTerminal or MiniCom (not available via SSH). This command "runDiagnostics" will typically only be used when there is no SSH or WebAdmin access to a device. This command will gather data and allow the administrator to transfer this data via ZModem. This data should then be sent to Forum Systems Support for review.

Troubleshooting Checklist:

The following are general troubleshooting questions and steps to take when reporting an issue to Forum Systems Support.

Troubleshooting questions:

1. What version of Sentry is being used? You can find this on the General Info page of the WebAdmin interface.

2. Please provide a detailed description of the issue, including as much information about reproducing the issue and the environment (load balancers, routing details, etc..) as possible.

3. When did the problems begin? Were there any recent changes to the Sentry configuration or to the environment that might have triggered the issue?

4. Are the issues occurring on multiple Sentry instances?

5. Is the issue reproducible or is this a sporadic issue?

6. When the failures were occurring, what information was being returned to the client? Or was the client simply timing out?

7. Were there any issues reported with the backend servers that Sentry is communicating with?

8. Is Sentry configured for any of the following: archiving, LDAP auth, SiteMinder auth, or WS Reports to a local database?

Gathering Diagnostics:

1. Please run the following CLI commands and send the output to Forum Support:

show general
show connections
show interfaces
show listeners
show max-threads
show routes
show arp

2. Download and send the Sentry Audit and System logs from any of the days the issues has occurred. If the problem is reproducible, please set the System log threshold to DEBUG mode and reproduce the problem, download the System log, and then set the threshold back to INFO or WARNING level.

3. If the issue might be network related, it may be beneficial to capture the packets using the Packet Capture feature on the Diagnostics>>Logging>>Packet Capture screen of the WebAdmin interface.

All diagnostic information should be sent to support@forumsys.com. If necessary this information can be FTP'd to Forum Systems, contact support@forumsys.com for the FTP site credentials.

FTPS Modes and Clients Supported by Forum Presidio and Forum Sentry

2011-03-03T14:00:00.000-08:00

Forum Presidio supports FTPS for both SSL and TLS. Presidio supports FTPS explicit mode only.

A brief description of Explicit FTPS vs Implicit FTPS:

Explicit: This type of security requires that the FTP client issues a specific command (AUTH SSL or AUTH TLS) to the FTP server after a connection to establish the SSL link has been made. The default FTP server port is used.

Implicit: This is a mechanism by which security is automatically turned on as soon as the FTP client makes a connection to an FTP server. In this case, the FTP server defines a specific port for the client (990) to be used for secure connections. Implicit FTPS is not supported by Forum Presidio.

With FTPS, Forum Systems recommends using AUTH TLS (as opposed to AUTH SSL) whenever possible.

The following FTPS clients have been confirmed to work with the 7.3 release of Forum Presidio and Forum Sentry:

WinSCP: TLS and SSL
SmartFTP: TLS and SSL
FireFTP: TLS only
FileZilla: TLS only
CuteFTP: TLS and SSL
GoFTP: TLS only

If you have a question on or problem using FTPS with Presidio or Sentry please email the details to support@forumsys.com.

Tips for Monitoring and Logging with Forum Sentry

2011-02-10T13:21:00.000-08:00

The following applies to Forum Sentry, Forum STS, and Forum Presidio.

Below is a list of tips/suggestions that can serve as some best practices for production logging and monitoring. More information on the logging options can be found in the Help menu.

1. Sentry has a feature to always log specific error codes, so you can always log particular messages regardless of the log level set.

2. There is a log file size option. If using DEBUG the log might grow quickly and when it reaches this threshold the log is overwritten completely. If you will be downloading log files, after running DEBUG mode, it might be best to set a lower log file size.

3. Sentry allows different download formats. If the log file is very large, set the download format to XML before downloading. If the download format is HTML or plain text, Sentry has to transform the XML log file into these formats. This can be a resource intensive operation on a busy server.

4. Consider using Syslog logging. It is possible to have the local logs use one log level while the Syslog policy uses another. If you frequently notice sluggish performance in the WebAdmin interface while viewing logs, Syslog will help as the logging information is stored off of the system.

5. Use SNMP monitoring to track the CPU, memory, and other statistical information.

6. Sentry monitoring with JMX - With the built in JMX Remote API, JMX provides another broadly accepted option for monitoring the health of the product.

Processing Request and Response Documents Individually with XML Policies in Forum Sentry

2010-11-15T13:51:00.000-08:00

Forum Sentry administrators using XML Policies may wish to process both the incoming request documents and the outgoing response documents separately using a different task lists.

Following the steps below will allow processing of both the request and the response XML documents with an XML Policy in Sentry:

Enable response processing on the HTTP Remote policy.
Import the sample request and response XML documents on the Documents page.
Create two Task Lists, one for each sample document and each with an Identify Document task.
For the request XML document, make sure the Task list uses an Identify Document task to correctly and uniquely identify the inbound XML document. Add any additional tasks.
For the response XML document, make sure the Task List uses an Identify Document task to correctly and uniquely identify the outbound XML document. Add any additional tasks.
Add each Task List to a Task List Group and ensure the "Process all Task Lists" option is disabled.
Associate the Task List Group to the XML Policy.

Both the inbound (request) and outbound (response) XML documents will need to be unique in some way. Given this, the Identify Document tasks will uniquely identify the request or response document and then trigger the remaining tasks in the task lists. When "Process all Task Lists" option on the Task List Group is disabled, the first Task List that successfully matches the XML document is run and all others are ignored.

Case Sensitivity with the Identify Document Task in Forum Sentry

2010-09-16T18:57:00.000-07:00

Forum Sentry administrators using the Identify Document task to uniquely identify a request or response document may wish to make the comparison value of the XPath expression case insensitive. By default the comparison values are case sensitive.

To make the comparison in the Identify Document task case insensitive, set the lower-case function on the XPath expression and make the value lowercase.

Below is an example entry for matching the word "forum" regardless of case. With this entry the values: forum, Forum, FORUM, fORum, etc.. will all match.

Original:

Path: /soap:Envelope/soap:Body/tns:Echo/tns:Buf
Comparator: =
Value: "forum"

Case Insensitive Version:

Path: lower-case(/soap:Envelope/soap:Body/tns:Echo/tns:Buf)
Comparator: =
Value: "forum"

For more information on the Identify Document task please refer to the Task Management Guide available in the Help menu in the WebAdmin interface or contact Forum Systems Support.

Configuring a WSDL Policy within Forum Systems Sentry for use with MTOM

2010-08-04T12:50:00.000-07:00

This article provides instructions for configuring a WSDL Policy within Forum Systems Sentry for use with MTOM attachment processing.

In order to use MTOM with WSDL Policies, you first need to create/add a new HTTP Request filter for MTOM on the WSDL Policy. When this HTTP Request Filter is triggered, the XOP Binary MIME is deserialized back into a standard SOAP message, processed, then re-serialized back into a binary XOP MIME sent to the back-end server.

Step 1: Open the WSDL Policy. On the Services Tab, click the link under PORT.

Step 2: Scroll down to the Request Filters and Press the NEW button:

Step 3: Enter information for a new MTOM Filter as follows:

Name: MTOM Filter

Format: MTOM

Description: MTOM Request Filter

Identification Expression: (Content-Type ==~ "(?i).*application/xop\\+xml.*") && (method == "POST")

Step 4: Save the request filter and the modifications to the WSDL Policy by clicking Save on each screen.

This WSDL policy should now be able to process MTOM attachments.

Configuring the Forum Sentry XML Security Gateway to Communicate with IBM MQ via SSL

2010-07-17T12:42:00.000-07:00

This article provides instructions for configuring the Forum Sentry XML Security Gateway to securely connect to an IBM MQ instance using SSL.

The procedures outlined below utilize Forum Sentry v7.3 and IBM MQ v7.0 (though the steps to configure MQ v6.0 should be similar). This article also assumes the reader is familiar with IBM MQ administration.

Configuring IBM MQ 7 for SSL
==============================

Use the IBM Key Management tool to create a self signed keypair, or import an existing SSL server keypair, using the label: "ibmwebspehermq(queue manager name in lowercase)". For example if your queue manager was "QM_TestMQ7_Server27" then your label would be "ibmwebspheremqqm_testmq7_server27". Note that the queue manager name has to be lower case.
Import any root CA/intermediary certificates necessary for client cert validation into the MQ keystore.
Save the keystore file under the ssl directory for the QM (On Windows: C:\Program Files\IBM\WebSphere MQ\qmgrs\QM_TestMQ7_Server27l\ssl\) as key.kdb in CMS format and then stash the password (File menu -> Stash password).
Within MQ Explorer, on your running Queue Manager, verify that the SSL key repository points to the key file (right click the QM, select properties, select SSL). Note that the extension is left off.
Under the Advanced/Channel folder on the QM, create a new Server-connection channel (Example name: S_TestMQ7_Server27).
Edit the SSL section of the newly created server connection channel's properties. Select the SSL CipherSpec you want to use. This must match the setting you use in Forum Sentry. The 'Authentication of parties initiation connection' is optional and can be set to 'required' if you plan to present client authentication certificates from Forum Sentry.
Apply the changes.

Note: It may be necessary to restart the QM, but only do this after you've configure Forum Sentry following the steps below and are unable to connect/retrieve messages.

Configuring Forum Sentry
==============================

Import any root CA/intermediary certificates necessary to verify the certificate installed on the IBM MQ instance. Note: If using a self signed certificate on MQ, then export the cert from the IBM Key Management tool and import this cert into Sentry as the root (CA) cert.
Create a Signer Group containing the root CA and intermediary certificates necessary to verify your MQ server's SSL certificate.
Create an SSL Initiation policy associating the Signer Group created in the previous step. Note: Enable the "Ignore Server Hostname Verification" option if the certificate is not issued for the correct hostname for the MQ server.
Create a new MQ Listener or Remote policy, enable SSL and associate the SSL Initiation policy created in the previous step. Note: Use the same SSL CipherSpec that the MQ channel is using.
Configure the remainder of the MQ Listener / Remote policy settings according to your environment.

The MQ Listener / Remote policy on Forum Sentry should now be able to communicate with the MQ instance using SSL. If there are problems, the first troubleshooting step should be to restart the QM.

New Podcast: Advantages of Certified XML Devices in your Application Security Lifecycle

2010-07-07T10:06:00.000-07:00

An XML device or application that provides security functions does not mean that the solution itself is secure. A secure XML hardware device requires a properly designed architecture, precise algorithm implementation, secure key storage, encrypted policy data, and a secure API.

Download and hear from Jason Macy, the CTO at Forum Systems who has pioneered the field of XML testing and simulation with over 40,000 product installations worldwide. In this download we will discuss in more detail why the FIPS and DoD Certified Forum Sentry XML Gateway provides distinct advantages over non certified devices, including the following areas:

XML device PKI private key compromise protection

SSL ciphers and XML security

Secure policy data storage

X509 authentication with CRL and parent chain signature verification

Physical hardware integrity

Click here to listen now

Maximize your Web Services Security with Forum Sentry

2010-06-30T16:33:00.000-07:00

It is important to note that one of the main focuses of the Sentry XML appliance is, and has always been, security for your Web Services. Right out of the box there are many security features enabled by default, and the fact that your clients are accessing Sentry and not your back-end service directly is a major security benefit in itself. We take great pride in offering the only patented XML Security Gateway that is both FIPS 140-2 certified and DoD PKI certified.

For a good overview of Sentry's focus on security please visit: http://www.forumsys.com/security/index.php.

You can also find many whitepapers regarding security around XML and Web Services here. We recommend starting with the "Best Practices in Deploying SOA Gateways" and the "Attacking and Defending Web Services" papers for a good introduction.

There are many features of Sentry related to securing Web services that might not always be utilized. These features include: SSL (with or without Mutual Auth), XML Encryption/Decryption, XML Signature/Verification, Intrusion Detection and Prevention (IDP Rules), Pattern Matching, Anti Virus scanning, Identity and Access Control (many different ways to accomplish this), support for all WS Security standards, etc...

Below are some recommendations for utilizing common features in Sentry to further increase the security of your services:

Use SSL with all externally facing services. All network listeners should use SSL (HTTPS). Start by enable SSL, and then consider enabling SSL with Mutual Authentication. SSL with client/server auth allows you to verify the client cert (and tie it to a specific user). At the very least, the network listeners should be HTTPS (SSL). For FTP traffic, Sentry supports FTPS (TLS or SSL) and OpenPGP encryption/decryption/signatures/verification.
Use IP ACLs on your network listener policies to only allow incoming traffic from specific IP addresses or IP ranges. If a client tries to connect from an unknown IP range the connection will be rejected.
Tighten existing IDP rule thresholds or add new IDP rules depending on your specific criteria.
Enable Anti Virus Scanning.
Consider creating custom Pattern Match policies to catch specific text strings. This helps to ensure no confidential data is leaked out with the response messages and prevents any harmful XML attacks coming into the service.
Consider using XML encryption and XML decryption with your trading partners. The trading partners would encrypt the request data before sending to Sentry, the request data is then decrypted on Sentry. For response processing, Sentry would encrypt the response data before sending it back to the client.
Consider using Schema Tightening and advanced validation options with your WSDL policies.
Utilize Sentry's built in PKI infrastructure. Create, import, and store all keys related to the security of your services within Sentry. For added PKI security upgrade to the Sentry appliances that include the FIPS Level III HSM.

How to tell if your services are secure?

In addition to the recommendations above for tightening the security of your services with Sentry, we strongly recommend you perform some security/vulnerability/penetration testing of your services hosted on Sentry. You can use SOAPSonar from Crosscheck Networks to perform this testing. This is a great tool for functional and performance testing as well, but there is patented technology focused on security/vulnerability testing that you won't find with any other SOA test tools.

For instance, SOAPSonar includes a Vulnerability mode that enables the user to run scans against your services and report any potential issues - and explain how to fix them! In addition, if you configure SSL, encryption/decryption, or other WS Security features on Sentry, you can use this tool to test these features.

You can download a free evaluation of SOAPSonar here: http://www.crosschecknet.com/products/soapsonar.php.

Understanding Group Remote Policies in Forum Sentry

2010-06-25T16:38:00.000-07:00

As an XML Security Gateway, Forum Sentry sits in front of your SOAP/XML/REST Web services protecting your back-end services. For externally facing services (traffic comes in from outside your network), Sentry is responsible for handling all incoming XML traffic sent from your trading partner's client applications and destined for your services. Sentry processes these incoming requests and then sends them along to the back-end service (the remote server).

Often times the Forum Sentry gateway resides behind network load balancers which distribute the incoming requests among multiple Forum Sentry appliances. The load balancers ahead of Sentry allow for redundancy and increased throughput.

Forum Sentry, through the use of Group Remote Policies, also includes support for load balancing requests to multiple remote servers.

A Group Remote policy is a collection of Remote network policies that provides failover for redundancy in the case of a remote server failure and can optionally use one of several strategies for remote load balancing. A Group Remote Policy can be associated with a WSDL or XML policy.

There are several Load Balancing strategies available with the Group Remote Policies. The strategies are broken into two categories: Passive Load Balancing Strategies and Adaptive Load Balancing Strategies. Below is a quick summary of each.

Passive Load Balancing Strategies

Passive strategies choose a Remote policy without reference to the traffic passing through the system.

Failover - Uses the order of the configured Remote policies in the group to signify priority. Always chooses the first Remote policy from the list of eligible Remote policies unless it is disabled or inaccessible, in which case it moves to the second, etc.
Round Robin - Initially chooses an eligible Remote policy at random and then rotates through the list of eligible Remote policies in order, choosing the next eligible Remote policy for each new client request.
Random - Chooses an eligible Remote policy at random for each new client request.
Weighted Random - Chooses an eligible Remote policy at random for each new client
request, using the relative weights configured for each Remote policy. The configured weights set the relative odds that each Remote policy will be selected if eligible.

Adaptive Load Balancing Strategies

Adaptive strategies gather statistics about current and past traffic passing through the system and choose a remote server based on the traffic patterns.

Transfer Throughput - Chooses the highest performing eligible Remote policy. Performance is measured by the average transfer throughput of the last 100 requests, in bits per second.
Active Requests - Chooses the eligible Remote policy which is the least busy, based on the
number of concurrent requests the Remote policy is servicing.
Response Time - Chooses the highest performing eligible Remote policy, measuring
performance by the average response time of the last 100 requests. The Response Time strategy chooses the Remote policy with the lowest average response time.

Summary of Group Remote Failover Behavior

All Group Remote policies, regardless of the load balancing strategy selected, includes failover functionality that works as follows:

The list of policies available for a Group Remote policy to use initially includes all the Remote policies configured for the Group Remote policy. Removed from this list are all Remote policies which have been manually disabled via the WebAdmin and any Remote policies which are known to be inaccessible.

The Group Remote Policy discovers that a Remote policy is inaccessible only after the policy is chosen for use by a client request and cannot be reached. If the Remote policy is reachable but returns an error, it is still considered to be accessible - only an unreachable Remote policy is removed from consideration. Once a Remote policy is discovered to be inaccessible and removed from the list, the Group Remote policy will begin trying to connect to the remote server of the Remote policy in the background, with a retry delay as configured in the Group Remote policy. The Remote policy will be returned to the list once it can be reached to process requests.

For more information on the Group Remote policies please refer to the latest HTTP Network Policies Guide available in the Help section of the WebAdmin interface.

Welcome to the Forum Systems Technical Support Blog

2010-06-22T12:30:00.000-07:00

Thanks for visiting the Forum Systems Technical Support Blog. This is a place where we will post and discuss all things related to the Forum Systems products. We intend to provide detailed technical information helpful to the administrators of the Forum Systems products as well as openly discuss the product roadmaps and technologies.

Visitors are welcome to comment and ask follow up questions. Please note that any critical product issues should be emailed to support@forumsys.com or reported via phone at 800-707-4590.

For full documentation, FAQs, and the ability to create Support Tickets please visit: https://helpdesk.forumsys.com.

Please check the blog periodically as we will update this site with common 'How To' guides and post updates when there are new versions of our products released. If there are any specific guides you'd like to see please don't hesitate to post your recommendations or to email them to support@forumsys.com.

Best Regards,

Forum Systems Technical Support
support@forumsys.com
800.707.4590 Forum Support Hotline