Skip to main content
Version: 4.12.x.x LTS

Standard nevisProxy Patterns

Introduction

The standard nevisProxy patterns can be used to set up nevisProxy instances.

Patterns are classified into categories for easy access; the nevisProxy patterns are classified in the Application Protectioncategory.

Core Patterns

The following diagram shows important patterns in the Application Protection category.

The diagram does not include most add-on patterns. See Standard Patterns Reference for a complete list.

Application Protection patterns

nevisProxy Instance Pattern

The nevisProxy Instancepattern sets up an empty instance of nevisProxy.

You have to use the Virtual Host pattern to add a web.xml file and the required connector configuration.

Additionally, you can assign the Generic nevisProxy Settings add-on pattern to adapt low-level settings in the navajo.xml file.

Additional add-on patterns are planned for future releases (for example, for nevisProxy sizing).

Service Patterns

Patterns that implement the Service interface are used to make content accessible via nevisProxy.

The Hosting Service pattern facilitates the deployment of static pages on nevisProxy over a certain path.

Service access patterns support the integration of backend applications. nevisAdmin 4 provides the following service access patterns:

  • Web Application: Used for classic web applications (e.g., form-based) and hybrid applications. CSRF protection and ModSecurity are enabled by default.
  • REST Service: Used for REST APIs. Basic JSON validation is enabled by default.
  • SOAP Service: Used for SOAP APIs. Schema validation using WSDL is in development for nevisAdmin 4.2.

See Getting Started on how to use these patterns to integrate an application.

Add-On Patterns

Several add-on patterns facilitate application protection. You can assign these add-on patterns to the following patterns:

  • Virtual Host pattern - Assign an add-on to this pattern to change the behavior of the root location. This affects all services.
  • Service patterns - Assign an add-on to a service pattern if you want to configure a feature for this service only. Service patterns are, for example, REST Service and SOAP Service.

Technically, assigning an add-on to a pattern is possible under the following conditions: The add-on pattern must implement the PathLocationAddon interface and the pattern must support the PathLocation interface. See also figure Application Protection patterns.

The add-ons are mostly used to enable WAF features. Example add-ons are:

  • Access Restriction: Use this add-on to white- or blacklist IPs.
  • ICAP Scanning: Use this add-on to perform a virus scan of uploaded files.
  • Request Validation Settings: Use this add-on to fine-tune the request validation by changing the configuration of ModSecurity.

See Standard Patterns Reference for a complete list of the add-on patterns.

What if my Use Case is not Covered by the Standard?

If your use case is not covered by the standard patterns, contact Nevis Support and explain your case. The nevisProxy patterns are in active development and we are interested in your requirements.

In the meantime you have several options:

  • Customize the settings in the navajo.xml file with the Generic nevisProxy Settings pattern. The Help page of this pattern explains which cases are supported.
  • Adapt the configuration in the web.xml file with the Generic Virtual Host Settings pattern or the Generic Application Settings pattern.
  • Solve complex use cases with the Lua script, by means of the Lua HTTP Processing pattern.