nevisadmin-plugin-nevisproxy

Access Restriction

Sets up a filter in nevisProxy to block or filter incoming requests based on the source IP of the request.

The pattern can be assigned to applications or an entire Virtual Host using Additional Settings.

Blocked requests are responded to with HTTP error code 403.

To produce a nice looking error page, ensure that you have configured an error page for 403 on the Virtual Host or use the HTTP Error Handling pattern on the same location.

Listing Type

Indicates if Source IPs should be used as blacklist or whitelist.

blacklist: Access from all configured Source IPs is denied. All other IPs are allowed.
whitelist: Access is allowed only for IPs in the Source IPs list. All other IPs are blocked.

Source IPs

List of client source IPs which shall be allowed. You may include entire range of IPs by separating two IPs with -. If there is load-balancer in front of nevisProxy please configure it to preserve the client source IP. IPv6 is not supported here.

Examples:

10.0.0.1: specific IP address
192.168.0.0-192.168.0.255: range of IP addresses
0.0.0.0-255.255.255.255: all IP addresses

Source IP HTTP-Header

Optional setting used to specify HTTP header that contains the users IP. Otherwise, a default environment variable from nevisProxy is used.

Examples:

X-Forwarded-For

Country database

IP geolocation database file for country filtering.

Currently only the mmdb format (MaxMind Database) is supported. This is a binary file format.

Rules

Defines what action should be taken for a specified country.

Possible actions are:

allow: Requests are let through
log: A log entry is made for each request from the specified country
block: Blocks requests from a country

Default Action

Defines the action taken either when no country rules were matched or the IP of a request does not have an associated country in the database.

Possible actions are:

allow: Requests are let through
log: A log entry is made for each request
block: Blocks requests

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Allow Override

By default, access restriction rules apply to all sub-locations.

For instance, when you assign an Access Restriction pattern to a Virtual Host all applications on this virtual host will be affected.

To replace the rules defined on a parent location select enabled on all Access Restriction patterns in the hierarchy.

If disabled is selected anywhere in the hierarchy the rules are considered additional.

Technical Details:

This feature is implemented using a nevisProxy LuaFilter. Mapped filters are inherited to sub-locations unless an exclude-url-regex is defined.

By selecting enabled the generator is informed that the mapped filter has the purpose access restriction. The generator then ensures that an exclude-url-regex entry is generated when a filter with the same purpose is mapped to a sub-location.

Automatic Key Store

Sets up a key store managed by nevisAdmin 4.

In classic deployment the private key is generated during deployment by running a command on the target host.

nevisAdmin then downloads the CSR and issues a certificate, which is deployed to the target host.

In Kubernetes deployment a custom resource definition (CRD) is generated and sent to the Nevis Operator running in the cluster.

Set the inventory variable __nevisadmin_pki_automatic_allowed_mode to restrict the allowed modes:

any (default) - assignment of key management patterns is optional.
explicit - assign patterns where-ever a key store or trust store is required.

This example illustrates how the key store looks on the target system:

[root@nevis /]# ls -l /var/opt/keys/own/<name>/
total 40
-rw-r----- 1 root nvbgroup 1103 Dec  1 07:05 ca-chain.pem
-rw-r----- 1 root nvbgroup 1013 Dec  1 07:05 cert.pem
-rw-r----- 1 root nvbgroup  887 Dec  1 07:05 csr.pem
-rwxr-x--- 1 root nvbgroup   40 Dec  1 07:05 keypass
-rw-r----- 1 root nvbgroup 1675 Dec  1 07:05 key_pkcs1.pem
-rw-r----- 1 root nvbgroup 1704 Dec  1 07:05 key.pem
-rw-r----- 1 root nvbgroup  451 Dec  1 07:05 key_pub.pem
-rw-r----- 1 root nvbgroup 2053 Dec  1 07:05 keystore.jks
-rw-r----- 1 root nvbgroup 2309 Dec  1 07:05 keystore.p12
-rw-r----- 1 root nvbgroup 2688 Dec  1 07:05 keystore.pem

Owner(s)

Select an instance pattern which defines the target hosts of this Automatic Key Store. This setting is required only when this pattern is assigned to an Automatic Trust Store.

Automatic Trust Store

Sets up a trust store managed by nevisAdmin 4.

In classic deployment the certificates of trusted key stores are deployed to the target host.

In Kubernetes deployment a custom resource definition (CRD) is generated instead and sent to the Nevis Operator running in the cluster.

Set the inventory variable __nevisadmin_pki_automatic_allowed_mode to restrict the allowed modes:

any (default) - assignment of key management patterns is optional.
explicit - assign patterns where-ever a key store or trust store is required.

This example illustrates how the trust store looks on the target system:

[root@nevis /]# ls -l /var/opt/keys/trust/<name>/
total 16
-rwxr-x--- 1 root nvbgroup   16 Dec  1 07:05 keypass
-rw-r----- 1 root nvbgroup 1656 Dec  1 07:05 truststore.jks
-rw-r----- 1 root nvbgroup 2042 Dec  1 07:05 truststore.p12
-rw-r----- 1 root nvbgroup 2116 Dec  1 07:05 truststore.pem

Trusted Key Store

Assign one or multiple Automatic Key Store patterns to establish a trust relation.

Additional Trusted Certificates

Upload additional trusted certificates in PEM format.

The content of all files will be concatenated and added to the truststore.* files generated by this pattern.

You can make this a variable and upload the files in the inventory using the Attach files function.

CSRF Protection Settings

Customize CSRF protection for an application, for example, Web Application.

You can assign the pattern to Virtual Host patterns as well, to configure CSRF protection for all applications on this host.

Set to lax to issue a separate cookie with the SameSite flag set to lax. In this configuration, links and redirects from other domains are allowed, while CSRF-prone requests (e.g. POST) should be prevented by the browser.

Set to off to not send an additional cookie. There are several reasons why this feature may be disabled:

Not all browsers support the SameSite flag and behave incorrectly by never sending the cookie. Older versions of IE and Windows may be affected.
The SameSite flag breaks SAML use cases when POST binding is used. SP-initiated authentication does work with NEVIS but all other SAML process (e.g. logout) will fail.

Header-based Check

CSRF protection can be obstructive for some cross-domain use cases (e.g. federation or providing a public REST API).

Allowed Domains

CSRF protection can be obstructive for cross-domain use cases (e.g. federation or providing a public REST API).

Enter domains which should be excluded from header-based CSRF protection. There is no support for wildcards, pre- or postfix notations (sub-domains must be listed individually).

Example:

www.adnovum.ch 
adnovum.ch

Configure whether cookies are to be returned to the caller or stored in the user session.

You may also assign the pattern to multiple applications, and set Shared Protected Cookies to share cookies between applications.

Note that cookie sharing is supported only for applications using the same session in nevisProxy, that is, applications protected by the same authentication realm.

The default cookie handling differs based on the type of application:

Type	Behaviour
Web Application (with authentication)	Cookies are stored.
Web Application (public)	Cookies are allowed to passthrough.
REST API	Cookies are dropped.
SOAP Service	Cookies are dropped.

Client Cookies

Cookies listed here will be allowed to pass through.

Use for cookies which should be returned to the caller (e.g. browser).

Regular expressions are supported.

Example:

LANG.*

Shared Protected Cookies

Cookies listed here will be stored in nevisProxy and shared between all applications which have this pattern assigned.

Note that storing cookies requires a user session. Thus, we recommend to not use this feature for applications which are supposed to be stateless and public.

Regular expressions are supported.

Note that cookies matching ^Marker_.*$ will never be stored as a corresponding allow rule is generated to support Session Expiration features of the SAML SP Realm.

Example:

LANG.*

Protected Cookies

Cookies listed here will be stored in nevisProxy.

However, cookies marked as Client Cookies in any Cookie Customization pattern assigned to the same application will still be allowed to pass through!

Storing cookies requires a user session. Thus, we recommend to not use this feature for stateless or public applications!

Incoming cookies with the same name will be blocked.

Regular expressions are supported.

Example:

.*SESSION.*

When multiple Cookie Customization patterns are used it happen that a certain cookie is defined as both a Client Cookie and as a Shared Protected Cookie for the same application.

By default, this conflict is resolved by allowing the cookie to pass-through, treating it as a Client Cookie.

This behaviour is usually more robust but less secure as the cookie will be accessible in the browser.

Select protect to threat the cookie as a Shared Protected Cookie instead.

Default Service

Makes the configured Frontend Path(s) accessible on the assigned Virtual Host(s) by mapping a DefaultServlet.

You can decorate the paths by assigning Additional Settings, for example, to provide custom services using nevisProxy filters.

Note that if your request passes through the entire filter chain without being responded or redirected an error code 404 is returned.

The pattern is only to be used when there is no pattern for your use case. Whenever possible, use the following patterns instead:

Web Application, REST Service, SOAP Service: to make a backend application accessible
Standalone Authentication Flow: to provide an entry point for flows implemented in nevisAuth
Hosting Service: to host static resources

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Frontend Path(s)

The path(s) which shall be accessible on the assigned Virtual Host(s).

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Generic Application Settings

Customize the web.xml configuration for an application using XML constructs as described in the nevisProxy Technical Documentation.

Use as add-on for Web Application, SOAP Service, or REST Service.

The following expressions may be used for all applications:

${name}: sanitized name of the pattern
${service.name}: the name of the application
${service.id}: the unique ID of the application
${host.key}: use as EntryPointID when adding a custom IdentityCreationFilter (advanced use case)

For applications with only 1 Frontend Path:

${service.path}: the frontend path of the application, excluding trailing slash / and asterisk *
${service.mapping}: the url-pattern calculated for the frontend path of the application

In case an Authentication Realm is assigned:

${realm.name}: name of the realm (use for StateKey / DelegateSource)
${auth.connector}: name of the Esauth4ConnectorServlet (use for AuthenticationServlet)
${logrend.renderer}: name of the LoginRendererServlet
${logrend.connector}: name of the Http(s)ConnectorServlet for nevisLogrend (if nevisLogrend is used)

When defining filters it is recommended to set Filter Mappings to automatic. This way the filters are mapped to all frontend paths of the application.

Filters and Mappings

Configure filters and their mappings using the XML syntax described in the nevisProxy Technical Documentation.

Filters that have the same name as other filters (even those defined by other patterns) will be combined: the init-param sets will be merged where possible. Direct contradictions are interpreted as validation failures.

Example 1: Create (or patch) a filter with a fixed name

<filter>
   <filter-name>SomeName</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   <init-param>
      <param-name>...</param-name>
      <param-value>...</param-value>
   </init-param>
</filter>

Example 2: Create (or patch) a filter using an application-specific name

<filter>
   <filter-name>SomeName_${service.name}</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   ...
</filter>

Example 3: Map a filter to a sub-path of the assigned application(s). This example works for applications which have 1 frontend path only.

