API Security

Simple Steps for Securing Browser Traffic through Forum Sentry

By | Date posted: January 12, 2016

Many Forum Sentry use cases involve proxying (forward or reverse) browser based (HTML, JavaScript, etc) data through the Sentry API Gateway. These use cases often involve secure SSL Termination, Single Sign On (SSO) for web portals as well as security scanning of the data. The Forum Sentry API Gateway is often used as a secure replacement for Apache reverse proxies.

Sentry administrators are usually very familiar with building API Security Management policies for handling SOAP, XML, REST, JSON type API traffic, however, they are usually less familiar with using Forum Sentry to secure browser-based traffic using the same API Security Management technology. Below are a few simple steps to help you pass your web traffic through Forum Sentry.

1. Use an HTML Policy for Browser Traffic

With web browser traffic, there may be multiple Content-Types and HTTP methods in use and the filtering of these may not be important.  Therefore the Message Type filters for HTML policies are more open.  Contrast this to a WSDL policy, where the HTTP method should always be a POST and the Content-Types are known entities.

There are different Content Policies in Sentry designed to handle different types of traffic. For instance, XML policies are built for XML traffic, REST policies for RESTful web services, and HTML policies for HTML or other web browser based traffic.

Technically any supported data types can be passed through any of the Content Policies. So for example, you can pass HTML traffic over an XML policy. However, each Content Policy has default configuration options for specific types of data and message flows. Specifically, each Content Policy has unique Message Type Filters enabled (associated to the virtual directory) which specify the Content-Type and HTTP Methods expected for each type of traffic flow. If data hits a virtual directory and the wrong Content-Type or Method is used, no Message Type Filter will be matched an a default IDP rule will trigger and block the message.

If you see the Invalid HTTP Message failure, see: FAQ: Triggering the “Invalid HTTP Message” IDP Rule in Forum Sentry –https://helpdesk.forumsys.com/entries/39885696

2. Configure the Virtual Directories for the HTML Policy: Using a root directory and modifying the Filter Expression

Note that when Sentry is simply acting as an HTTP proxy for browser based traffic, there are often many more requests/responses (transactions) than with web service calls. All of the calls for images, and other files needed by the browser to render the page correctly are potentially Sentry transactions.

If all of these requests and responses will go through Sentry they need to be explicitly allowed.  These messages may use different URIs, specifically different paths. Therefore using a root virtual directory with just  / for the virtual path will process all requests that come into a directory that are not explicitly defined.

In many form post / cookie based SSO use cases, there may be multiple virtual directories in a single HTML policy. For example:

/login/login.html – a public directory used to proxy the browser request to the login page behind Sentry

/login – where the form post credentials are submitted to and consumed by Sentry, which then generates a cookie, then redirects to /

/ – the root directory that is requiring a cookie authentication then proxying all requests to the remote web servers. If auth fails, redirect to /login/login.html

/ logout – where the cookie can be logged out and the session terminated

In addition to the path, the characters allowed at the end of the URL are also filtered by default with Sentry policies. This is the Filter Expression field on the virtual directory page and you may need to adjust the from the default of (/.*)? to just .* which is a wild card.  Leave the Replace Expression as $0 if you want Sentry to keep all characters that the browser sends in the URL.

3. Setup SSL Policies and Security

The primary benefit for using Sentry to protect web servers is its ability to rapidly enable and easily manage SSL traffic.

Forum Sentry does not use OpenSSL and therefore is not vulnerable to the many and widespread OpenSSL vulnerabilities such as Heartbleed.  Many Sentry customers have replaced older unsecured Apache reverse proxies with Sentry. Forum Systems always recommends SSL Termination at Sentry rather than at the upstream load balancer.  Many popular load balancers use OpenSSL are impacted by all known and future OpenSSL vulnerabilities.

The SSL policies in Sentry can be configured with or without client/server cert validation, with or without cert mapping to a user. You can also control which versions of TLS / SSL protocol to be used and which cipher suites are allowed.

SSL Policies are associated to the Network Policies.  SSL Termination to HTTP Listener policies, and SSL Initiation to HTTP Remote policies.

At the layer 7 level, Sentry can protect against many other types of attacks. WAF rules are built for the OWASP top ten vulnerabilities and are used to protect against things like SQL injections and cross site scripting attacks.  Sentry task lists can do query parameter filtering. URL rewriting, custom HTTP header processing, full pattern matching on request and response documents, target or general AV scanning, attachment processing or stripping, and much more.

To seamlessly redirect browser requests that come in via HTTP to HTTP, see:


4. Enable Single Sign-On for Browser Based Traffic Flows

In addition to securely proxying the browser based traffic, Sentry can be used to enable SSO through a variety of technologies.

While there are many options for this, the most common for browser based traffic are:

  • Form Post Authentication with FSSESSION Cookies
  • OAuth 2.0
  • SAML SSO Web Browser  Profile

5. Load Balancing – Routing Considerations for Browser Based Traffic Flows

Most Sentry deployments consist of multiple active instances where the load balancer routes the traffic to based on a specific load balancing strategy (ie: failover, round robin, etc.).

When there are multiple remote web servers behind Sentry, the Group Remote Policies in Sentry allow for load balancing to these servers. There are a variety of load balancing strategies available as well as the ability to set server affinity (stickiness).

Sentry also supports content based routing, so that a specific request can be routed to a specific server based on variety of criteria.. including the client IP, a header value, a query parameter value, a user attribute, etc.

6. Using the Same HTTP/S Listener with Multiple Virtual Directories

The use case may call for securing multiple web sites using the same IP:Port combination (HTTP/S Listener Policy) with Forum Sentry.  The HTTP/S Listener policies can be reused across multiple virtual directories, with the caveat that each virtual directory has some unique criteria.

When Sentry receives a request it has to match the request to a defined virtual directory.  If it cannot match, it will issue the “Server Error 404 The requested virtual directory was not found” error.

Sentry uses 3 criteria to match the incoming request URL to a virtual directory. One of these 3 has to be unique for each virtual directory:

Using the Request URL below as an example:

  1.  Protocol://IP_Address:Port combination – the HTTP/S Listener. In the example above this is
  2. Virtual Path – everything following the Port number in the URL. In the example above, this is /login.
  3. Incoming Host Header – set by the client using the value of the hostname, DNS name, or IP entered to access the Sentry virtual directory. In the example above, this is

When you want to have multiple virtual directories using the same IP:Port/VirtualPath, use the Virtual Host option on the virtual directory, specifying what the incoming Host header value will be. Sentry will now use this 3rd criteria to match the Request URL to the virtual directory. Note that the Sentry log at DEBUG level will show the full Request URL and which virtual directory it was matched to.

Summary – Essentials for Passing Browser Based Traffic through Sentry

  • Use an HTML policy for browser based traffic flows
  • Create the appropriate virtual directories correctly for the traffic flow and modify the Filter Expression on each
  • Use SSL and other Sentry features for security
  • Enable SSO with Sentry
  • Use Sentry load balancing and dynamic routing options with multiple back-end web servers
  • Use the Virtual Host option on the virtual directory to allow for using the same HTTP/S listener policy for multiple sites

How to create a REST policy in Forum Sentry

By | Date posted: April 5, 2014

In this tutorial, you will learn how to create a REST policy in Forum Sentry. As an API gateway, Forum Sentry enables you to lockdown APIs that generate XML and JSON traffic in your network. Three simple steps are required for setting up a REST policy: i) Registering the RESTful service endpoint ii) Setting up a listener iii) Configuring a REST policy that ties the listener and the endpoint. Let’s go through these steps.
Read more

Protecting your API Listener through SSL

By | Date posted: February 5, 2014

In this tutorial, you will learn how to rapidly protect your corporate APIs by providing a centralized SSL policy for your service.  We will use three components for this tutorial:  (i) TempConvert – a publicly available service that will be the corporate service that you plan to protect through SSL (ii) Forum Sentry to enable centralized API security via an SSL policy (iii) SOAPSonar used as a testing tool.  Download and install Forum Sentry and SOAPSonar to follow this tutorial.

Read more

Signer Groups and CRLs for API Security

By | Date posted: February 3, 2014

Signer Group for API SecuritySigner Groups and CRLs are the cornerstone of PKI management necessary for API Security. In asymmetric cryptography used for SSL, when an X.509 certificate is presented to a client or a server, a process of certificate chain validation establishes trust in the X.509 certificate and the public key that it represents.  Certificate chain validation requires intermediate and root certificates that are embedded in the client (e.g., a browser) or a server (e.g., an Apache server).  Additionally, if an X.509 certificate is compromised, through Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol OCSP, certificates can be marked as revoked such that any entity presenting such certificates cannot be trusted.  Certificate validation through Signer Groups and revocation though CRLs or OCSP form the backbone of PKI management necessary for SSL, XML, SOAP and Big Data security.

In the tutorial, we will show how to enable and manage Signer Groups and CRLs rapidly for establishing APIs security using Forum Sentry API Gateway.

Read more

Key Generation and Certificate Signing Request

By | Date posted: January 30, 2014

SSL-protocol and data-level encryption are both based on Public Key Infrastructure (PKI) that uses public-private key pairs for asymmetric cryptography.  Generating such key pairs and issuing a certificate signing request are initial steps for enabling privacy.  Learn how to generate keys in Forum Sentry without requiring command line toolkits such as openssl. These key pairs can then be consumed by SSL or content encryption policies for securing XML, HTML, SOAP, JSON over a variety of protocols.

Read more

SSL Policies for securing your APIs

By | Date posted: January 29, 2014

Forum Sentry provides granular control for centralized SSL/TLS protection of your APIs running on application servers, web servers or message queues.  Forum Sentry typically sits in front of such components and deals with all the SSL related communication for your APIs so that you can focus on building business functionality while Forum Sentry takes the ownership of your security policies.

Learn how to set SSL policies for your XML, JSON, HTML, SOAP traffic and the benefits of using Forum Sentry for protecting your SOA, API components.

Read more