<filter-mapping>
   <filter-name>SomeFilter</filter-name>
   <url-pattern>${service.path}/custom/*</url-pattern>
</filter-mapping>

Example 4: Use multi-value expressions

Multi-value expressions replicate an entire line for each associated value.

Use the expressions *{service.path} and *{service.mapping} to generate filters which must contain the frontend paths of all assigned applications.

The following snippet is not complete but should illustrate the concept:

<filter>
    <filter-name>FormSigning</filter-name> 
    <filter-class>ch::nevis::isiweb4::filter::validation::EncryptionFilter</filter-class>
    <init-param>
        <param-name>EntryURL</param-name>
        <param-value>
            *{service.path}/
        </param-value>
    </init-param>
    ...
</filter>

Filter Mappings

Choose between:

manual (default): only the filter-mapping elements which have been configured via Filters and Mappings will be added.
automatic: filters configured via Filters and Mappings will be mapped to all Frontend Paths of the application.
both: like automatic but additional filter-mapping elements are allowed as well.

Filter Phase

When adding filter-mapping elements, a phase must be defined.

The phase defines where the filter-mapping is placed in the web.xml and ensures that filters are applied in the right order, relative to other phases.

The order within a certain phase is undefined as it must not matter.

The order for requests is START to END and END to START for responses.

This setting applies to all filter-mapping elements.

The filter-mapping elements may be provided via Filters and Servlets, or created automatically (see Filter Mappings for details).

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

This setting is ignored when you patch a filter generated by another pattern (e.g. by adding, overwriting, or removing an init-param element) but don't create any filter-mapping element.

Servlets and Mappings

Configure servlet and/or servlet-mapping elements using the XML constructs described in the nevisProxy Technical Documentation.

You may add new elements or customize elements provided by other patterns.

Reference a servlet by setting servlet-name. Use Connector_${service.name}for the servlet which connects to the backend application.
Reference a servlet-mapping by setting url-pattern.

In Kubernetes side-by-side deployment a postfix is added to service names. Use the expression ${service.postfix} connecting to a service deployed against the same inventory.

Example 1: Add or overwrite an init-param:

Enable load-balancing when there are multiple backend servers.

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>LoadBalancing</param-name>
    <param-value>true</param-value>
  </init-param>
</servlet>

Instruct nevisProxy to a add Content-Type header when missing.

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>ProxyPolicy</param-name>
    <param-value>mime-completion</param-value>
  </init-param>
</servlet>

Example 2: Remove an init-param (no param-value provided):

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>CookieManager</param-name>
  </init-param>
</servlet>

Example 3: Change the servlet-mapping for an application to use a different servlet by changing servlet-name.

<servlet>
   <servlet-name>Connector_Conditional_${service.name}</servlet-name>
   <servlet-class>ch::nevis::isiweb4::servlet::mapping::ServletMappingServlet</servlet-class>
   ...
</servlet>
<servlet-mapping>
   <servlet-name>Connector_Conditional_${service.name}</servlet-name>
   <url-pattern>${service.path}/*</url-pattern>
</servlet-mapping>

Removing servlet or servlet-mapping elements is not supported.

Template Parameters

Define Template Parameters.

Examples:

backend-host: backend.siven.ch

These parameters can be used in:

Servlets and Mappings
Filters and Mappings

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

Remove Filter Mappings

Remove <filter-mapping> elements generated by other patterns.

The syntax is a map of <filter-name>:<url-pattern>, according to elements from the web.xml.

In the <filter-name> the expressions ${service.name} and ${realm.name} may be used.

For applications which have only 1 frontend path you may use ${service.mapping} instead of <url-pattern>.

Examples:

ModSecurity_${service.name}:${service.mapping}
Authentication_${realm.name}:${service.mapping}

Generic QoS Configuration (mod_qos)

Assign the pattern to a Virtual Host using Additional Settings.

Use to configure mod_qos in case the standard configuration is not sufficient.

mod_qos is quite powerful, and can cover may use cases. See mod_qos documentation for further information.

The pattern is experimental and may change in future releases. The mod_qos directives are not validated.

The directives are applied using an ApacheConfigFilter (named Qos), which is added to the web.xml of the Virtual Host.

Server Directives (Experimental)

Server level directives can be entered here.

These directives apply to the entire nevisProxy Instance which means that other Virtual Host patterns may be affected.

Examples:

QS_ClientEventBlockCount 200 300
QS_SetEnvIf NAVAJO_HTTPSESS_CREATED !QSNOT QS_Block=yes
QS_SrvMaxConnClose 85%
QS_SrvMaxConnPerIP 75
QS_SrvMinDataRate 75 300 250

Host Directives

Host level directives can be entered here.

Generic Virtual Host Settings

Customize the web.xml configuration using XML constructs as described in the nevisProxy Technical Documentation.

Use as add-on for the Virtual Host pattern. The following expressions are supported:

${name}: sanitized name of the pattern
${service.name}: the name of the virtual host
${service.id}: the unique ID of the virtual host
${service.path}: the base path of the virtual host (empty String)
${service.mapping}: the url-pattern for the virtual host /*

Filters and Mappings

Configure filters and their mappings using the XML syntax described in the nevisProxy Technical Documentation.

Example 1: Create (or patch) a filter with a fixed name

<filter>
   <filter-name>SomeName</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   <init-param>
      <param-name>...</param-name>
      <param-value>...</param-value>
   </init-param>
</filter>

Example 2: Create (or patch) a filter using an application-specific name

<filter>
   <filter-name>SomeName_${service.name}</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   ...
</filter>

Example 3: Map a filter to a sub-path of the assigned application(s). This example works for applications which have 1 frontend path only.

<filter-mapping>
   <filter-name>SomeFilter</filter-name>
   <url-pattern>${service.path}/custom/*</url-pattern>
</filter-mapping>

Example 4: Use multi-value expressions

Multi-value expressions replicate an entire line for each associated value.

Use the expressions *{service.path} and *{service.mapping} to generate filters which must contain the frontend paths of all assigned applications.

The following snippet is not complete but should illustrate the concept:

<filter>
    <filter-name>FormSigning</filter-name> 
    <filter-class>ch::nevis::isiweb4::filter::validation::EncryptionFilter</filter-class>
    <init-param>
        <param-name>EntryURL</param-name>
        <param-value>
            *{service.path}/
        </param-value>
    </init-param>
    ...
</filter>

Filter Mappings

Choose between:

manual (default): only the filter-mapping elements which have been configured via Filters and Mappings will be added.
automatic: filters configured via Filters and Mappings will be mapped to /*.
both: like automatic but additional filter-mapping elements are allowed as well.

Filter Phase

When adding filter-mapping elements, a phase must be defined.

The phase defines where the filter-mapping is placed in the web.xml and ensures that filters are applied in the right order, relative to other phases.

The order within a certain phase is undefined as it must not matter.

The order for requests is START to END and END to START for responses.

This setting applies to all filter-mapping elements.

The filter-mapping elements may be provided via Filters and Servlets, or created automatically (see Filter Mappings for details).

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

This setting is ignored when you patch a filter generated by another pattern (e.g. by adding, overwriting, or removing an init-param element) but don't create any filter-mapping element.

Servlets and Mappings

Configure servlet and/or servlet-mapping elements using the XML constructs described in the nevisProxy Technical Documentation.

You can also customize elements which have been generated by other patterns. Elements can be referenced as follows:

servlet: servlet-name
servlet-mapping: url-pattern

In Kubernetes side-by-side deployment a postfix is added to service names. Use the expression ${service.postfix} connecting to a service deployed against the same inventory.

Example 1: Add or overwrite an init-param for an existing servlet:

<servlet>
  <servlet-name>Hosting_Default</servlet-name>
  <init-param>
    <param-name>NoMatchFile</param-name>
    <param-value>/index.html</param-value>
  </init-param>
</servlet>

Example 2: Remove a servlet-mapping:

<servlet-mapping>
    <url-pattern>/app/*</url-pattern>
</servlet-mapping>

Here we left out the servlet-name to tell the pattern to remove the servlet-mapping for the given url-pattern.

Note that the mapping of the hosted resources is an exception and cannot be removed this way (see the property Hosted resources of the Virtual Host pattern for more information).

Removing a servlet element is not supported.

Template Parameters

Define Template Parameters.

Examples:

backend-host: backend.siven.ch

These parameters can be used in:

Servlets and Mappings
Filters and Mappings

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

Remove Filter Mappings

Remove <filter-mapping> elements generated by other patterns.

This is an advanced configuration. Use only when you want to remove a <filter-mapping> but keep the <filter> element, e.g. to map it on a sub-location.

The syntax is a map of <filter-name>:<url-pattern>, according to values from the web.xml.

For instance, the following would remove the ErrorHandler_Default from /*:

ErrorHandler_Default:/*

Mime-Mappings

Set or replace mime-mapping elements.

Examples:

<mime-mapping>
    <extension>svg</extension>
    <mime-type>image/svg+xml</mime-type>
</mime-mapping>

The mime-mapping elements affect the entire Virtual Host and are used use to determine the Content-Type for responses.

nevisProxy always sets a Content-Type header for static resources served by the Virtual Host.

Further, nevisProxy can add a Content-Type header for resources served by applications. To enable this advanced feature assign Generic Application Settings to the application and set the parameter ProxyPolicy to mime-completion.

Generic nevisProxy Instance Settings

You can assign the pattern to a nevisProxy Instance using Additional Settings.

Use to customize the main configuration files of the nevisProxy instance, including:

navajo.xml
bc.properties

To configure logging, use nevisProxy Log Settings instead.

Configuration: navajo.xml

Customize the Navajo servlet container configuration (navajo.xml) using XML constructs described in the nevisProxy Technical Documentation.

The root element <Service> must be provided.

Examples:

Increase number of parallel requests (worker threads):

<Service>
    <Server MaxClients="1000"/>
</Service>

Increase the maximum allowed request body size:

<Service>
    <Server LimitRequestBody="10485760"/>
</Service>

Set a Context attribute for some.domain.com:

<Service>
    <Engine>
        <Host name="some.domain.com">
            <Context additionalStatusCodes="207,210,242,422,423,424,449,456,540,541,543,544,545,456,549,552,560" />
        </Host>
    </Engine>
</Service>

Overrule the allowed HTTP methods for some.domain.com:

<Service>
    <Engine>
        <Host name="some.domain.com">
            <Context allowedMethods="ALL-HTTP" />
        </Host>
    </Engine>
</Service>

Overrule the server aliases for some.domain.com:

<Service>
    <Connector name="some.domain.com" port="*" serverAlias="*.domain.com">
    </Connector>
</Service>

It is possible to use the following placeholders:

${instance.id}: unique ID of the nevisProxy Instance pattern
${instance.name}: name of the nevisProxy instance. For instance, use /var/opt/nevisproxy/${instance.name} to refer to the instance directory.

Limitations:

customizing Navajo elements is not supported
customizing Host (or its child elements) requires name

Configuration: bc.properties

Customize the low-level configuration (bc.properties) using properties described in the nevisProxy Technical Documentation.

For instance, when request validation is enabled this requires a buffer and this buffer has to be big enough to store the entire request.

The following example increases the maximum size of the request buffer to 10 MB:

ch.nevis.navajo.request.BufferSize=10485760

You also may have to increase the maximum allowed request size. See Configuration: navajo.xml for an example.

Note that increased buffer sizes may lead to increased demand of RAM and disk space.

When the required buffer exceeds ch.nevis.navajo.request.MemBufferSize then nevisProxy will buffer to disk instead.

The demand caused by request buffers can be estimated as follows:

RAM: MaxClients * ch.nevis.navajo.request.MemBufferSize
disk: MaxClients * ch.nevis.navajo.request.BufferSize

See Configuration: navajo.xml for a description of MaxClients.

Template Parameters

Define Template Parameters.

Examples:

backend-host: backend.siven.ch

These parameters can be used in:

Configuration: navajo.xml
Configuration: bc.properties

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

HTTP Error Handling

Use the pattern to handle HTTP error codes.

You can use the pattern as an add-on for Virtual Host or any backend application, for example, Web Application, REST Service, or SOAP Service.

Error Pages

Upload HTML error pages, JSON error pages and associated resources here.

Pages must be named like the error code they are used for (e.g. 500.html). You can use the same page for multiple status code (e.g. 401,403,500-599.html).

By default, the error pages are deployed to /errorpages/<name> but you can set a different location via the property Base Path (see Advanced Settings).

In your error pages we recommend to use relative links to include resources. You may also include resources deployed on the virtual host via Hosted Resources.

The following placeholders are supported:

TRANSFER_ID for the unique ID of the request (e.g. c0a80e52-5d04-11ac0500-16906714eee-00000003)
TIMESTAMP to show a timestamp (e.g. Tue, 19 Feb 2019 15:48:02 GMT)

Blocked Status Codes

Hide certain HTTP status code(s) by returning 200 OK instead (by using the reset-status-code action).

By default, the status code is not changed as it can be useful for technical clients.

The response body will still be replaced.

You may also enter:

ranges of status codes (e.g. 500-599),
lists (e.g. 403,500)
combination thereof (e.g. 403,500-599).

Redirect Status Code Mapping

Redirect to a given location instead of rewriting the response body.

Locations can be entered as:

URLs (starting with http:// or https://)
paths (starting with /)

Internal and external locations are supported.

Examples:

404,500-599 -> /some/super/redirect/
403 -> https://www.google.com

Keep Header Status Codes

By default, HTTP headers are dropped when an error code is handled.

This avoids information leakage but can lead to session loss in some cases.

For instance, the nevisProxy session will be lost when all of the following holds:

this pattern is configured to handle code 502.
the application is unreachable (502 is produced).
the nevisProxy session cookie is renegotiated (Set-Cookie header is set).
user refreshes the page after the error page is shown.

To overcome this limitation you may enter 502 here.

Note that we are investigating additional measures and may adapt this property in future releases.

Overwrite Status Codes

Overwrite certain HTTP status code(s) by returning with the defined status code instead.

If for an error code both Blocked Status Code and Overwrite Status Code is configured, the Blocked Status Code will take precedent.

Examples:

404,406-499 -> 401
405 -> 200

Mode

Enable or disable the error handling.

When set to disabled, all settings except Apply only to sub-paths are ignored. Use this setting in combination with Apply only to sub-paths to disable the error handling for some sub-paths only.

Usage examples (valid for Virtual Hosts and backend applications):

Disable the error handling: use an Error Handler pattern with Mode set to disabled and link it to the target pattern via Additional Settings;
Disable the error handling for some sub-paths: use an Error Handler pattern with Mode set to disabled and Apply only to sub-paths set to the paths where no error handling should occur, and link it to the target pattern via Additional Settings;
Define a customised error handling and disable it for some sub-paths: use two Error Handler patterns, one with the custom settings, and one with Mode set to disabled and Apply only to sub-paths set to the paths where no error handling should occur. Link both of them to the target pattern via Additional Settings.

Apply only to sub-paths

Set to apply the error handling on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Content-Type Mode

The Content-Type Mode allows enabling or disabling the error handling depending on the Content-Type header of the backend response. Use this setting in combination with the Content-Types setting.

Choose one of:

None: The error handling settings are applied to all backend responses.
Enabled: The error handling settings are enabled only for the backend responses with a Content-Type header included in the Content-Types setting. Backend responses with other Content-Types are propagated to the client.
Disabled: The error handling settings are disabled for the backend responses with a Content-Type header included in the Content-Types setting. These responses are propagated to the client. The error handling settings are applied to backend responses with other Content-Type headers.

Content-Types

The Content-Types configures the Content-Type headers for which the Content-Type Mode setting is applied. Enter one value per line.

Use this setting in combination with the Content-Type Mode setting.

Base Path

By default, the error pages are deployed to /errorpages/<name> but you can set a different location here.

Keep Security Headers

Configure the name of special response headers which should be kept, regardless of the header action of the matching rule. Useful for keeping the security response headers for the error pages.

Default:

Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy

HTTP Header Customization

Use to add, overwrite, or remove HTTP headers in requests or responses.

You can use the pattern as add-on for Virtual Host or applications, for example, Web Application, REST Service, or SOAP Service.

The following expressions may be used:

${client.ip} - IP address of the caller
${request.id} - unique ID of this request
${request.header.<name>} - value of a request header (only for requests)
${env.<name>} - Apache ENV variables
${auth.<name>} - access to the AUTH scope (only for requests, requires an Authentication Realm and the Filter Phase is to be set to AFTER_AUTHENTICATION or END)

Add / Overwrite Headers

Adds/overwrites HTTP headers in requests.

The syntax is: <header name>:<value>

Examples:

X-Forwarded-For: ${client.ip}
User-ID: ${auth.user.auth.UserId}

Note: change the Filter Phase to replace headers early / late.

Basic Auth User

Enter the basic auth user or an expression of the format <source>:<parameter>.

For the <source> you may use:

AUTH: outargs returned by nevisAuth.
CONST: constant strings.
ENV: Apache environment variables.
PARAM: values from a request body as provided by a ParameterFilter.
HEADER: request headers.

Basic Auth Password

Enter the basic auth password or an expression of the format <source>:<parameter>.

For the <source> you may use:

AUTH: outargs returned by nevisAuth.
CONST: constant strings.
ENV: Apache environment variables.
PARAM: values from a request body as provided by a ParameterFilter.
HEADER: request headers.

Remove Headers

Removes HTTP headers from requests.

The syntax is: <header name>

Examples:

User-Agent

Note: change the Filter Phase to remove headers early / late.

Filter Phase

BEFORE_SANITIATION - manipulate request headers early to hide them from validation and authentication.
AFTER_AUTHENTICATION - the original values are subject to validation and can be accessed in the authentication flow. The header manipulation is applied afterwards to affect the application only.
END - manipulate request headers late, just before the request is forwarded to the application.

Add / Overwrite Headers

Adds/overwrites HTTP headers in responses.

The syntax is: <header name>:<value>

Force browser to use HTTPS only (1 day expiration):

Strict-Transport-Security: max-age=86400

Ensure pages are not cached:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Headers set by Apache (e.g. Server) cannot be overwritten.

Note: change the Filter Phase to set headers early / late.

Remove Headers

Removes HTTP headers from responses.

The syntax is: <header name>

Examples:

X-Content-Type-Options

Headers set by Apache cannot be removed:

Server

Note: change the Filter Phase to remove headers early / late.

Filter Phase

BEFORE_SANITIATION - manipulate request headers late to also cover any headers set by nevisProxy.
AFTER_AUTHENTICATION - default behaviour which should work in most cases.
END - manipulate response headers early hiding them from other nevisProxy filters which operate on responses.

Add / Overwrite Headers Condition

Set to do the header customization only if the given condition applies.

The condition is checked for Add / Overwrite Headers on requests and on responses.

You can use the expressions mentioned above.

Syntax:

${expression} == value

Examples:

${request.header.Content-Type} == application/x-www-form-urlencoded

Apply only to sub-paths

Set to apply the header customization on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table illustrates the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Hosting Service

Use the pattern to host static pages and related resources.

For instance, you can use this pattern to host HTML or a single-page application (SPA).

Further, you can provide CSS, images, and Javascript for error pages uploaded by a HTTP Error Handling pattern.

The pattern generates configuration for the nevisProxy ch::nevis::nevisproxy::servlet::file::FileReaderServlet.

Virtual Host

Assign a Virtual Host which shall serve as entry point.

Frontend Path

The path at which the resources shall be accessible at the frontend. You may use / to deploy root content.

Resources

Upload your resources here.

All files will be deployed in the same directory. Please use standard extensions (e.g. .css, .png, .html, .htm) only.

If you want to use subdirectories please upload a .zip file instead. The content of the .zip file will be unpacked.

Authentication Realm

Optionally assign a realm to protect this application or service.

Rewrite Rules

Rewrite rules for serving files.

This can be useful if a file should be served under a different name, or to map extensions to file names.

Examples:

Source	Destination
`/static/picture`	`/static/picture.jpg`

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

ICAP Scanning

The pattern configures a filter in nevisProxy to forward incoming requests to an ICAP server, for example, ClamAV. A typical use case is virus scanning for file uploads.

ICAP Server URLs

URL(s) of the ICAP server(s). Each URL must have the same path.

Example: icap://my-clamav-server1/avscan

Content-Type Restriction

Optional property to restrict scanning to a certain Content-Type (regular expression is supported here).

Example: application/.*

Apply only to sub-paths

Set to apply the ICAP scanning on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

JWT Access Restriction

Sets up a filter in nevisProxy to verify the JWT of incoming requests.

A request will be allowed to pass through if it contains a valid JWT, in every other case (e.g. failed to verify, expired or token not present), the request will be blocked. Blocked requests are responded to with HTTP error code 403

The pattern can be assigned to applications or an entire Virtual Host using Additional Settings. .

HTTP Header

By default, the JWT will be extracted from the Bearer type Authorization request header:

Authorization: Bearer <token>

Optionally, this behavior can be overwritten by this property by specifying a request header from where the token should be extracted, for example if the token is sent like:

CustomAuthHeader: <token>

Then configure CustomAuthHeader for this property.

Algorithm

The algorithm used to sign and verify the JWT.

Supported algorithms are:

RS256
RS384
RS512 (default)

Public Key

The public key corresponding to the private key which was used to sign the JWT.

Lua HTTP Processing

Sets up a filter in nevisProxy which evaluates a Lua script.

The filter class is ch::nevis::isiweb4::filter::lua::LuaFilter.

Assign this pattern to your applications to perform complex request or response processing tasks.

Lua Script

Upload a Lua script which should be invoked for requests and / or responses. The script has to contain one or multiple of the following Lua functions:

function inputHeader(request, response) - called once per request
function input(request, response, chunk) - called once per request body chunk
function outputHeader(request, response) - called once per response
function output(request, response, chunk) - called once per response body chunk

The uploaded script will be deployed to the nevisProxy host in sub-directory WEB-INF using the name of this pattern for the file name to ensure that the file name is unique.

Here is an example Lua script which replaces sensitive information in response bodies:

local buf = {}
function output(request, response, chunk)
  if chunk ~= nil then
    table.insert(buf, chunk)
    return nil
  else
    return string.gsub(table.concat(buf), "some-sensitive-data", "*****");
  end
end  

The following expressions can be used anywhere within the script:

${name} - sanitized name of this pattern
${host} - name of the Virtual Host directory
${instance} - name of the nevisProxy Instance directory

Lua Libraries

Upload addtional Lua libraries to be used within the Lua Script.

Uploaded files will be deployed to the following directory:

/var/opt/nevisproxy/${instance}/${host}/WEB-INF/lib/${name}/"

The Lua script must patch package.path so that the Lua libraries can be used.

For instance, add the following line at the beginning of the script:

package.path = package.path .. ";/var/opt/nevisproxy/${instance}/${host}/WEB-INF/lib/${name}/?.lua"

Filter Phase

Defines the position of the filter-mapping for this Lua filter. Which position to choose depends on your use case.

For requests filters will be invoked from START to END. For responses filters will be invoked from END to START.

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

Script Parameters

Parameters defined here can be used inside the Lua script.

The name of each parameter must start with param_. This limitation may be lifted in a future release.

The value will be trimmed.

Set this property if you need a different value depending on the inventory.

click var to use a nevisAdmin 4 variable for the entire setting:
- Enter a good name for the variable as the default may be quite verbose.
- Enter some sample values to document the variable in the project.
add the nevisAdmin 4 variable to your inventories:
- See below for an example which illustrates the syntax.

Example inventory variable:

vars:
  example-variable:
    param_example_string: "on"
    param_example_numeric: 60

It is sometimes required to quote values. In the example above, the value on would be converted to a boolean value if it weren't for the double quotes ". When unsure, always put double quotes around the value.

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Maintenance Page

Shows a static maintenance page if the current date and time is within a certain interval.

Technical note: nevisProxy uses system calls to determine the current time in UTC. To check if UTC time is correct, run date -u on the nevisProxy host.

You can assign the pattern using Additional Settings to applications, or an entire Virtual Host.

Show Maintenance Page

Allows to easily enable / disable the maintenance with being forced to set a time window.

Start

Enter the start date and time of the maintenance window.

format: yyyy-mm-dd HH:mm (24 hours)
timezone: UTC (not your local time)
example: 2020-05-20 15:00

End

Enter the end date and time of the maintenance window.

format: yyyy-mm-dd HH:mm (24 hours)
timezone: UTC (not your local time)
example: 2020-05-20 15:00

Maintenance Page

The page must contain two meta-tags which define the maintenance interval and will be patched during generation.

Example:

<head>
  <meta name="maintenance-start" content="${maintenance-start-value}">
  <meta name="maintenance-end" content="${maintenance-end-value}">
</head>

If the date and time on the target host are within this interval, the maintenance page will be shown. See also the introduction help text above.

Status Code

The status code of the response with the maintenance page.

By default, the response is sent with status code 503 for Service Unavailable.

Base Path

Enter the base path under which the maintenance page will be hosted.

You usually don't have to change this configuration, unless the path clashes with any other hosted resources.

By default, /maintenance/ is used.

NGINX Ingress Settings

Assign this pattern to a nevisProxy Instance using Additional Settings.

Use in Kubernetes deployments to add annotations for the NGINX Ingress which runs in front of nevisProxy and terminates incoming connections.

Annotations

Add Kubernetes annotations to customize the behaviour of the NGINX ingress.

Restrict access based on source IP:

nginx.ingress.kubernetes.io/whitelist-source-range: 213.189.148.0/24,173.245.48.0/20,103.21.244.0/22

Increase the maximum allowed request size:

nginx.ingress.kubernetes.io/proxy-body-size: 10m

Please read Annotations - NGINX Ingress Controller for details.

TLS Secrets

Use your own Kubernetes secrets to provide the frontend key store for a Virtual Host.

Syntax is a map of (primary) frontend address of the host to secret name.

www.siven.ch: customsecretname

Secrets must be of type: kubernetes.io/tls. Secrets must be prepared before deployment. They must contain a private key (tls.key), a matching certificate (tls.crt) and should contain the CA chain (ca.crt).

If not set the Nevis operator request certificates from the cluster issuer and generates a secret for each Virtual Host to store the required key material.

Ingress Class Name

Defines the ingressClassName of the generated ingress. It can be used instead of the kubernetes.io/ingress.class annotation to select which ingress controller should handle the generated ingress. For more information see Multiple Ingress controllers.

Client Cert Authentication

Enables client certificate validation in the NGINX Ingress.

Please note that client cert validation cannot be used when the TLS connection is terminated in front of the NGINX Ingress.

Choose between:

enabled: Request a client certificate that must be signed by a certificate that is included in the CA Secret. Failed certificate verification will result in a status code 400 (Bad Request) (unless Error Page is configured`).
optional: Do optional client certificate validation against the CAs. Requests will fail with status code 400 (Bad Request) when a certificate is provided that is not signed by the CA (unless Error Page is configured`). When no or an otherwise invalid certificate is provided, the request does not fail, but instead the request is allowed to pass through.
optional_no_ca: Do optional client certificate validation, but do not fail the request when the client certificate is not signed by the CAs from CA Secret. The secret still has to exist with a valid certificate.
disabled (default): Don't request client certificates and don't do client certificate verification.

This setting is used to generate the following annotation for the NGINX Ingress:

nginx.ingress.kubernetes.io/auth-tls-verify-client

CA Secret

Enter the name of the Kubernetes secret which contains the CA certificate in the key ca.crt. If the secret does not exist it will result in 403 (Forbidden), and with a missing ca.crt key the feature will not be enabled.

Can be created with: kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt

The ca.crt file can contain multiple certificates.

CA Secret Namespace

Enter the namespace of the CA Secret.

Client Cert Validation Depth

The maximum validation depth between the provided client certificate and the CA chain. (default: 1).

You only need to increase this if you only have a parent CA in the CA Secret but want to accept client certificates which have been issued by a child CA.

Error Page

An error page which will be presented in case of certificate validation error.

If you enter a path (e.g. /errorpages/403.html) then that path will be fetched from nevisProxy.

If you enter a URL then the caller is redirected to that URL.

Propagate Client Cert

Indicates if the received certificates should be passed on to nevisProxy in the header ssl-client-cert.

Path

Define a custom path for the generated ingress resource.

Example:

/nevis/

This is an ingress specific setting, the endpoints have to be configured separately to be available under the defined path. When using side-by-side deployment, the path must be the same between the primary and secondary deployment.

TLS Settings

If disabled, the TLS related settings are removed from the generated Ingress resource, which means the default certificate provided by NGINX will be used for the TLS termination.

It's only recommended to use this option, when an additional loadbalancer is used in front of NGINX (e.g. Cloudflare), which already provides a valid certificate.

NodePort Service

If enabled, the generated services for the Ingresses will be of type NodePort. This allows direct connection to the nevisProxy instance.

PEM Key Store

Sets up a key store.

Private key and certificate must be uploaded in PEM format. If the key is encrypted, Private Key Passphrase must be set.

For performance reasons, some issues are reported during deployment only.

The store will be deployed to /var/opt/keys/own/<name>.

Some files are generated and contain entropy (e.g. generation timestamp). To avoid fake changes on subsequent deployments, these files are cached in the nevisAdmin 4 database.

The cache has an expiration of 6 months and will also be invalidated when you change the uploaded key.pem, cert.pem, or the Key Store Passphrase.

Key Store Content

Upload your key material in PEM format.

File name	Description	Required
`key.pem`	private key	yes
`cert.pem`	own certificate	yes
`ca-chain.pem`	CA chain	when providing a HTTPS endpoint

Examples

How to produce the required files depends on your setup. The following examples use openssl.

Generate a private key:

openssl genrsa -des3 -out key.pem 2048

Generate a certificate signing request (CSR):

openssl req -new -key key.pem -out example.csr -subj "/C=CH/O=Example Company/CN=example.com"

If this key store is used to provide a HTTPs endpoint, the common name (CN) should contain the domain.

You can now use the CSR to request a certificate from your CA. For testing a self-signed certificate is often sufficient:

openssl x509 -signkey key.pem -in example.csr -req -days 365 -out cert.pem

Hardening

We recommend to use a variable so that you can use secrets to protect the content. This example references 2 nevisAdmin 4 secrets storing private key and own certificate:

  my-variable: 
    - inv-res-secret://f370a14a36db9f29763e8dc1#key.pem
    - inv-res-secret://147cc54a5629fadac761ec01#cert.pem

When deploying to Kubernetes, the key material may be stored in a Kubernetes secret instead. nevisAdmin 4 does not retrieve Kubernetes secrets during generation and thus all key store files must be provided. This example uses a Kubernetes secret my-secret:

  my-variable: 
    - k8s-secret-file://my-secret:key.pem/
    - k8s-secret-file://my-secret:cert.pem/
    - k8s-secret-file://my-secret:ca-chain.pem/
    - k8s-secret-file://my-secret:keystore.pem/
    - k8s-secret-file://my-secret:keystore.jks/
    - k8s-secret-file://my-secret:keystore.p12/
    - k8s-secret-file://my-secret:keypass/

The additional keystore.* files contain private key, own certificate, and the CA chain. You can use the Java keytool and openssl to produce these files.

The keypass file must be a script which is executable by nvbgroup and prints the passphrase for keystore.* and key.pem to stdout.

nevisAdmin 4 does not notice when the content of the Kubernetes secret changes. Manual interaction (terminating pods) is required in that case.

Private Key Passphrase

Enter the passphrase of the private key.

The passphrase will be used to decrypt the uploaded private key, if it is encrypted.

As the passphrase is considered sensitive information it should not be published with the project. It is therefore required to use a variable and define the value in the inventory (as a secret).

The default value of the variable is not relevant as the key is not loaded during background validation.

Key Store Passphrase

Enter a passphrase.

The passphrase will be used to protect sensitive keystore files (key.pem, keystore.pem, keystore.jks, and keystore.p12) on the target hosts.

If you do not enter any passphrase a passphrase will be generated.

As the passphrase is considered sensitive information it should not be published with the project. It is therefore required to use a variable and set the value in the inventory (as a secret).

Custom Directory Name

Enter a name for the key store directory which is used instead of the pattern name.

This configuration may be used to prevent key stores overwriting each other and is only required in complex setups with multiple projects or inventories.

Custom Root Directory Name

Set to deploy the key store underneath a base directory. The key store will be established at:

/var/opt/keys/own/<base>/<name>

This configuration may be used to prevent key stores overwriting each other and is only required in complex setups with multiple projects or inventories.

PEM Trust Store

Set up a trust store.

The trust store is deployed to /var/opt/keys/trust/<name>.

The trust store will contain the following files:

truststore.pem
truststore.jks - JKS format
truststore.p12 - PKCS12 format
keypass - used by Java-based components to retrieve the password to access the JKS or PKCS12 files

All truststore.* files contain the same certificates.

The JKS and PKCS12 files are created during the first generation, and then stored in a cache backed by the nevisAdmin 4 database.

Trusted Certificates

Upload trusted certificate(s) in PEM format.

If you set a variable, the variable should be a list of secret file references in the inventory. Example:

  my-variable: 
    - inv-res-secret://147cc54a5629fadac761ec01#some-cert.pem
    - inv-res-secret://147cc54a5629fadac761ec01#some-other-cert.pem

Upload files for this variable by clicking Attach files in the drop-down on the inventory screen.

If you are deploying to Kubernetes you may store the trust store content in a Kubernetes secret. You can pick any name for the Kubernetes secret but the keys must be as in the following example:

  my-variable: 
    - k8s-secret-file://dummy-truststore:truststore.pem/
    - k8s-secret-file://dummy-truststore:truststore.jks/
    - k8s-secret-file://dummy-truststore:truststore.p12/
    - k8s-secret-file://dummy-truststore:keypass/

Note that nevisAdmin 4 does not notice when the content of the Kubernetes secret changes. Manual interaction (terminating pods) is required in that case.

Custom Directory Name

Enter a name for the trust store directory which is used instead of the pattern name.

This configuration may be used to prevent trust stores overwriting each other and is only required in complex setups with multiple projects or inventories.

Custom Root Directory Name

Set to deploy the trust store underneath a base directory. The trust store will be established at:

/var/opt/keys/trust/<base>/<name>

This configuration may be used to prevent trust stores overwriting each other and is only required in complex setups with multiple projects or inventories.

REST Service

Set up access to a backend application providing a REST API.

Virtual Hosts

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path(s)

The (base) path of the application.

Examples:

/app/ - defines a base path. Any requests which have a path component starting with /app/ will be sent to this application.
/ - forward all requests to this application. Use this only when there are no other applications or hosted resources.
exact:/app.html - matches requests to /app.html only (query parameters are allowed). Use this for single-page applications which don't require any additional resources.

Note that if the frontend path is different from the path used within Backend Addresses then URL rewriting will be configured to correctly route requests and responses between clients and backends.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky. The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store. The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When backend is selected then nevisProxy uses the host part of the backend address that has been selected. This is the default behaviour and similar to what a browser would do. Therefore, this configuration should work in most cases.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

The configuration is dynamic to support virtual hosts with multiple frontend addresses. Note that this may be less secure. Even though browsers do not allow this clients may sent an arbitrary value for the Host header. It is therefore recommended to test how your application behaves in this case.

Response Rewriting

Use this feature to replace backend hostnames in responses or set to custom to configure complex rewriting use cases.

off disables automatic response rewriting
header enables auto rewrite for response headers (including Set-Cookie header)
complete enables auto rewrite for the entire response (including body)
custom configure Response Rewriting Settings via Additional Settings

CSRF Protection

Cross-Site Request Forgery (CSRF) is an attack that forces an authenticated user to send unwanted requests.

off (default) - no CSRF protection. Recommended for APIs which may be called from other sites.
header-based - GET and HEAD requests are allowed. For other requests Referer and Origin headers must match the Host header.

JSON Validation

Choose between:

enabled - all requests which have a request body must be valid JSON.
log only - similar to enabled but violations are not blocked, only logged.
content-type - validation is performed only when the Content-Type header matches application/json.
disabled

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.
These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.
These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

Please check the nevisProxy technical documentation for supported init-params of the servlet classes ch::nevis::isiweb4::servlet::connector::http::HttpConnectorServlet and ch::nevis::isiweb4::servlet::connector::http::HttpsConnectorServlet.

Request Validation Settings (ModSecurity)

Use the pattern to customize ModSecurity rules. Assign the same pattern to multiple applications to enforce a common configuration.

Do not use rule IDs in the range 500001-500999 as they are reserved for Nevis internal purposes.

Deploying changes to an existing pattern triggers a restart of nevisProxy if the RestartPolicy is set to eager.

Restarting the instance better suits large and highly customised ModSecurity setups.

If you prefer to let nevisProxy reload the ModSecurity configuration on-the-fly, set the RestartPolicy to lazy in the corresponding nevisProxy Instance patterns.

Validation Scope

Sets the scope of request validation:

all: validation will be applied to all requests. This includes authentication.
backend: validation will be applied to requests which are sent to the backend application. The authentication is excluded.
authentication: validation will be applied to requests which are sent to nevisAuth.

Log Only Mode

Allows to use the request validation settings in log only mode.

Paranoia Level

Sets the paranoia level of the ModSecurity OWASP Core Rule Set (CRS). Please see https://coreruleset.org/faq/ for more details.

Paranoia level 1 (PL1) is recommended for beginners and setups with standard security requirements. If you encounter false positives at PL1 OWASP recommends to raise an issue at their Github site.
Paranoia level 2 (PL2) includes SQL, XSS and code injection rules. PL2 is recommended for setups with elevated security requirements and advanced users.
Paranoia level 3 (PL3) enables additional rules and keyword lists to cover less common attacks. Consider PL3 if you are experienced at handling false-positives and for sites with high security requirements.
Paranoia level 4 (PL4) also restricts special characters. PL4 may produce a lot of false positives so please do extensive testing before going into production.

Rule Modifications

Use to add, modify, or remove ModSecurity rules.

Use the Rule recommender to white-list requests. Click the link to open the dialog, then paste log snippets from the nevisProxy navajo.log for requests which have been blocked by ModSecurity.

The log statement must contain the trace group IW4ModsecF and at least the id of the ModSecurity rule which has blocked the request. Example:

2020-07-21 13:00... IW4ModsecF ... Matched "Operator `Rx' with parameter ... against variable `REQUEST_BODY' ... [id "930100"] ... [uri "/nevisidm/admin/"]

The recommender will propose ModSecurity modifications to prevent these requests from being blocked in the future. The modifications will be as specific as possible, including the path, as well as parameters from the request. Please review the recommended modifications and adapt as required.

You may also enter your own rules or modifications directly, skipping the recommender dialog. Check the ModSecurity documentation for further information on how to modify rules.

Both exception modifications or whitelist modifications are allowed in this box. The pattern ensures that the statements are included into the correct place in the generated ModSecurity configuration.

New ModSecurity rules require a rule ID which has to be unique within this pattern and must not used in the rule set. According to ModSecurity documentation the range 1-99999 is reserved for local (internal) use. The rule recommender will use the range 10001-10999.

Whitelist Modifications

Configure whitelist modifications.

As explained in the ModSecurity documentation whitelist modifications are applied before including the core rules.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200 for the path /app/some.html:

SecRule REQUEST_URI "@streq /app/some.html" "pass,nolog,id:1000,ctl:ruleRemoveById=200002"

Exception Modifications

Configure exception modifications.

As explained in the ModSecurity documentation exception modifications are applied after including the core rules.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200:

SecRuleRemoveById 900200

Whitelist body parameter upload for all rules:

SecRuleUpdateTargetByTag ".*" "!ARGS:upload"

Whitelist body parameter upload for rule ID 123:

SecRuleUpdateTargetById 123 !ARGS:upload

Add a new rule which allows the HTTP methods used for WebDAV:

SecAction \
 "id:1,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK'"

Template Parameters

Define parameters which may be used within rules.

Enter a map of key-value pairs.

For instance, a parameter my_param could be defined as follows:

my_param: 900200

These parameters can be used in:

Additional Rules
Whitelist Modifications
Exception Modifications

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

In case a variable my-variable is used this is the format you need to use in the inventory:

my-variable: |
  my_param: 900200

Rule Bundle

Add a Rule Bundle pattern for global or group ModSecurity rule configuration.

Response Rewrite Settings

Use the pattern to replace the hostname of the backend or transform response bodies using regular expressions.

Backend Host Rewriting

off disables automatic response rewriting
header enables auto rewrite of response headers (includes cookies)
complete enables auto rewrite for response headers and body

Response Body Rewriting

Configure response body rewrite rules.

In the first column enter a regular expression. In the second column enter the replacement.

Rules will be applied to each line of the response body.

Response body rewriting can be a complex task and should only be done if there is no other way. Use the browser's network tracing to have a look at the responses to find out what needs to be rewritten.

Examples:

Regex	Replacement	Description
`http://my-backend.intra.siven.ch`	`https://www.siven.ch`	replace an internal host name with the external one
`https?://[^/]+(/.*)`	`$1`	make links relative
`<base href="/">`	`<base href="/app/">`	apps which have a context root of `/` may require a rewrite of the `base` element

For further information see documentation of RewriteFilter in nevisProxy Technical Documentation.

Response Body Content Types

Enter regular expressions to match the Content-Type of responses. If the expression matches, the response body is rewritten.

Rule Bundle (ModSecurity)

Use the pattern to further customize ModSecurity rules.

Assign the same pattern to multiple Request Validation Settings patterns to easily configure and maintain global or group ModSecurity rule configurations.

Do not use rule IDs in the range 500001-500999 as they are reserved for Nevis internal purposes.

Whitelist Modifications

Configure whitelist modifications.

As explained in the ModSecurity documentation whitelist modifications are applied before including the core rules.

If both the Request Validation Settings and the Rule Bundle pattern have whitelist modifications configured, first the Rule Bundle, then the Request Validation Settings whitelists will be applied.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200 for the path /app/some.html:

SecRule REQUEST_URI "@streq /app/some.html" "pass,nolog,id:1000,ctl:ruleRemoveById=200002"

Exception Modifications

Configure exception modifications.

As explained in the ModSecurity documentation exception modifications are applied after including the core rules.

If both the Request Validation Settings and the Rule Bundle pattern have exception modifications configured, first the Request Validation Settings, then the Rule Bundle modifications will be applied.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200:

SecRuleRemoveById 900200

Whitelist body parameter upload for all rules:

SecRuleUpdateTargetByTag ".*" "!ARGS:upload"

Whitelist body parameter upload for rule ID 123:

SecRuleUpdateTargetById 123 !ARGS:upload

Add a new rule which allows the HTTP methods used for WebDAV:

SecAction \
 "id:1,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK'"

SOAP Service

The pattern sets up access to a backend application which provides a SOAP service.

Virtual Hosts

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path

The (base) path of the application.

Examples:

/app/ - defines a base path. Any requests which have a path component starting with /app/ will be sent to this application.
/ - forward all requests to this application. Use this only when there are no other applications or hosted resources.
exact:/app.html - matches requests to /app.html only (query parameters are allowed). Use this for single-page applications which don't require any additional resources.

Note that if the frontend path is different from the path used within Backend Addresses then URL rewriting will be configured to correctly route requests and responses between clients and backends.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky. The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store. The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

Response Rewriting

Use this feature to replace backend hostnames in responses or set to custom to configure complex rewriting use cases.

off disables automatic response rewriting
header enables auto rewrite for response headers (including Set-Cookie header)
complete enables auto rewrite for the entire response (including body)
custom configure Response Rewriting Settings via Additional Settings

SOAP Schema Validation

Optional property to upload a schema.

This feature is experimental and may change in future releases.

You must upload all required XSD schema files. Each XSD schema file must declare 1 target namespace which will be extracted from the first targetNamespace attribute found in the file.

Upload of a WSDL file is optional. If provided, the WSDL must contain a types declaration containing an XSD schema. However, this schema definition can be empty. Here is a minimal example:

   <types>
      <xsd:schema targetNamespace="urn:com.example:echo"
                  elementFormDefault="qualified">
      </xsd:schema>
   </types>

The actual schemas must still be uploaded as separate files.

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.
These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.
These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

Secret Test

#TESTING ONLY - NOT FOR PRODUCTION USE

Used for testing the secret-preserving in Kubernetes deployments.

Assign to a nevisProxy Instance using Additional Settings.

Secret Value(s)

Set a variable and insert secret value(s) in the inventory.

The file /var/opt/nevisproxy/<instanceName>/run/secret_values.txt should then contain:

classic: resolved value(s)
Kubernetes: secret:// reference(s)

Secret File(s)

Set a variable and upload secret file(s) in the inventory.

The file /var/opt/nevisproxy/<instanceName>/run/secret_files.txt should then contain:

classic: resolved value(s)
Kubernetes: inv-res-secret:// reference(s)

Security Response Headers

Configure security headers to be set by nevisProxy on responses. Assign the pattern to an entire Virtual Host or individual applications.

Response Headers

Use this property to add security headers to responses. The syntax is: <header name>:<value>

Example:

Strict-Transport-Security: max-age=63072000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Securosys Key Store

Sets up a Securosys HSM based key store.

The necessary configuration files are deployed into '/etc/primus', while the library itself is shipped with the image.

Certificate with private key is required.

If the certificate does not contain the private key, set the private key separately.

If the private key is encrypted, the passphrase has to be set.

The configuration files are not validated by nevisAdmin 4.

Certificates object label

The certificate objects label on the HSM.

Private Keys object label

The key objects label on the HSM.

Securosys PIN

The PIN for accessing the materials on the HSM.

You must set it as a variable for security reasons.

Securosys configuration files

The two necessary configuration files for accessing the HSM.

'primus.cfg' must contain the configuration settings for connecting to the HSM, and '.secrets.cfg' must contain the credentials to access the materials on HSM.

Keep in mind that the files are not validated, first set up a working configuration, and use the already validated files here.

Static Content Cache

Use this pattern to configure a nevisProxy filter to cache responses returned by backend applications.

This pattern should only be configured for:

locations that emit static insensitive content,
early hint resources,
or backend applications that return Cache-Control headers to prevent storing sensitive responses.

Cached responses are stored in the directory:

/var/opt/nevisproxy/<instance>/run/cache/Cache_<pattern name>/

Stored response bodies can use up to Max Entries Max Entry Size of disk space. Stored response headers generally use less disk space, up to Max Entries ResponseLineSize of the HttpConnectorServlet (default: 4kB) * max number of response headers.

Max Entries

The maximum number of documents to be cached.

Max Entry Size

The maximum size of a document to be cached. Larger documents are never cached.

Max Lifetime

The maximum duration to cache a document.

Max-Age Mode

Choose one of:

override : The cache entry lifetime is set to Max Lifetime.
backend : The cache entry lifetime is copied from the Cache-Control: max-age directive sent by the backend. The Max Lifetime is used as a fallback.

Request Header Mode

Request headers can force an intermediate server to override its cache and answer with the response from the original server.

Choose one of:

comply : Follow the Cache-Control: no-cache directives sent by the client.
ignore : Answer with the stored response even if the client sent a Cache-Control: no-cache directive.

Response Header Mode

Response headers can indicate whether clients and intermediate servers should cache the response.

Choose one of:

comply : Follow the Cache-Control directives sent by the backend.
ignore : Store the response even if the backend sent a Cache-Control directive to prevent caching. Be aware that ignoring Cache-Control directives can lead to sharing sensitive data between clients.

Some clients or content providers try to switch off caching even for mostly static content like images or style sheets. You can limit the load on your content providers as follows:

Add a Static Content Cache pattern and link it to your application via Additional Settings;
Configure Apply only to sub-paths to store responses on paths that only emit static content, for instance images;
Set Response Header Mode to ignore;
Configure the Max Lifetime of stored responses.

Apply only to sub-paths

Set to apply the cache handling on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

TCP Settings

Use the pattern to customize TCP connections to backend applications. Assign the same pattern to multiple applications to enforce a common standard.

`DNS Caching`	`Keep-Alive`	Description
`disabled`	`disabled`	Always works but has the biggest impact on latency.
`disabled`	`enabled`	DNS may resolve a new IP but Keep-Alive is enabled so some requests may still be routed to the previous IP. This may be acceptable if the previous IP is still reachable and could even be required in case sessions are bound to the TCP connection.
`enabled`	`disabled`	The resolved IPs are stable but for each request a new TCP connection is established.
`enabled`	`enabled`	The resolved IPs are stable and connections are reused.

Connect Timeout

Timeout for establishing the TCP connection.

Request Timeout

Timeout waiting for the response.

DNS Caching

Cache DNS lookup results.

default: does not generate any configuration so the default nevisProxy behaviour will apply.
disabled: the configured backend host names are resolved for each request. Use when IP addresses may change.
enabled: host names are resolved only once. Use when the IP addresses are stable.

DNS Caching Timeout

If DNS Caching is set to true, DNS Caching Timeout specifies how long the DNS info should be cached (in seconds) before getting again the IP address.

Keep-Alive

Pool TCP connections to backends for later reuse.

default: does not generate any configuration so the default nevisProxy behaviour will apply.
disabled: the TCP connection is closed after use, and a new connection will be established for the next request.
enabled: the TCP connection is put in a pool so that it can be reused by future requests. Limiting factors are Connection Pool Size, By Client, Inactive Interval, and Lifetime.

Connection Pool Size

Number of pooled TCP connections. A TCP connection is only put in the pool if the size of the pool does not exceed the configured size. By leaving this field empty, you will be using the nevisProxy default value.

By Client

Forces TCP connections to only be reused for the same client. A call from a different client will use another TCP connection from the connection pool. If set to default, the nevisProxy default will be used.

Inactive Interval

Inactivity duration allowed before a TCP connection is dropped. By leaving this field empty, you will be using the nevisProxy default value.

Lifetime

The absolute lifetime of a TCP connection. This should be configured to less than the connection lifetime allowed by the firewall between nevisProxy and the content providers. By leaving this field empty, you will be using the nevisProxy default value.

TLS Settings

Use the add-on to customize TLS/SSL settings for nevisProxy.

Assign to a Virtual Host to customize settings for incoming connections.

You can customize connections to backends by assigning the pattern to your service (Web Application, REST Application, SOAP Application) using Additional Settings.

Protocols

The value configured here will be applied as SSLProtocol.

Check the Apache Documentation for details.

If empty and when this pattern is assigned to a Virtual Host the following value is used:

-all +TLSv1.2 -TLSv1.3

If empty and when this pattern is assigned to an application, default SSLProtocol from nevisProxy are applied. Check the nevisProxy Technical Documentation for details.

Cipher Suite

The value configured here will be applied as SSLCipherSuite.

Check the Apache Documentation for details.

If empty and when this pattern is assigned to a Virtual Host the following value is used:

ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256

If empty and when this pattern is assigned to an application, default SSLCipherSuites from nevisProxy are applied. Check the nevisProxy Technical Documentation for details.

SSL Options

The value configured here will be applied as SSLOptions.

It should only have value when assigned to a Virtual Host pattern.

Check the Apache Documentation for details.

If empty and when this pattern is assigned to a Virtual Host the following value is used:

+OptRenegotiate +StdEnvVars +ExportCertData

Testing Service

#TESTING ONLY - NOT FOR PRODUCTION USE

Used for testing. This pseudo service does not configure anything but allows tweaking the validation, generation, planning and deployment processes.

On validation

Use for testing only.

On generation

Use for testing only.

On planning

Use for testing only.

On deployment

Use for testing only.

URL Handling

Use the pattern to:

redirect requests (returning status code 302 with a Location header)
rewrite the path of a request, that is, forward.

Query parameters are always considered.

You can use the pattern as an add-on for Virtual Host or any application, for example, Web Application, REST Service, SOAP Service.

Redirect and forward rules have the following format:

<source> -> <destination>

The pattern generates a nevisProxy RewriteFilter named URLHandler_<name>. If either source or destination starts with http:// or https:// then the init-param RequestURL is set, otherwise RequestURI is used.

Redirect Rules

Terminate requests by returning a HTTP Redirect (status code 302).

In the first column (source) enter the current location. In the second column enter the destination to redirect to.

The following formats are supported:

URL
absolute path (starting with /)
relative path

Regular expressions are supported in the source, and group extractions may be used in the destination.

Absolute paths always point to the host, while relative paths are appended to the path of the assigned host (/) or application.

The order of the rules matters. Only the first matching rule is applied.

Examples:

Source	Destination	Description
`http://(.*)`	`https://$1`	redirects plain HTTP to HTTPs, preserving the request path
`(.*)?lang=de`	`de/$1`	put query parameter into request path
`/nevis.html`	`https://www.nevis.ch`	redirect requests to a certain HTML page to a different domain

Forward Rules

Rewrite the path of HTTP requests.

Rewrites are done using a forward which means that they are transparent for the caller.

The format is the same as in Redirect Rules.

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behaviour:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Filter Phase

The phase when this filter should be applied depends on your use case.

use START when the redirect / rewrite should be done as early as possible.
use AFTER_SANITATION to redirect / rewrite after validating the request.
use AFTER_AUTHENTICATION to redirect / rewrite after authentication.

Unauthenticated Realm

Public applications typically do not have an Authentication Realm assigned. However, there are some cases where you have to assign this pattern.

1) You have a public and an authenticated application with overlapping Frontend Paths.

Assign this pattern to your public application and select disabled in the Session Tracking drop-down.

This expresses that no sessions are expected.

This pattern ensures that session tracking and authentication are excluded from all frontend paths of your public application.

2) You are using nevisProxy features which need a session.

For instance, the Cookie Customization pattern needs a nevisProxy session to store cookies when you configure Shared Protected Cookies or Protected Cookies.

In this case, set the Session Tracking drop-down to COOKIE.

In general, we do not recommended to have a proxy session for public applications, as it can lead to a high sessions count. Thus, we recommend to set the Session Timeout as low as possible.

Session Tracking

Choose between:

COOKIE: issue a session cookie.
AUTHORIZATION_HEADER: track the session based on the value of the Authorization header.

By default, the session cookie will be called Session_<pattern-name>

Set this optional property to use a different name (e.g. ProxySession).

If the same name is configured for multiple realms on the same host then the sessions will be cleaned up together when the first session expires.

In February 2020 Chrome 80 has been released which treats cookies without SameSite flag as Lax.

This change can break cross-domain use cases (e.g. SAML).

Thus, it is recommended to select None here.

If None is selected, and you have to support older browsers also check Cookie Same Site Relaxation.

If you do not expect any requests from other domains, you may also go for Lax or Strict as this increases security.

Some older browsers treat cookies with SameSite=None as Strict.

See this example bug report for Safari:

Bug 198181 - Cookies with SameSite=None or SameSite=invalid treated as Strict

Enable this feature to map a filter to the root location /* which evaluates the User-Agent request header to remove SameSite=None for browsers which are known to be affected.

Session Validation

A newline separated list of rules declaring attributes that must not change in the same session. A rule has the following syntax:

ENV|CONST|PARAM|HEADER:<name of the attribute>:block|invalidate

block: the request will be blocked and 403 (Forbidden) will be returned
invalidate: the session will be invalidated and a new one will be created

nevisProxy Conditions are supported. See nevisProxy reference guide for details.

For instance, use the following configuration to terminate the session if the source IP changes:

ENV:REMOTE_ADDR:invalidate

Session Timeout

Defines the idle timeout of a nevisProxy session.

A nevisProxy session will be created only if required (e.g. to store application cookies).

Please set the timeout as low as possible to not increase the risk of session exhaustion attacks.

Nevis recommends not to exceed the default. A high session timeout in Unauthenticated Realm is strongly discouraged as it opens the door to DoS attacks: nevisProxy can be brought down by creating millions of sessions with simple GET requests.

Max Session Lifetime

Define the maximum lifetime of a nevisProxy session. The session will be removed after that time even if active.

Update Session Timestamp Interval

Sets the minimum time interval between two updates of the session timestamp.

If the parameter is set to "0", the system will update the session timestamp each time a request accesses a session.

The Initial Session Timeout is used as Update Session Timestamp Interval if it is shorter than the duration configured here.

Virtual Host

The pattern represents a virtual host of a nevisProxy Instance.

A virtual host provides access to applications: applications are reachable on their Frontend Path(s) on all of the Frontend Addresses of this virtual host.

To assign an application, add a Web Application, REST Service, or SOAP Service pattern, and reference this virtual host.

The pattern supports IP-based, port-based, and name-based virtual hosting. Name-based virtual hosting with HTTPs requires server name indication (SNI).

Basic Usage

Define the addresses under which the host is reachable using Frontend Addresses.

The addresses must be fully qualified, they have to they have to start with http:// or https://.

You can define multiple addresses and you can mix HTTP and HTTPs, as long as you do not use more than one port for each protocol.

Examples:

Frontend Addresses: https://www.siven.ch
Frontend Addresses: https://www.siven.ch http://www.siven.ch http://partners.siven.ch
Frontend Addresses: https://www.siven.ch:8443 http://www.siven.ch:8080 http://partners.siven.ch:8080

The pattern is required for all nevisProxy instances, even those having only one frontend address.

Listening on Internal Addresses

Set Bind Addresses to make the host listen on addresses (DNS host names or IPs and ports) other than the configured frontend addresses.

Supporting both HTTPS and HTTP

To expose a host using HTTP and HTTPS, specify the two schemas in Frontend Addresses:

Frontend Addresses: https://www.siven.ch http://www.siven.ch

Name-based Virtual Hosts

With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address.

To configure name-based virtual hosts, set the Frontend Addresses to the virtual name(s) of the host and set the Bind Addresses to the physical addresses of the host.

For example, to set up a two virtual hosts to be reachable on the same internal address IP and port but with different public host names, configure as follows:

Frontend Addresses: https://www.siven.ch http://www.siven.ch
Bind Addresses: https://0.0.0.0:8443 http://0.0.0.0:8080

Then configure another virtual host to use the same Bind Addresses but different Frontend Addresses:

Frontend Addresses: https://partners.siven.ch http://partners.siven.ch
Bind Addresses: https://0.0.0.0:8443 http://0.0.0.0:8080

Note: name-based virtual hosts using HTTPS requires all clients supporting SNI.

nevisProxy

Assign the nevisProxy Instance this virtual host should be assigned to.

Frontend Addresses

Define addresses (HTTPS or HTTP) at which this host will be reachable from a client perspective.

The basic syntax is:

<scheme>://<hostname>
<scheme>://<hostname>:<port>

A variable may be used to define different addresses for different stages (e.g. DEV, TEST, PROD).

The expression ${deployment_host} may be used when the name of the target host is required.

Examples:

http://www.siven.ch
https://www.siven.ch
http://${deployment_host}:8080

The port will, if omitted, default to 443 for HTTPS and to 80 for HTTP.

You also have to set Bind Addresses if:

the addresses cannot be resolved on the target host(s)
the port should be opened on different addresses / IPs, or ports.
multiple virtual hosts should listen on the same endpoint (name-based virtual hosts).

Bind Addresses

The physical address(es) to bind on, with scheme HTTP or HTTPS and ports.

Must be set when multiple virtual hosts should listen on the same endpoint (name-based virtual hosts).

If not set the Frontend Addresses will be used to bind.

The host name must resolve to an IP which is bound to a network interface.

You can also use 0.0.0.0 for the host name to listen on all network interfaces.

Examples:

https://www.siven.ch:8443
http://localhost:8080
https://192.168.1.1:443
http://0.0.0.0:80

Frontend Key Store

A key store is required when HTTPS is used for any of the Frontend Addresses.

If not set a key store will be set up automatically. This requires automatic key management to be enabled.

The key store should provide a certificate which is valid for all frontend addresses, e.g. because SANs (subject alternative names) are set or because it is a wildcard certificate.

In a Kubernetes deployment the TLS connection is terminated by an NGINX Ingress in front of nevisProxy and this configuration does not apply. The required key material will be generated automatically.

You can configure the NGINX Ingress to use key material from a Kubernetes secret as follows:

assign a NGINX Ingress Settings pattern to your nevisProxy Instance via Additional Settings
in the NGINX Ingress Settings pattern configure TLS Secrets.

Frontend Trust Store

Set a trust store to validate client certificates for incoming TLS connections.

The trust store may contain an arbitrary number of CA certificates. Client certificates must be signed by those CAs.

Caution: client certificate authentication is not enabled automatically. As of release 4.3.1 there are no dedicated patterns but client cert authentication can be enforced for the entire host (e.g. using Generic nevisProxy Settings) or in the authentication process (X509State and IdentityCreationFilter init-param ClientCert).

Frontend TLS Settings

Choose between:

recommended: for high security, apply the recommended settings for SSLProtocol and SSLCipherSuite. The settings may change in future releases. Check the nevisProxy Technical Documentation for details. This works with modern browsers and clients. Current recommended values are:

sslProtocol = '-all +TLSv1.2 -TLSv1.3'
sslCipherSuite = 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256'

compatible: the SSLProtocol and SSLCipherSuite will be based on Mozilla's SSL configuration for Apache server. These settings provide high compatibility with older browsers and clients. Current compatible values are:

sslProtocol = '-all +TLSv1.1 +TLSv1.2 -TLSv1.3'
sslCipherSuite = 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA'

custom: assign a TLS Settings pattern via Additional Settings to apply your own configuration. If not provided, SSLProtocol and SSLCipherSuite follow the recommended settings.

Root URL Redirect

Set to redirect requests for the root path (/) to an absolute path or a full URL.

Hosted Resources

Upload a ZIP to provide your own resources.

By default, the following resources are provided:

/favicon.ico
/index.html
/errorpages/403.html
/errorpages/404.html
/errorpages/500.html
/errorpages/502.html
/resources/logo.png
/resources/bootstrap.min.css
/resources/default.css

This host has its own error handler (ErrorHandler_Default) which is assigned to the root location (/*). The error handler will replace the response body when an HTTP error code occurs and an error page is available.

Error pages for HTML must be added the sub-directory errorpages and named <code>.html.

The error code is returned to the caller as this may be required by some REST clients.

If you do not want this you can assign a specific HTTP Error Handling pattern to this Virtual Host or to applications via Additional Settings.

The servlet hosting the above resources is usually mapped to the root location (/*), however if there is already another servlet mapped there, the servlet is mapped to individual root files and directories.

If there is an undesired mapping, it can be deleted by removing the given resource from the zip file.

Session Store

Assign a nevisProxy Remote / Hybrid Session Store pattern here if you want to store sessions in a remote session store.

A remote session store must be used when the nevisProxy instance is deployed with redundancy and there is no sticky load balancer in front.

Unsecure Connection

This property defines how to handle requests received via plain HTTP. Choose between:

redirect If a request is received via plain HTTP the client is redirect to the HTTPS endpoint (requires a Frontend Address with scheme https://).
allow the request is processed.

Require Client Certificate

Choose from:

disabled (default): No client certificate is required to connect to this virtual host.
enabled: Clients must present a client certificate signed by a CA. The CA which has issued the client certificate must be part of the Frontend Truststore. When no client certificate is presented or the certificate is not valid the connection will be aborted. As no error page is rendered this feature is not recommended when there are browser-based clients. Use for technical clients only.

Qos Configuration (mod_qos)

nevisProxy uses the mod_qos module to ensure quality of service (QoS). Choose between:

off: the module is disabled on this virtual host.
standard: provides a default configuration which protects against common denial of service (DoS) attacks.
custom: configure Generic mod_qos Configuration via Additional Settings.

Allowed HTTP Methods

Define the HTTP methods which are allowed on this virtual host.

The setting default (complete) is quite relaxed as it enables most methods. Only two are excluded:

CONNECT: no use case of nevisProxy.
TRACE: may be useful for debugging but can be a security vulnerability.

If you do not have any applications using WebDav select basic.

The allowed HTTP methods can be restricted further in application patterns.

For more fine-grained control you may use Generic nevisProxy Instance Settings to overwrite the allowedMethods (see pattern help for details).

OWASP ModSecurity CRS Version

Allows to select the OWASP ModSecurity CRS version.

Available options are:

3.3.5: default and recommended setup, uses Anomaly Scoring Mode, requires nevisProxy 5.4.0 or newer
3.3.2: previous version of CRS, uses Anomaly Scoring Mode, kept for easier migration
3.0.2: older version of CRS, uses Self-Contained Mode, kept for easier migration
custom: allows to upload a custom rule set. See the ModSecurity Rule Set option for more information.

The following HTTP methods are allowed by default when selecting any of the included versions: CHECKOUT, COPY, DELETE, GET, HEAD, LOCK, MERGE, MKACTIVITY, MKCOL, MOVE, OPTIONS, POST, PROPFIND, PROPPATCH, PATCH, POST, PUT, TRACE, UNLOCK

ModSecurity Rule Set

Upload a .zip file containing configuration for ModSecurity. The .zip must contain a configuration file called modsecurity.conf.

The modsecurity.conf file will be included for all Web Application patterns which have Request Validation set to standard, custom, or log only.

Click Download Default Configuration to download the default configuration which is applied when no .zip is uploaded. There is one link per provided OWASP ModSecurity CRS Version.

Security Response Headers

Configure security response headers:

off does not set any security headers
basic sets default headers on responses. That is:
- Strict-Transport-Security: max-age=63072000
- X-Content-Type-Options: nosniff
- Referrer-Policy: strict-origin-when-cross-origin
custom configure Security Response Headers via Additional Settings

Session Store Resource

Exposes the REST interface of the session store servlet on the given path. For security reasons, only DELETE requests are allowed and assigning an access restriction pattern is recommended.

Before setting this parameter, make sure that there will be an actual session store servlet.

Session Store Access Restriction

Assign an access restriction patterns to prevent unauthorized access to the REST interface of the session resource.

HTTP/2 Support

Enables the support of HTTP/2 for incoming connections on this nevisProxy virtual host.

Note that mod_qos has limited support for HTTP/2, therefore only request level directives are supported if enabled.

Early Hints

Enables the HTTP/2 feature of early hints.

Configures early hints with the Apache directive H2PushResource

It will send out a "103 Early Hints" response to a client as soon as the server starts processing the request.

Static Cache

Add a Static Content Cache pattern to the Virtual Host.

Use it to cache the early hint resources as static content in nevisProxy to further increase the performance. Map the Static Content Cache pattern to the same paths as the Early Hints parameter.

Encoded Slashes

Choose from:

allowed: URLs containing encoded slashes are allowed and will not be decoded (AllowEncodedSlashes NoDecode). Also URLEncoding will be set to false for each HttpsConnectorServlet.
forbidden: URLs containing encoded slashes will be denied and a 404 will be returned. This is the default behaviour of Apache.

Additional HTTP Status Codes

Allow non-standard HTTP status codes.

The configuration of additional status codes is required, for example, when using WebDav (HTTP status code 207 is used by WebDav).

Additional Settings

Assign add-on patterns to customize the behaviour of this virtual host.

Web Application

Using the pattern, you can set up access to a web application on a nevisProxy Virtual Host.

Virtual Hosts

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path(s)

Enter the path(s) where this application shall be accessible on the assigned Virtual Host.

It is recommended to set only 1 path. Examples:

/app/ - defines a base path. Requests which have a path component starting with /app/ will be sent to this application. This is the most common scenario.
/ - may be used when there are no other applications. The Hosted Resources of the Virtual Host are still accessible but all other requests will be sent to the backend application.
exact:/app.html - matches requests to /app.html only (query parameters may also be added). Use for single-page applications which don't require any additional resources.
prefix:/app - matches requests which have a path component starting with /app. Examples: /application, /app/index.html, /app2/secure/

In case the frontend path is different from the path used within Backend Addresses then the path will be rewritten in incoming requests.

Note that for response by default only the headers are rewritten. See Response Rewriting for further options.

Note that when you enter multiple paths there are some limitations:

Filters created by a Realm or Additional Settings will be mapped to all paths.
The paths have to be the same on the backend server.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky. The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store. The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

Response Rewriting

Enable to replace backend host names in responses or set to custom for complex rewriting use cases.

off - disables automatic response rewriting
header - enables auto rewrite for response headers (including Set-Cookie header)
complete - enables auto rewrite for the entire response (including body)
custom - requires assignment of Response Rewriting Settings via Additional Settings

CSRF Protection

Cross-Site Request Forgery (CSRF) is an attack to force an authenticated user to send unwanted requests.

off (default) - no CSRF protection. Recommended for applications which may be called from other sites.
header-based - GET and HEAD requests are allowed (assumption: these methods must not manipulate server-side state). For other requests the Referer and Origin headers must match the Host header.

Request Validation (ModSecurity)

off - no request validation
standard - uses ModSecurity OWASP Core Rule Set (CRS) with default paranoia level 1 - Basic security
custom - configure Request Validation Settings via Additional Settings
log only - uses standard in log only mode

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.
These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.
These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

WebSocket Support for Application

The pattern enables WebSocket support for backend applications. Assign to your application using Additional Settings.

The pattern generates two additional servlets:

a WebSocketServlet named Connector_<application>_WS
a ServletMappingServlet which selects Connector_<application>_WS when the HTTP Header Upgrade contains the value websocket

The TCP connection is reserved for each WebSocket connection.

Custom Parameters

Add custom init-param for the WebSocket servlet.

Please check the nevisProxy technical documentation for supported init-params of the servlet class ch::nevis::isiweb4::servlet::connector::websocket::WebSocketServlet.

nevisKeybox Store

Apply the pattern to use existing key material from nevisKeybox. You can assign the pattern where-ever a key store or trust store is required.

The nevisKeybox instance is to be named default.

The pattern does not deploy any key material. This is the intended behavior and not a limitation.

To deploy a private key and certificate you may use PEM Key Store instead, for deploying trusted certificates use PEM Trust Store instead.

Slot

A Slot is a directory of a nevisKeybox instance.

By default, nevisKeybox is located at /var/opt/neviskeybox/default/. If missing please run the following command on the affected target server(s):

neviskeybox handover

A Slot may contain:

an arbitrary number of key stores (identified by label)
up to 1 trust store.

Label

Setting the Label is required if this pattern is used as a key store provider.

This pattern relies on the standard nevisKeybox mechanism for retrieving the passphrase of the private key.

Run the following commands on all target server(s) to ensure the passphrase can be retrieved:

neviskeybox passwd -slot <slot> -label <label> -keep

neviskeybox access -slot <slot> -label <label> -group nvbgroup

The last command will generate a shell script /var/opt/neviskeybox/default/<slot>/<label>_keypass which can be invoked by NEVIS components to retrieve the passphrase.

Due to a limitation in some NEVIS components keypass files which contain base64 encoded passphrases are not supported yet. Replace any of the following content with a simple echo returning the passphrase directly.

echo "cGFzc3dvcmQ=" | openssl base64 -d

nevisKeybox may also be integrated with nevisCred to store the passphrase in a secure place. In this case the shell script will not contain the passphrase but a call of nevisCred.

Validation

Allows to the validation in case the nevisKeybox is deployed by this project (e.g. using Generic Deployment).

nevisProxy Instance

The pattern represents a nevisProxy instance.

Create at least one Virtual Host pattern and assign this pattern.

Hint for pattern renaming

When the 'Instance Name' property is not filled, this pattern uses the pattern's name as instance directory at the target host.

To rename this pattern, do the following:

Rename the pattern in the GUI.
Rename the instance directory and associated systemd files on the deployment hosts.
Deploy.

In case step 2 is omitted, the old instance is shut down during deployment.

For more information, see User Guide / Configuration Projects / Working with Patterns.

Instance Name

Enter the instance name.

If not set, the pattern name will be used as the instance name.

When deploying to Kubernetes, this setting will be ignored and the instance name will be default.

Log Settings

Add logging configuration for nevisProxy.

Apache SSL Cache

Configures the Apache storage type of the global/inter-process SSL Session Cache.

Uses the default high-performance cyclic buffer inside a shared memory segment in RAM.

This is the recommended and default SSL Cache for nevisProxy, which is required to enable SSL session resumption.

For more information, see the official Apache documentation about the SLLSessionCache directive.

SSL Cache Size

Configures the approximate size of the Apache SSL Cache.

The minimum allowed value is 1 KB. The maximum is 100 MB.

If not, the default from Apache is used.

SSL Cache Timeout

Configures the number of seconds before an SSL session expires in the SSL Session Cache.

For more information, see the documentation of the SSLSessionCacheTimeout directive.

Instance Rename Detection

During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.

If instance rename is detected the current instance is stopped.

This check should be disabled if multiple environments are simulated on the same server.

This setting is relevant for classic VM deployment only.

Start Inactive

In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.

This setting defines if the instance should also be started when it is down.

This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.

Liveness Delay

Time to wait before checking Kubernetes liveness.

You may have to increase this value if start of the nevisProxy service fails because of a failing liveness check.

Sets initialDelaySeconds of the Kubernetes liveness probe.

Readiness Delay

Time to wait before checking Kubernetes readiness.

You may have to increase this value if start of the nevisProxy service fails because of a failing readiness check.

Sets initialDelaySeconds of the Kubernetes readiness probe.

Probe Periodicity

Configures how often perform the readiness and liveness probe.

Sets periodSeconds of the Kubernetes readiness probe.

Check Minimum Version

Select enabled to perform basic version checks.

In classic VM deployment we run a command on each target host, to check which version of the component is installed.

In Kubernetes deployment we check the version of the docker image instead.

This check can be disabled for testing purposes.

Restart Policy

Determines the instance behaviour when a configuration change triggers an optional restart.

Select one of:

eager - the instance will restart when deploying the new configuration;
lazy - the instance will skip optional restarts.

Restart Condition

Enter an expression to prevent nevisProxy from being restarted even if the configuration changes.

nevisProxy will only be restarted if the exit status is 0.

The expression must always terminate.

In Kubernetes deployment this setting is ignored.

A use case where this is required is when nevisProxy is deployed to multiple hosts and listens on a shared IP which is bound on 1 host only.

ip address show dev eth1 | grep -q "172.29.0.5"

Example for multiple shared IPs:

ip address show dev eth1 | egrep -q "172.29.0.5|172.29.0.6"

Recommendations:

Run the command manually on the target host to be sure that it works for you.
You can check the exit status of the last command by running echo $?

Password Getter

Choose between:

recommended: uses nevisadmin for Kubernetes and classic deployments. The recommended value may change in future releases.
nevisadmin: uses a script deployed by nevisAdmin. Does not work for PKCS11.
nevisproxy: uses /opt/nevisproxy/bin/keystorepwget to lookup passwords for encrypted key material. Requires nevisProxy version 4.4 or later. Does not support lookup of the password for the key.pem of PEM Key Store.
neviskeybox: uses /opt/neviskeybox/bin/keystorepwget to lookup passwords for encrypted key material. nevisKeybox must be installed on the target system. Does not work in Kubernetes deployments.

Crash Recovery Strategy

Defines how to handle process crashes.

Choose between:

recommended: uses recover for classic and kill for Kubernetes deployments;
recover: the child process is recovered by the parent process;
block: every request will be blocked by 503 Service Unavailable status code;
kill: the whole nevisproxy process (including the parent process) is killed. This works only if the owner of the child process has the permissions to kill the parent process (for example in some Kubernetes setups). Otherwise, this option works like block.

Note for block and kill: these actions take place if at least one request was being processed when the crash occurred. These features can be useful for liveness test in Kubernetes setups, so the given pod can be terminated normally in case of a crash. Using one of these options in a classic setup requires to restart nevisProxy with an external tool after a crash.

Default Virtual Host

The default virtual host of this nevisProxy instance.

The default will be used for requests without a Host header or if there is no host with a corresponding frontend address.

Additional Settings

Assign add-on patterns to customize the behaviour of this nevisProxy instance.

nevisProxy Log Settings

Use to configure logging for nevisProxy. Assign to your nevisProxy Instance via Log Settings.

Default Log Level

Sets the base log level of nevisProxy.

The level will be applied to BC.Tracer.ThresholdBase as follows:

ERROR: 3
NOTICE: 5
INFO: 6
DEBUG: 7
DEBUG_HIGH: 9
TRACE: 10

Note that if you only change log levels nevisProxy won't be restarted during deployment. The new configuration will be activated within 60 seconds.

Log Levels

Configure log levels.

Overrules the Log Level property.

See nevisProxy Reference Guide Operation and Administration / Debugging for possible trace groups.

Enter the suffix of the name of the trace group and a log level.

Supported log levels are:

ERROR
NOTICE
INFO
DEBUG
DEBUG_HIGH
TRACE

Do not enter numbers for the log level as nevisAdmin4 will calculate them automatically.

The default configuration is:

NavajoOp = INFO 
NProxyOp = INFO

Debug startup:

NavajoStart = INFO

Debug HTTP Header Customization:

IW4HdrDlgFlt = DEBUG

Conditional Log Levels

Can be used to configure log levels based on conditions.

Example:

Condition:REMOTE_ADDR:CIDR/10.4.12.0/24/
Pragma: block-begin
BC.Tracer.DebugProfile.NavajoOp=4
BC.Tracer.DebugProfile.IsiwebOp=4
BC.Tracer.DebugProfile.IW4IdentCreaFlt=4
Pragma: block-end

Rotation Type

Defines how to handle log retention for the access, apache and navajo log files. Rotation is possible based on:

file size
time interval

Max Files

Maximum number of backup files to keep in addition to the current log file.

Max File Size

Maximum allowed file size (in bytes) before rolling over.

Suffixes "KB", "MB" and "GB" are allowed. 10KB = 10240 bytes, etc.

If not set the following defaults will be used:

apache.log: 1MB
other logs: 10MB

Rotation Interval

Interval on which a logfile will be rotated.

Compress Rotated Log

Define rotated files will be compress or not

Compression Application

You may specify a program or script which shall be used to compress rotated files.

Example:

/usr/bin/gzip

Log Targets

Select if only log file should be used or if statements should also be forwarded to syslog.

Event Log

Enable event logging capability of nevisProxy.

Event logs are not forwarded to syslog.

Server LogFormat

Allows the configuration of the LogFormat Apache directive in the navajo.xml file.

For more information, check the official Apache documentation of the directive.

nevisProxy Observability Settings

Sets up observability with OpenTelemetry for nevisProxy.

The OpenTelemetry settings are applied to each Virtual Host of the instance.

Trace Mode

Choose one of:

enabled: enable the trace feature of OpenTelemetry
disabled: disable the trace feature of OpenTelemetry

Trace Exporter Address

Enter the target URL (host:port) of the backend services to which the exporter is going to send spans. The /v1/traces path is automatically attached to it.

Metrics Mode

Choose one of:

enabled: enable the metrics feature of OpenTelemetry
disabled: disable the metrics feature of OpenTelemetry

Metrics Exporter Address

Enter the target URL (host:port) of the backend services to which the exporter is going to send metrics. The /v1/metrics path is automatically attached to it.

Trace Context Extraction

Choose one of:

enabled: if present, extract the trace context from the HTTP request header and set it as parent for the current span
disabled: ignore the trace context from the HTTP request header

Trace Context Injection

Choose one of:

enabled: inject the current context (span ID, trace ID, etc) as a HTTP header to the request
disabled: do not inject the current context in the request

Trace Resource Service Name

Configure the service.name key-value pair resource attribute.

Metrics Timeout

Configures a timeout for the metrics observable callback.

Metrics Interval

Interval of the metrics reader to initiate metrics collection.

nevisProxy Remote / Hybrid Session Store

Configures nevisProxy to use a MariaDB database for storing sessions. Assign to Virtual Host as Session Store.

Use this pattern when in-memory session storage cannot be used. Note that in-memory sessions may be sufficient in the following cases:

classic (VM) deployment: only 1 line or load balancing towards proxy is session sticky
Kubernetes deployment: only 1 pod (not recommended)

The session store is used only when there are filters or servlet which require a session. In particular, this is the case when you assign an Authentication Realm to applications.

You can choose between remote, or hybrid session store. An overview about different types can be found here. The hybrid session store can be used in classic deployment only.

When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.

In classic VM deployment you have to create the database including tables. Setup instructions can be found in the nevisProxy Technical Documentation. For details see Configuration of MariaDB-based remote session store.

Database Type

Choose between MariaDB and Oracle and PostgresSQL.

We recommend to use MariaDB as it is supported by all Nevis components that have a database.

Note: PostgresSQL database is only experimental configuration.

Database Host

Enter the host name of the database service.

The database service must be up when you deploy.

In a classic deployment the Database User and Database Password is used to connect.

In Kubernetes deployment a connection user and password will be generated and the Root Credential will be used to set up the database schema.

Database Name

Here you can change the name of the database.

The database name only needs to be changed when the database service contains multiple databases.

Root Credential

Enter the name of a Kubernetes secret which contains the user and password of a database root account.

Required in Kubernetes deployment when Advanced Settings / Database Management is to complete or schema.

This is the default behaviour in Kubernetes.

With complete the secret should contain the following:

username: <root-user
password: <root-password>

If the Database Management is set to schema the root user can be omitted, but the application and schema user has to be specified:

ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>

If used with complete the app and owner users will be created with the credentials specified in the secret.

Due to the usage of schemas, it is recommended to create a separate Kubernetes secret for each database pattern with the app and owner credentials when using Oracle or PostgreSQL.

Root Credential Namespace

Set if the Root Credential is in a different Kubernetes namespace.

Database User

Database connection user.

This setting is used in the following cases:

Classic deployments (VM)
In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.

Database Password

Password for the database connection user.

This setting is used in the following cases:

Classic deployments (VM)
In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.

TLS Encryption

If enabled the query parameter useSSL=true will be added to enable 1-way TLS.

If no Trust Store is assigned then trustServerCertificate=true will be added to the connection string.

Assignment of a Trust Store is recommended for production use.

Note: PostgresSQL database connection configuration doesn't support TLS connection yet.

Trust Store

Assign a trust store which provides the CA certificate of the DB endpoint.

Session Store Peer Address

The hybrid session store requires that the nevisProxy Instance is deployed on 2 lines. For illustration purposes let's call the hosts where the instances are deployed p1 and p2.

Enter the URL where the other nevisProxy Virtual Host exposes its local session store. The URL must be reachable and should not go via a load-balancer to ensure that the request reaches the peer proxy directly.

You can use variables to ensure that the correct host name is used for the configuration on each line. For instance, the variable may be a host variable and have the following values:

for server p1 use: https://p2:443
for server p2 use: https://p1:443

Alternatively, you can use a semantic host name and and define this name in /etc/hosts on both p1 and p2.

Example: https://proxy-peer:443

Session Store Path

Enter the path where the local session store shall be exposed and accessed by the nevisProxy peer.

Peer Servlet Strategy

Controls the used strategy of the Peer Servlet:

FAILOVER: The loadbalancer sends all requests to the same instance (instance A). If instance A goes down, the loadbalancer will send now all requests to instance B. The loadbalancer should only switch back to instance A if it has been restarted.
DISTRIBUTED: The loadbalancer assure at least 90% session stickiness to both instances, for example by using the client IP address. Once the request for a session goes to the other instance, this one will get the session information from the first instance and copy into its local session store.

Session Store Access Restriction

This optional configuration is available when Mode is set to hybrid.

Assign an Access Restriction pattern to define the source IPs that are allowed to access the Session Store Path.

Database Management

The pattern can set up the database, and it's schema when deploying to Kubernetes.

The complete option, on top of handling the schema migration, will do the initial database preparation like creating the actual database or tablespace in case of oracle, as well as creating the required database users.

The schema option will skip the initial preparation and will only take care of the actual schema migration. This requires the schema owner and the application user credentials to be present in the root credential secret. The root user information can be omitted with this option.

You can select disabled here to opt out. In this case you have to create and migrate the database schema yourself.

This feature is set to recommended by default which aims for the most convenient solution based on the deployment type. In case of Kubernetes deployments, it uses complete. In a classical VM deployment, it will use schema if the pattern allows setting Schema User and Schema Password, otherwise it's disabled.

Session Store Mode

Select one of:

classic - sessions are stored in the remote database only. Recommended setting for production setups.
hybrid - adds a local cache to improve the performance of the session store. This value is experimental and should only be used for test setups. This mode requires a session-sticky load balancer in front of nevisProxy. The generated configuration may change in future versions.

Database Schema Check

Select one of:

enabled - the database schema and integrity constraints are checked on startup to ensure they match the requirements of the Remote Session Store.
disabled - the database schema and integrity constraints are not checked on startup.

Note: On certain MariaDB versions, the check produces fake errors due to a MariaDB bug. By setting this parameter to disabled, you can skip the check.

Custom Parameters

Add custom init-param for the MySQL session store servlet.

Check the nevisProxy technical documentation for supported parameters of the servlet class ch::nevis::nevisproxy::servlet::cache::mysql::MySQLSessionStoreServlet.

Connection Parameters

Enter parameters for the DB connection string.

Enter 1 parameter per line.

Lines will be joined with &.

The default for MariaDB:

ping_timeout=2
connect_timeout=10

and for PostgreSQl:

connect_timeout=10

The default value will be used only when no parameters are entered.

If you want to keep the default parameters, add them as well.

Connection URL

Set only if you have to use a JDBC connection string which the pattern cannot generate.

If the prefix of the connection string works for you and you only have to add or overwrite query parameters, set Connection Parameters instead.

If you have to use this setting, please consult your setup with your integration partner.

In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.

Thus, this setting should only be used in classic deployments, or when Database Management is disabled.

Access Restriction
- Listing Type
- Source IPs
- Source IP HTTP-Header
- Country database
- Rules
- Default Action
- Apply only to sub-paths
- Allow Override
Automatic Key Store
- Owner(s)
Automatic Trust Store
- Trusted Key Store
- Additional Trusted Certificates
CSRF Protection Settings
- SameSite Cookie (Experimental)
- Header-based Check
- Allowed Domains
Cookie Customization
- Client Cookies
- Shared Protected Cookies
- Protected Cookies
- Cookie Conflict Resolution
Default Service
- Virtual Host(s)
- Frontend Path(s)
- Additional Settings
Generic Application Settings
- Filters and Mappings
- Filter Mappings
- Filter Phase
- Servlets and Mappings
- Template Parameters
- Remove Filter Mappings
Generic QoS Configuration (mod_qos)
- Server Directives (Experimental)
- Host Directives
Generic Virtual Host Settings
- Filters and Mappings
- Filter Mappings
- Filter Phase
- Servlets and Mappings
- Template Parameters
- Remove Filter Mappings
- Mime-Mappings
Generic nevisProxy Instance Settings
- Configuration: navajo.xml
- Configuration: bc.properties
- Template Parameters
HTTP Error Handling
- Error Pages
- Blocked Status Codes
- Redirect Status Code Mapping
- Keep Header Status Codes
- Overwrite Status Codes
- Mode
- Apply only to sub-paths
- Content-Type Mode
- Content-Types
- Base Path
- Keep Security Headers
HTTP Header Customization
- Add / Overwrite Headers
- Basic Auth User
- Basic Auth Password
- Remove Headers
- Filter Phase
- Add / Overwrite Headers
- Remove Headers
- Filter Phase
- Add / Overwrite Headers Condition
- Apply only to sub-paths
Hosting Service
- Virtual Host
- Frontend Path
- Resources
- Authentication Realm
- Rewrite Rules
- Additional Settings
ICAP Scanning
- ICAP Server URLs
- Content-Type Restriction
- Apply only to sub-paths
JWT Access Restriction
- HTTP Header
- Algorithm
- Public Key
Lua HTTP Processing
- Lua Script
- Lua Libraries
- Filter Phase
- Script Parameters
- Apply only to sub-paths
Maintenance Page
- Show Maintenance Page
- Start
- End
- Maintenance Page
- Status Code
- Base Path
NGINX Ingress Settings
- Annotations
- TLS Secrets
- Ingress Class Name
- Client Cert Authentication
- CA Secret
- CA Secret Namespace
- Client Cert Validation Depth
- Error Page
- Propagate Client Cert
- Path
- TLS Settings
- NodePort Service
PEM Key Store
- Key Store Content
- Examples
- Hardening
- Private Key Passphrase
- Key Store Passphrase
- Custom Directory Name
- Custom Root Directory Name
PEM Trust Store
- Trusted Certificates
- Custom Directory Name
- Custom Root Directory Name
REST Service
- Virtual Hosts
- Frontend Path(s)
- Authentication Realm
- Application Access Token
- Additional Settings
- Backend Addresses
- Load Balancing
- Key Store
- Send Certificate Chain
- Trust Store
- Hostname Validation
- Host Header
- Response Rewriting
- CSRF Protection
- JSON Validation
- Allowed HTTP Methods
- Session Termination
- Custom Parameters
Request Validation Settings (ModSecurity)
- Validation Scope
- Log Only Mode
- Paranoia Level
- Rule Modifications
- Whitelist Modifications
- Exception Modifications
- Template Parameters
- Rule Bundle
Response Rewrite Settings
- Backend Host Rewriting
- Response Body Rewriting
- Response Body Content Types
Rule Bundle (ModSecurity)
- Whitelist Modifications
- Exception Modifications
SOAP Service
- Virtual Hosts
- Frontend Path
- Authentication Realm
- Application Access Token
- Additional Settings
- Backend Addresses
- Load Balancing
- Key Store
- Send Certificate Chain
- Trust Store
- Hostname Validation
- Host Header
- Response Rewriting
- SOAP Schema Validation
- Allowed HTTP Methods
- Session Termination
- Custom Parameters
Secret Test
- Secret Value(s)
- Secret File(s)
Security Response Headers
- Response Headers
Securosys Key Store
- Certificates object label
- Private Keys object label
- Securosys PIN
- Securosys configuration files
Static Content Cache
- Max Entries
- Max Entry Size
- Max Lifetime
- Max-Age Mode
- Request Header Mode
- Response Header Mode
- Apply only to sub-paths
TCP Settings
- Connect Timeout
- Request Timeout
- DNS Caching
- DNS Caching Timeout
- Keep-Alive
- Connection Pool Size
- By Client
- Inactive Interval
- Lifetime
TLS Settings
- Protocols
- Cipher Suite
- SSL Options
Testing Service
- On validation
- On generation
- On planning
- On deployment
URL Handling
- Redirect Rules
- Forward Rules
- Apply only to sub-paths
- Filter Phase
Unauthenticated Realm
- Session Tracking
- Session Cookie Name
- Session Cookie Same Site
- Session Cookie Same Site Relaxation (Experimental)
- Session Validation
- Session Timeout
- Max Session Lifetime
- Update Session Timestamp Interval
Virtual Host
- Basic Usage
- Listening on Internal Addresses
- Supporting both HTTPS and HTTP
- Name-based Virtual Hosts
- nevisProxy
- Frontend Addresses
- Bind Addresses
- Frontend Key Store
- Frontend Trust Store
- Frontend TLS Settings
- Root URL Redirect
- Hosted Resources
- Session Store
- Unsecure Connection
- Require Client Certificate
- Qos Configuration (mod_qos)
- Allowed HTTP Methods
- OWASP ModSecurity CRS Version
- ModSecurity Rule Set
- Security Response Headers
- Session Store Resource
- Session Store Access Restriction
- HTTP/2 Support
- Early Hints
- Static Cache
- Encoded Slashes
- Additional HTTP Status Codes
- Additional Settings
Web Application
- Virtual Hosts
- Frontend Path(s)
- Authentication Realm
- Application Access Token
- Additional Settings
- Backend Addresses
- Load Balancing
- Key Store
- Send Certificate Chain
- Trust Store
- Hostname Validation
- Host Header
- Response Rewriting
- CSRF Protection
- Request Validation (ModSecurity)
- Allowed HTTP Methods
- Session Termination
- Custom Parameters
WebSocket Support for Application
- Custom Parameters
nevisKeybox Store
- Slot
- Label
- Validation
nevisProxy Instance
- Hint for pattern renaming
- Instance Name
- Log Settings
- Apache SSL Cache
- SSL Cache Size
- SSL Cache Timeout
- Instance Rename Detection
- Start Inactive
- Liveness Delay
- Readiness Delay
- Probe Periodicity
- Check Minimum Version
- Restart Policy
- Restart Condition
- Password Getter
- Crash Recovery Strategy
- Default Virtual Host
- Additional Settings
nevisProxy Log Settings
- Default Log Level
- Log Levels
- Conditional Log Levels
- Rotation Type
- Max Files
- Max File Size
- Rotation Interval
- Compress Rotated Log
- Compression Application
- Log Targets
- Event Log
- Server LogFormat
nevisProxy Observability Settings
- Trace Mode
- Trace Exporter Address
- Metrics Mode
- Metrics Exporter Address
- Trace Context Extraction
- Trace Context Injection
- Trace Resource Service Name
- Metrics Timeout
- Metrics Interval
nevisProxy Remote / Hybrid Session Store
- Database Type
- Database Host
- Database Name
- Root Credential
- Root Credential Namespace
- Database User
- Database Password
- TLS Encryption
- Trust Store
- Session Store Peer Address
- Session Store Path
- Peer Servlet Strategy
- Session Store Access Restriction
- Database Management
- Session Store Mode
- Database Schema Check
- Custom Parameters
- Connection Parameters
- Connection URL

nevisadmin-plugin-nevisproxy

Access Restriction​

Listing Type​

Source IPs​

Source IP HTTP-Header​

Country database​

Rules​

Default Action​

Apply only to sub-paths​

Allow Override​

Automatic Key Store​

Owner(s)​

Automatic Trust Store​

Trusted Key Store​

Additional Trusted Certificates​

CSRF Protection Settings​

SameSite Cookie (Experimental)​

Header-based Check​

Allowed Domains​

Cookie Customization​

Client Cookies​

Shared Protected Cookies​

Protected Cookies​

Cookie Conflict Resolution​

Default Service​

Virtual Host(s)​

Frontend Path(s)​

Additional Settings​

Generic Application Settings​

Filters and Mappings​

Filter Mappings​

Filter Phase​

Servlets and Mappings​

Template Parameters​

Remove Filter Mappings​

Generic QoS Configuration (mod_qos)​

Server Directives (Experimental)​

Host Directives​

Generic Virtual Host Settings​

Filters and Mappings​

Filter Mappings​

Filter Phase​

Servlets and Mappings​

Template Parameters​

Remove Filter Mappings​

Mime-Mappings​

Generic nevisProxy Instance Settings​

Configuration: navajo.xml​

Configuration: bc.properties​

Template Parameters​

HTTP Error Handling​

Error Pages​

Blocked Status Codes​

Redirect Status Code Mapping​

Keep Header Status Codes​

Overwrite Status Codes​

Mode​

Apply only to sub-paths​

Content-Type Mode​

Content-Types​

Base Path​

Keep Security Headers​

HTTP Header Customization​

Add / Overwrite Headers​

Basic Auth User​

Basic Auth Password​

Remove Headers​

Filter Phase​

Add / Overwrite Headers​

Remove Headers​

Filter Phase​

Add / Overwrite Headers Condition​

Apply only to sub-paths​

Hosting Service​

Virtual Host​

Frontend Path​

Resources​

Authentication Realm​

Rewrite Rules​

Additional Settings​

Access Restriction

Listing Type

Source IPs

Source IP HTTP-Header

Country database

Rules

Default Action

Apply only to sub-paths

Allow Override

Automatic Key Store

Owner(s)

Automatic Trust Store

Trusted Key Store

Additional Trusted Certificates

CSRF Protection Settings

SameSite Cookie (Experimental)

Header-based Check

Allowed Domains

Cookie Customization

Client Cookies

Shared Protected Cookies

Protected Cookies

Cookie Conflict Resolution

Default Service

Virtual Host(s)

Frontend Path(s)

Additional Settings

Generic Application Settings

Filters and Mappings

Filter Mappings

Filter Phase

Servlets and Mappings

Template Parameters

Remove Filter Mappings

Generic QoS Configuration (mod_qos)

Server Directives (Experimental)

Host Directives

Generic Virtual Host Settings

Filters and Mappings

Filter Mappings

Filter Phase

Servlets and Mappings

Template Parameters

Remove Filter Mappings

Mime-Mappings

Generic nevisProxy Instance Settings

Configuration: navajo.xml

Configuration: bc.properties

Template Parameters

HTTP Error Handling

Error Pages

Blocked Status Codes

Redirect Status Code Mapping

Keep Header Status Codes

Overwrite Status Codes

Mode

Apply only to sub-paths

Content-Type Mode

Content-Types

Base Path

Keep Security Headers

HTTP Header Customization

Add / Overwrite Headers

Basic Auth User

Basic Auth Password

Remove Headers

Filter Phase

Add / Overwrite Headers

Remove Headers

Filter Phase

Add / Overwrite Headers Condition

Apply only to sub-paths

Hosting Service

Virtual Host

Frontend Path

Resources

Authentication Realm

Rewrite Rules

Additional Settings

ICAP Scanning