Copyright

Copyright © 2019 Balasys IT Ltd.. All rights reserved. This document is protected by copyright and is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Balasys.

This documentation and the product it describes are considered protected by copyright according to the applicable laws.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)

Linux™ is a registered trademark of Linus Torvalds.

Windows™ 10 is registered trademarks of Microsoft Corporation.

The Balasys™ name and the Balasys™ logo are registered trademarks of Balasys IT Ltd.

The Zorp™ name and the Zorp™ logo are registered trademarks of Balasys IT Ltd.

The Proxedo™ name and the Proxedo™ logo are registered trademarks of Balasys IT Ltd.

AMD Ryzen™ and AMD EPYC™ are registered trademarks of Advanced Micro Devices, Inc.

Intel® Core™ and Intel® Xeon™ are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries.

All other product names mentioned herein are the trademarks of their respective owners.

DISCLAIMER

Balasys is not responsible for any third-party websites mentioned in this document. Balasys does not endorse and is not responsible or liable for any content, advertising, products, or other material on or available from such sites or resources. Balasys will not be responsible or liable for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods, or services that are available on or through any such sites or resources.

2021-07-12 .Copyright

Preface

Typographical conventions

Before you start using this guide, it is important to understand the terms and typographical conventions used in the documentation. For more information on specialized terms and abbreviations used in the documentation, see the Glossary at the end of this document.

The following text formatting principles and icons identify special information in the document.

Tips provide best practices and recommendations.
Notes provide additional information on a topic, and emphasize important facts and considerations.
Warnings mark situations where loss of data or misconfiguration of the device is possible if the instructions are not obeyed.
Command

Commands you have to execute.

Emphasis

Reference items, additional readings.

/path/to/file

File names.

Parameters

Parameter and attribute names.

In the parameter listing tables the required parameters are also emphasized with bold text:

Key Description

param1

This is a required parameter.

param2

This is an optional parameter.

Additional marks used specifically in the Web User Interface (UI):

Key Description

*

The elements marked with * in the configuration reference tables are mandatory to be configured.

(Default)

For some of the configuration elements there are recommended default values, marked as (Default). In case the value is not defined during the configuration, the default value will be considered for the actual element.

+

By clicking this sign you can add the actual element to the list of configuration elements.

Contact and support information

This product is developed and maintained by Balasys IT Ltd..

Contact:

Balasys IT Ltd.
4 Alíz Street
H-1117 Budapest, Hungary
Tel: +36 1 646 4740
E-mail: <info@balasys.hu>
Web: http://balasys.hu/

Sales contact

You can directly contact us with sales-related topics at the e-mail address <sales@balasys.hu>, or leave us your contact information and we call you back.

Support contact

To access the Balasys Support System, sign up for an account at the Balasys Support System page. Online support is available 24 hours a day.

Balasys Support System is available only for registered users with a valid support package.

Support e-mail address: <support@balasys.hu>.

Training

Balasys IT Ltd. holds courses on using its products for new and experienced users. For dates, details, and application forms, visit the https://www.balasys.hu/hu/support/trainings webpage.

1. Scope of this document

This document describes the Web User Interface for the Proxedo API Security. The purpose of this document is to present the designed approach and the usage for the configuration of Proxedo API Security via Web User Interface (UI). The Web UI allows easy configuration for Proxedo API Security. All the functionalities are grouped visually and logically into thematic units which follow the logical built up of Proxedo API Security’s configuration. The primary intended audience of this document are system engineers and system designers for configuring Proxedo API Security systems.

2. Introduction to Proxedo API Security

2.1. What is Proxedo API Security

The Proxedo API Security (PAS) is a security solution that protects API serving endpoints. It is positioned in the network flow between consumers of the APIs (clients) and backend solutions serving the API (servers) as a transparent HTTP proxy.

Proxedo API Security can:

  • handle incoming Transport Layer Security v1 (TLS) connections from clients & outgoing TLS connections to servers separately and selectively

  • verify that the communication conforms to HTTP specifications

  • verify that the content of the messages conform to their specified content type

  • verify that the content of messages conform to API specification(s) as described in schemas

  • extract parts of the content of the messages and relay them to external data stores such as log servers, SIEM systems or other data warehouses

2.2. Where to start

Depending on what you need to do the following starting points are suggested:

3. Overview of Proxedo API Security

3.1. Main features

3.1.1. TLS

Transport Layer Security v1 (TLS) (successor of the now obsoleted Secure Socket Layer v3 (SSL)) is a widely used crypto protocol, guaranteeing data integrity and confidentiality in many PKI and e-commerce systems.

The TLS framework inspects TLS connections, and also any other connections embedded into the encrypted TLS channel. TLS connections initiated from the client are terminated on the Proxedo API Security, and two separate TLS connections are built: one between the client and the firewall, and one between the firewall and the server. If both connections match the configuration settings of PAS (for example, the certificates are valid, and only the allowed encryption algorithms are used), PAS inspects the protocol embedded into the secure channel as well. Note that the configuration settings can be different for the two connections, for example, it is possible to permit different protocol versions and encryption settings.

3.1.2. Enforcement

Proxedo API Security acts as an HTTP proxy and verifies that the traffic passing through conforms to HTTP’s specifications. By using OpenAPI schemas, as defined in OpenAPI specifications (also known as Swagger), it also verifies that the traffic passing through conforms to the API enpoint’s specification and can log or deny non-conforming traffic.

PAS also provides its own versatile filtering system to control passing traffic.

3.1.3. Insights

With Proxedo API Security it is possible to extract business-relevant information with extremely high resolution from the traffic and relay it to external data stores where further analysis can be implemented.

Thus, it is possible to feed Log Management solutions, Monitoring and SIEM systems, Data visualization tools with data extracted from the traffic, even to the level of specific fields deep inside API calls or URI parameters.

3.1.4. Security flow

The security flow binds most of PAS’s features together. It allows flexible configuration for handling the traffic. Multiple Enforcement, Filter and Insight plugins can be mix-and-matched with control over error policies.

3.1.5. High Availability

Proxedo API Security offers the high availability (HA) feature optionally. With the help of this feature, two identical PAS servers provide redundancy so that the network traffic is not disturbed in case any of the nodes fails. Support for synchronizing configuration and setting remote services' state is also implemented.

3.2. Main Concepts in Proxedo API Security

This chapter provides an overview of the Proxedo API Security solution, introduces its main concepts, and explains the relationship of the various components.

API Endpoint

Proxedo API Security protects API endpoints. An API endpoint is the serving part of the communication channel and is the collection of all functions of a service. It resides at a list of well-known top URIs under which all the functions are accessible. APIs have well-defined HTTP Endpoints for all exposed calls, resources etc., usually through providing a schema that describes all parameters of these URI paths, including possible HTTP response codes, the format and fields of the data structure in the request’s and response’s body.

Client

It is a consumer of API endpoints. It is the source of the requests.

Backend

The backend constitutes of one or more servers that serve the API endpoint. It receives the requests of the client and sends the responses.

HTTP message

It can be an HTTP request coming from the client or an HTTP response coming from the backend.

Call

An HTTP conversation constitutes of a request — response interchange of HTTP messages between the client and the backend. Whenever the direction is irrelevant in the context — it applies to both requests and responses — the message is named Call.

Listener

It is the part of PAS that listens to incoming traffic for given API Endpoints. It is bound to a network port. Clients address this port when accessing API Endpoints through the gateway.

TLS

Transport Layer Security is the cryptographic protocol that secures HTTPS communications. PAS can apply TLS encryption both when communicating with Clients and Backends.

Security flow

It provides a collection of security rules that PAS applies to a Call. It is two series of Plugins: one for requests and one for responses.

Plugin

It is an element of the security flow that applies a specific security function. It has different types based on the role they do.

Decompressor

It is a Plugin responsible for decompressing compressed content in the HTTP message’s body. This ensures that the original content of the message is available for processing.

Compressor

It is a Plugin responsible for compressing the result of a flow and forwarding the compressed content.

Deserializer

It is a Plugin responsible for parsing the HTTP message’s body to structured data. This ensures that a message is well-formed. The structured data will also be consumed by other Plugins that operate on the body of the message.

Serializer

It is a Plugin responsible for serializing the structured data to the format of the HTTP message’s body.

Filter

It is a Plugin that rejects calls when they match defined rules.

Enforcer

It is a Plugin that validates calls against externally defined schemas.

Insight

It is a Plugin that extracts various data from the call and sends it to external systems (log servers, SIEMs, and other data analysis tools).

Brick

They are reusable components of Plugins. They can be defined on their own and then shared by multiple Plugins.

Error policy

It is a brick that defines what happens if the Plugin has found an error. It decides if calls are rejected or merely logged, and defines the details of the HTTP error response sent to the client if a call is rejected.

Matcher

It is a brick that decides if the Plugin should be executed for a given call by checking various data in the HTTP message.

Selector

Selector is a brick that can extract a piece of information from a call. It is used by Insight plugins.

Target

It is a brick that defines an external system to send extracted data to. It is used by Insight plugins.

High Availability

This feature enables two nodes serving as redundant PAS endpoints. It helps ensure service continuity in case of a node failure while being transparent to clients.

3.3. Architecture for Proxedo API Security

Proxedo API Security is based on a micro-services architecture.

The components of the architecture are each responsible for well-defined subset of handling traffic between the client and the backend. Proxedo API Security is built up of three components:

Transport Director

It manages the transport layer of API connections:

  • handles network connections from the client

  • handles network connections towards the backends

  • handles TLS on these connections

  • load-balances between multiple backend servers

  • load-balances between multiple Flow Directors

  • enforces HTTP protocol validity in calls

Flow Director

It is responsible for the execution of the Plugins in the Endpoint’s flow and for applying Error Policies as necessary.

Insight Director

It manages the connections to Targets. It is responsible for sending the data collected by Insight plugins to Target systems.

The handling of a connection with the help of components is shown in this figure:

PAS Architecture
Figure 1. PAS Architecture
  1. Incoming connections are accepted by the Transport Director.

    • It handles TLS with the client if necessary.

  2. It hands over the connection to the Flow Director.

    • The Flow Director chooses the Endpoint based on the URL.

    • The Flow Director applies the Endpoint specific Request Security Flow.

  3. If an Insight plugin needs to send data to an external Target it sends the collected data to the Insight Director.

  4. The Insight Director sends the data further to the Target with the appropriate protocol.

  5. The Flow Director hands the connection back to the Transport Director.

  6. The Transport Director then sends the data to the Backend.

    • It handles TLS with the backends if necessary.

    • It performs load balancing among Backend servers if necessary.

The same procedure is executed with the response coming from the Backend.

3.3.1. Understanding processing flow

The figure on Proxedo API Security architecture and the steps following that describe how client connection is handled. The following figure explains how calls are processed in more details:

PAS processing flow
Figure 2. PAS processing flow
  1. As shown in the figure above, the incoming connection from the client is handled by the Transport Director, applying TLS if needed.

  2. The Transport Director hands over the connection to the Flow Director, indicating which Listener the connection belongs to.

  3. The Flow Director then chooses the Endpoint based on the URL in the request. First endpoint has matching URL is chosen.

  4. The Flow Director then starts applying the request part of the Security Flow definition.

  5. For each Plugin the Flow Director:

    • Checks if the Plugin's matcher matches the request.

    • If so, it executes the Plugin, if not, it executes the next Plugin.

    • If the Plugin indicates success it executes the next Plugin.

    • If the Plugin indicates an error it applies the Plugin's error policy. If the policy dictates to abort the connection:

      • It fills error details and hands back the connection to the Transport Director, aborting the execution of the flow.

      • The Transport Director closes the connection, sending error details to the client if allowed by the policy.

  6. Once, the last Plugin has been executed the connection is handed back to the Transport Director.

  7. The Transport Director initiates the connection towards the Backend:

    • It handles load balancing if necessary.

    • It handles TLS if necessary.

    • It sends the request itself to the Backend server.

  8. The Backend server sends its response to the Transport Director.

  9. Once, the response has been received the Transport Director again hands over the connection to the Flow Director.

  10. The Flow Director then starts applying the response part of the Security Flow definition, executing the Plugins as above.

  11. Once, the last Plugin has been executed the connection is handed back to the Transport Director.

  12. Finally, the Transport Director sends the response to the client.

Usually, Plugins are organized in the following manner:

  • A Decompressor Plugin extracts the compressed body.

  • A Deserializer Plugin processes the decompressed request to understand the details in the body.

  • Filters are applied to filter unnecessary traffic.

  • Enforcers are applied for detailed validation of calls.

  • Insights are applied to collect data from the call.

  • Serializer Plugin serializes the body

  • Compressor Plugin compresses the serialized body

Though the order of the plugins can be changed based on the needs, note the followings:

  • When a Plugin needs access to the request body it requires Deserialized data. It is therefore strongly recommended that the first plugin is a Decompressor followed by a Deserializer.

  • At the end of the flow it is strongly recommended to place a Serializer plugin followed by a Compressor.

  • Generally Insights are applied after Filters and Enforcers so that they are not executed on possibly invalid calls.

  • Anything that operates on the HTTP headers or the body of the message will be aware of the call direction: The same Plugin in the request and response flow will act on the request or response data.

  • However, the Flow Director handles a request-response exchange together, so you can still use details from the request in Plugins of the response flow. The most notable example of this is using URI or method matchers in the response flow.

  • Plugins in the request flow, however, cannot access details of the response flow (since they are not available yet.)

It is also worth noting that Insight Plugins instantly hand over data to the Insight Director, and let the execution continue.

3.3.2. Architecture with High Availability

In case of HA operation, the core component is configured on both nodes participating in the HA operation. The architecture and the process are identical on both nodes, but they are set up to work redundantly. Only one node (the master) of the cluster is receiving traffic actively.

This operation uses the following additional resources:

  • two nodes with PAS core installed

    At the moment, only clusters of two are supported. It also means, that you will need to have a node with both management and core components installed, and a node with only core installed.
  • a virtual IP address through which the service is supposed to be accessible

The technical foundation of our HA solution is the Virtual Router Redundancy Protocol (VRRP). Once the requirements are properly set up, it operates as follows:

  • At startup, the nodes send keepalive messages to each other to see if the other node is available. Both of them consider themselves to be in BACKUP state until they make sure the other node is not in MASTER state. If both nodes are newly connected to the cluster, they participate in an election and the one with the higher priority becomes the MASTER.

  • After one of the nodes has become the MASTER, both of them keep sending keepalive messages so that they notice when the other node disappears.

  • A node (re)connecting to the cluster does not result in the reelection of the MASTER.

4. Installation of Proxedo API Security

PAS is mainly distributed as Docker images, and is also completed with a .deb package that sets up the operational environment.

You can install the management and the core components either on one single node or on two separate ones. The synchronization of the core configuration is provided by the storage component. To configure the storage component properly for either setup, you should follow the instructions in /opt/balasys/etc/storage/config.yml.

For the multi-node setup, we also provide a core deployment tool along with the management component. Using that, you need to configure and install everything manually on the management node, but you can use the automation tool to deploy and configure the core and the storage on the remote node.

The specific sections on the installation of the different components also provide details on how to install them on a single node. In section Multi-node setup using the automated deployment tool, the main starting points for using the automated deployment tool are described.

4.1. Prerequisites

The followings are needed prior to the installation of Proxedo API Security:

  • the licence for PAS

  • a technical user for accessing Balasys' download site and docker registry

  • the PAS core and management .deb packages

    You can download the .deb packages from the Balasys Download website.
  • a server with Ubuntu 18.04 Operating System installed

4.2. Installation steps for the storage component

  1. Log in as root.

  2. Update the OS' package list: apt update.

  3. Install the PAS storage .deb package: apt install <path/to/deb>/proxedo-api-security-storage_<version>.deb.

This will:

  • Create a user named pas for running and configuring PAS.

    pas user must not be created manually beforehand.
  • Install the necessary configuration files and helper scripts under /opt/balasys.

  • Create systemd services for managing the PAS storage component.

    You need to use apt to install the .deb package locally as it installs its dependencies as well. dpkg will not resolve dependencies, and apt-get cannot install from a local file. Also note that to install PAS from the current directory, you must use the path ./ before the .deb package, or apt will try to download the package from a repository.
  1. Change to the PAS user: su - pas.

  2. Set up parameters in /opt/balasys/etc/infrastructure/storage/docker-compose.conf. For details, see docker-compose.conf.

  3. Run pas-mgmt-registry-login to set up authentication with the docker registry. Provide login credentials on the prompt. Contact support if you need assistance with your credentials.

    Docker will, by default, save your credentials unencrypted in the home directory of the pas user. Using a password-management tool like pass is not enforced, but it is recommended.
  4. Run pas-storage-update to download the docker images.

  5. Set up startup configuration in /opt/balasys/etc/storage/config.yml along with all the other resources it describes.

  6. Run pas-storage-checkconfig to validate the configuration.

  7. Start PAS storage: systemctl start proxedo-api-security-storage.

    This service is enabled by default, so the service starts on system restart.

4.3. Installation steps for the management component

  1. Log in as root.

  2. Update the OS' package list: apt update.

  3. Install the PAS management .deb package: apt install <path/to/deb>/proxedo-api-security-mgmt_<version>.deb.

This will:

  • Create a user named pas for running and configuring PAS.

    pas user must not be created manually beforehand.
  • Install the necessary configuration files and helper scripts under /opt/balasys.

  • Create systemd services for managing the PAS management component.

    You need to use apt to locally install the .deb package as it installs its dependencies as well. dpkg will not resolve dependencies, and apt-get cannot install from a local file. Also note that to install PAS from the current directory, you must use the path ./ before the .deb package, or apt will try to download the package from a repository.
  1. Change to the PAS user: su - pas.

  2. Set up MINIO_* parameters in /opt/balasys/etc/infrastructure/mgmt/docker-compose.conf. You can also modify other parameters if necessary, including port numbers and the version. For details, see docker-compose.conf.

  3. Run pas-mgmt-registry-login to set up authentication with the docker registry. Provide login credentials on the prompt. Contact support if you need assistance with your credentials.

    Docker will, by default, save your credentials unencrypted in the home directory of the pas user. Using a password-management tool like pass is not enforced, but it is recommended.
  4. Run pas-mgmt-update to download the docker images.

  5. Set up startup configuration in /opt/balasys/etc/mgmt/config.yml.

  6. Run pas-mgmt-checkconfig to validate the configuration.

  7. Start PAS management: systemctl start proxedo-api-security-mgmt.

    This service is enabled by default, so the service starts on system restart.

4.4. Installation steps for the core component

  1. Log in as root.

  2. Update the OS' package list: apt update.

  3. Install the PAS .deb package: apt install <path/to/deb>/proxedo-api-security_<version>.deb.

This will:

  • create a user named pas for running and configuring PAS.

    pas user must not be created manually beforehand.
  • Install the necessary configuration files and helper scripts under /opt/balasys.

  • Create systemd services for managing PAS.

    You need to use apt to locally install the .deb package as it installs its dependencies as well. dpkg will not resolve dependencies, and apt-get cannot install from a local file. Also note that to install PAS from the current directory, you must use the path ./ before the .deb package, or apt will try to download the package from a repository.
  1. Change to the PAS user: su - pas.

  2. Set up MINIO_* parameters and the number of Flow Director instances to run in /opt/balasys/etc/infrastructure/pas/docker-compose.conf. If necessary, also change the version you want to follow. For details, see docker-compose.conf.

  3. Copy license.txt to /opt/balasys/etc/pas.

  4. Run pas-registry-login to set up authentication with the docker registry. Provide login credentials on the prompt. Contact support if you need assistance with your credentials.

    Docker will, by default, save your credentials unencrypted in the home directory of the pas user. Using a password-management tool like pass is not enforced, but it is recommended.
  5. Run pas-update to download the docker images.

  6. Start PAS: systemctl start proxedo-api-security.

    The core component will not start until a running configuration is set up through the management interface. To do it, please refer to Configuration of Proxedo API Security on the Web User Interface.
    This service is enabled by default, so the service starts on system restart.
  7. If you configured Certificate Revocation List (CRL) verification in any of your Backends or Listeners you need to enable CRL updates:

    sytemctl enable proxedo-api-security-crl-update.service
    sytemctl enable proxedo-api-security-crl-update.timer
    sytemctl start proxedo-api-security-crl-update.timer

4.5. Multi-node setup using the automated deployment tool

For a multi-node setup, you first need to have a functional management component installed on a node. Its storage needs to be set up to work in cluster with the node the core component is going to be deployed to. Along with the management component, you get the automated deployment tool that helps you manage your remote node and the core component on it.

4.5.1. Configuration

To deploy a core component on a remote node, the following prerequisites need to be met:

  • the core and the storage .deb packages on the management node

  • the license file on the management node

  • a node with an Ubuntu installed

  • a user on the remote node which can run sudo without providing password

    As running sudo without a password grants virtually limitless privileges over the machine, it is strongly advised that SSH is only allowed using SSH keys.

To configure the automation and the remote nodes, you need to fill out three types of configuration files.

  • /opt/balasys/etc/automation/inventory.yml: The details of the nodes to deploy the core component to.

  • /opt/balasys/etc/automation/common_vars.yml: Variables that are common among all nodes.

  • /opt/balasys/etc/automation/host_vars: The directory holding variables for host-specific values. For each entry in inventory.yml, there must be a file in this directory. For example, if you have an entry named pas-node-1 in your inventory, you need to have a file named pas-node-1.yml in the host_vars directory.

The last step to do before you can deploy the core component on a remote node is to implement login. To do that

  1. Generate an SSH key.

    pas@pas-node-mgmt:~$ ssh-keygen -t rsa -b 4096 -C "pas-node-1"
  2. Add the SSH key to the user on the remote node which can run sudo without password.

    deployment@pas-node-1:~$ mkdir -p ~/.ssh
    deployment@pas-node-1:~$ cat <<generated_public_key_here>> >> ~/.ssh/authorized_keys
    deployment@pas-node-1:~$ chmod 700 ~/.ssh/
    deployment@pas-node-1:~$ chmod 600 ~/.ssh/authorized_keys

4.5.2. Deployment and remote management commands

To deploy core and manage it on the remote node, you need to run the pas-mgmt-deploy-core command. Running this command with different command line flags, you can execute different operations. For the list and explanation of possible operations, run pas-mgmt-deploy-core --help.

5. Base system configuration

This chapter explains configuration details for setting up a working PAS. Configuration settings are detailed here, provided by the .deb packages installed on an Ubuntu 18.04 LTS server.

The .deb packages carry convenience tools for managing the Proxedo API Security core and the management component, the actual installation and execution is done by Docker and docker-compose.

5.1. Overview of configuration directories

PAS consists of multiple components and each may have multiple configuration files for both infrastructure definition and bootstrapping. In this section, a general overview is provided about how the corresponding configuration directories are structured.

As a rule of thumb, every configuration file for PAS is available under /opt/balasys/etc, and right after installation of all the components, the directory tree looks like the following.

Tree of initial configuration files
/opt/balasys/etc/
├── automation
│   ├── common_vars.yml -> ../../usr/share/automation/roles/deploy-core/vars/main.yml
│   ├── host_vars -> ../../usr/share/automation/host_vars
│   └── inventory.yml -> ../../usr/share/automation/inventory.yml
├── ha
│   └── config.yml
├── infrastructure
│   ├── ha
│   │   └── docker-compose.yml
│   ├── mgmt
│   │   ├── docker-compose.conf
│   │   └── docker-compose.yml
│   ├── pas
│   │   ├── docker-compose.conf
│   │   └── docker-compose.yml
│   └── storage
│       ├── docker-compose.conf
│       └── docker-compose.yml
├── mgmt
│   └── config.yml
├── pas
└── storage
    └── config.yml

In general, the following rules apply:

  • /opt/balasys/etc/infrastructure holds the files to describe the infrastructure, the component will run in. Exposed ports and used images are the two most important parameters set up in the files in this directory.

  • /opt/balasys/etc/{ha,mgmt,pas,storage} hold the bootstrap configuration of the respective components. By default, only configuration files are created, but certificates, the license file, etc. also reside in these directories. They will be mounted to the containers so that the processes can use these files as well.

  • /opt/balasys/etc/automation makes necessary configuration available for remote core deployment. As seen in the directory tree, files in this directory are symbolic links to ease access to the actual files. During debugging, or after installation, their original directories may also be useful to look at.

As there are more directories and subdirectories linked to each package, the following table defines the corresponding directories for each package.

Table 1. Directories grouped by package ownership
Package Directories

proxedo-api-security

  • /opt/balasys/etc/ha

  • /opt/balasys/etc/pas

  • /opt/balasys/etc/infrastructure/ha

  • /opt/balasys/etc/infrastructure/pas

proxedo-api-security-mgmt

  • /opt/balasys/etc/mgmt

  • /opt/balasys/etc/automation

  • /opt/balasys/etc/infrastructure/mgmt

proxedo-api-security-storage

  • /opt/balasys/etc/storage

  • /opt/balasys/etc/infrastructure/storage

5.2. docker-compose.yml

The main configuration of the running environment is defined in the /opt/balasys/etc/infrastructure/storage/docker-compose.yml, /opt/balasys/etc/infrastructure/pas/docker-compose.yml and /opt/balasys/etc/infrastructure/mgmt/docker-compose.yml files. They describe the containers running PAS.

The format of the files must adhere to the YAML 1.1 specification. For a brief overview of the YAML format look at the example here. For an in-depth reference of docker-compose configuration see its documentation.

This file controls:

  • the images to run the container from

  • the persistent data storage (docker volumes) to attach to the containers

  • the ports propagated to the containers

  • the environment variables available inside the containers

  • intra container communication channels (links)

  • log target configuration

Unless inevitable, you should not modify these files. There are two cases when you might need to.

  1. If you need to modify the provided environment to debug your setup.

  2. If you need to change the default behavior of logging into the system’s journal you must change the logging parameters under all the services. See more details in docker-compose’s documentation.

If you modify these files, they will not be overwritten on package upgrade. Only interactive installs will notify you.
Do not use docker-compose directly to manage the installation. Always use systemctl as it handles dependencies and scaling.

5.3. docker-compose.conf

Some aspects of how the services are run by docker-compose are configured through /opt/balasys/etc/infrastructure/storage/docker-compose.conf, /opt/balasys/etc/infrastructure/pas/docker-compose.conf and /opt/balasys/etc/infrastructure/mgmt/docker-compose.conf.

The format of this file is a shell environment file format: a key-value pair in each line, separated by an equal sign ("=").

There must not be spaces around the equal sign.

The configuration files of different components have a common portion along with other parameters that are only valid in one of them. For details, see the following tables.

There are no storage-specific configuration options.
Table 2. docker-compose.conf configuration common options
Key Default Description

PAS_IMAGE_TAG

3.0.latest

The release track of Proxedo API Security to use. See Tracking version.

COMPOSE_FILE

/opt/balasys/etc/infrastructure/pas/docker-compose.yml or /opt/balasys/etc/infrastructure/mgmt/docker-compose.yml

Path to the compose file. You must not modify the default value.

COMPOSE_PROJECT_NAME

pas

Name used for the compose project. They must be kept synchronized over different files.

PAS_DOCKER_REGISTRY

docker.balasys.hu

It is the domain name of the docker registry to download images from.

Table 3. docker-compose.conf configuration management-specific options
Key Default Description

PAS_MGMT_WEBUI_HTTP_PORT

80

It is the port to expose for HTTP access of the management web user interface.

PAS_MGMT_WEBUI_HTTPS_PORT

443

It is the port to expose for HTTPS access of the management web user interface.

MINIO_ACCESS_KEY

It is the access key to be used for MinIO authentication. It must be the same as defined in /opt/balasys/etc/storage/config.yml.

MINIO_SECRET_KEY

It is the secret key to be used for MinIO authentication. It must be the same as defined in /opt/balasys/etc/storage/config.yml.

Table 4. docker-compose.conf configuration core-specific options
Key Default Description

PAS_FLOW_DIRECTOR_SCALE

1

It defines the number of Flow Director instances to run. For details, see Scaling Flow Director.

PAS_TRANSPORT_DIRECTOR_PORT_RANGE1

49000-49100

It is a port range to expose to Transport Director. Listeners will work in this port range.

PAS_TRANSPORT_DIRECTOR_PORT_RANGE2

49101-49200

It is an additional port range to expose to Transport Director. Listeners will work in this port range.

MINIO_ACCESS_KEY

It is the access key to be used for MinIO authentication. It must be the same as defined in /opt/balasys/etc/storage/config.yml.

MINIO_SECRET_KEY

It is the secret key to be used for MinIO authentication. It must be the same as defined in /opt/balasys/etc/storage/config.yml.

Storage example:

PAS_IMAGE_TAG=3.0.latest
COMPOSE_FILE=/opt/balasys/etc/infrastructure/mgmt/docker-compose.yml
COMPOSE_PROJECT_NAME=pas
PAS_DOCKER_REGISTRY=docker.balasys.hu

Management example:

PAS_IMAGE_TAG=3.0.latest
COMPOSE_FILE=/opt/balasys/etc/infrastructure/mgmt/docker-compose.yml
COMPOSE_PROJECT_NAME=pas
PAS_DOCKER_REGISTRY=docker.balasys.hu

PAS_MGMT_WEBUI_HTTP_PORT=80
PAS_MGMT_WEBUI_HTTPS_PORT=443

MINIO_ACCESS_KEY=your_minio_access_key
MINIO_SECRET_KEY=your_minio_secret_key

Core example:

PAS_IMAGE_TAG=3.0.latest
COMPOSE_FILE=/opt/balasys/etc/infrastructure/mgmt/docker-compose.yml
COMPOSE_PROJECT_NAME=pas
PAS_DOCKER_REGISTRY=docker.balasys.hu
PAS_FLOW_DIRECTOR_SCALE=1

PAS_TRANSPORT_DIRECTOR_PORT_RANGE1=49000-49100
PAS_TRANSPORT_DIRECTOR_PORT_RANGE2=49101-49200

MINIO_ACCESS_KEY=your_minio_access_key
MINIO_SECRET_KEY=your_minio_secret_key
Changing any of the values requires the restart of the service.

5.4. PAS restart policy

PAS service lifecycle is managed by systemd and is by default set to restart if any of the components fails at any point. To avoid infinite restarting, the number of restarts within a short period of time is also limited. As a result, if PAS core or management stops with a non-zero exit code 3 times within 100 seconds, the corresponding systemd unit will enter failed state.

The default restart policy and the options are identical for the storage, core and management components.

The relevant part of the service file looks as follows:

[Unit]
StartLimitIntervalSec=100
StartLimitBurst=3

[Service]
Restart=on-failure

Modifying the restart policy is possible by editing the service file in override mode. To do so, run systemctl edit proxedo-api-security-storage, systemctl edit proxedo-api-security or systemctl edit proxedo-api-security-mgmt. This will open a text editor and will let you define the parameters you wish to override. For example, if you want to switch off all default restart settings, enter the following text in the override editing window:

[Unit]
StartLimitIntervalSec=
StartLimitBurst=

[Service]
Restart=no

Possible values for Restart= are documented by systemd. We recommend using no to avoid automatic restarting by systemd or on-failure to make the service restart on non-zero exit codes. If you want a more fine-tuned restart policy, please consult the systemd.service(5) man page and configure the desired options.

To discard your overrides, run systemctl revert proxedo-api-security-storage, systemctl revert proxedo-api-security or systemctl revert proxedo-api-security-mgmt.

You only need to enter the parameters you want to change.
Overriding systemd units is only possible as root user.

5.5. Tracking version

Proxedo API Security has a version number in the form of major.minor.patch. The docker image labels control how the automatic update of the services are handled. Each image has 3 possible tags:

  • MAJOR.latest (for eg. 1.latest): These tags point to the latest release in the major release. That is, for the release of both x.y.z+1 and x.y+1.0, this tag will be updated, and the services will be upgraded at the restarts. There will not be upgrades for x+1.0.0.

  • MAJOR.MINOR.latest (for eg. 1.3.latest): These tags point to the latest release in the minor release. That is, for the release x.y.z+1, this tag will be updated, and the services will be upgraded at restarts, however not for the release x.y+1.0.

  • MAJOR.MINOR.PATCH (for e.g. 1.4.7): These tags point to a specific release and will never be changed once released.

5.6. Scaling Flow Director

A single instance of Flow Director uses a single processor core. It is necessary to adjust the number of instances to use all the available cores. This is controlled by the PAS_FLOW_DIRECTOR_SCALE variable. As the Flow Director handles the most demanding duties among the components, it must be assigned most of the cores. If there are up to four cores available, assign three cores to the Flow Director, and the remaining one core will be suitable for the Transport and Insight Director. If there are more than four cores, assign two cores for the Transport and Insight Director and assign the rest to the Flow Director.

5.7. Configuration of dockerd

The docker daemon is configured through /etc/docker/daemon.json. The full documentation can be found in the official docker documentation.

Balasys recommends the use of the default configuration.

Do not use /etc/default/docker as it is ignored when systemd is used.

5.8. High availability configuration

5.8.1. HA Director

The HA functionality is implemented by the HA Director included in the core component. It uses keepalived in VRRP mode to provide the service.

It can be configured in two ways:

  1. When installed and configured manually on the host running core, the configuration file /opt/balasys/etc/ha/config.yml should be filled out.

  2. When installed using the automation tool, the following configuration files need to be filled in on the management node:

    • /opt/balasys/etc/automation/common_vars.yml: Common HA parameters to be used on remote hosts.

    • /opt/balasys/etc/automation/host_vars: Host-specific HA parameters to be used on remote hosts.

As at the moment, only clusters of two are supported, you can only implement HA by installing core alongside the management component as well. That instance you need to configure and set up manually, while you can use the automated deployment tool to deploy core and HA on the remote node.

5.8.2. HA restart policy

PAS service lifecycle is managed by systemd and is by default set to restart if any of the components fails at any point. To avoid infinite restarting, the number of restarts within a short period of time is also limited. As a result, if PAS core or management stops with a non-zero exit code 3 times within 100 seconds, the corresponding systemd unit will enter failed state.

The default restart policy and the options are identical for the storage, core and management components.

The relevant part of the service file looks as follows:

[Unit]
StartLimitIntervalSec=100
StartLimitBurst=3

[Service]
Restart=on-failure

Modifying the restart policy is possible by editing the service file in override mode. To do so, run systemctl edit proxedo-api-security-storage, systemctl edit proxedo-api-security or systemctl edit proxedo-api-security-mgmt. This will open a text editor and will let you define the parameters you wish to override. For example, if you want to switch off all default restart settings, enter the following text in the override editing window:

[Unit]
StartLimitIntervalSec=
StartLimitBurst=

[Service]
Restart=no

Possible values for Restart= are documented by systemd. We recommend using no to avoid automatic restarting by systemd or on-failure to make the service restart on non-zero exit codes. If you want a more fine-tuned restart policy, please consult the systemd.service(5) man page and configure the desired options.

To discard your overrides, run systemctl revert proxedo-api-security-storage, systemctl revert proxedo-api-security or systemctl revert proxedo-api-security-mgmt.

You only need to enter the parameters you want to change.
Overriding systemd units is only possible as root user.

5.9. Setting up time synchronization

To ensure time synchronization on different nodes you need to configure NTP on them. The ntp package is already installed as a dependency, but it must be configured We recommend adding the following configuration to /etc/ntp.conf.

driftfile /var/lib/ntp/ntp.drift

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1

server time.nist.gov prefer
server ip-time-1.cern.ch
Use your own NTP servers in the server directives if you have any, or adjust the given values to ones that are allowed by your policies.

After creating the configuration, run the following commands.

# Disable systemd-timesyncd
timedatectl set-ntp false

# Restart ntp
systemctl restart ntp

# Enable ntp so that it starts on system startup
systemctl enable ntp

6. Configuration of Proxedo API Security on the Web User Interface

This chapter explains configuration details for setting up a working Proxedo API Security (PAS) with the help of the Web User Interface.

The Proxedo API Security Web User Interface (UI) is installed together with the installation of Proxedo API Security. The URL for Proxedo API Security Web UI and the necessary credentials are defined by the administrator during the initial configuration of Proxedo API Security.

6.1. Minimum configuration

It is possible to run PAS with a minimum, basic configuration. For a minimum configuration the following items need to be configured in the Web UI:

This basic configuration can be further improved with the completion of more configuration units later. The minimum configuration can also be used to test the installation settings.

6.2. Login Page

The main component of the Login page is the login form where the user needs to provide the credentials in order to be authorized to use the Web UI of Proxedo API Security.

As part of the initial configuration of Proxedo API Security, the administrator defines the necessary credentials, which can now be used.

Login Page for Proxedo API Security Web User Interface
Figure 3. Login page for Proxedo API Security Web User Interface

For accessing the Web User Interface:

  1. Enter the valid user credentials.

  2. Click the Log In button.

After a successful login, the user has access to the Proxedo API Security Web UI.

6.3. Proxedo API Security Web User Interface main page

The configuration elements are organized into a logical order for easier usage.

Proxedo API Security Web User Interface main page
Figure 4. Proxedo API Security Web User Interface main page

The PAS Web UI has the following navigation areas:

Navigation areas in the Proxedo API Security Web User Interface
Figure 5. Navigation areas in the Proxedo API Security Web User Interface

The navigation areas identified in Figure Navigation areas in the Proxedo API Security Web User Interface are described here in more details:

Left navigation area (1)

This navigation area (1) presents the navigation units available for configuration.
When opening up the Proxedo API Security Web UI, three main navigation units are available, that is, BRICKS, PLUGINS, and SERVICES.
These three main navigation units can be opened for further sub-navigation units by clicking on either the navigation item itself or on the arrow open arrow icon next to it. Alternatively, when the sub-navigation units are not in use, they can be hidden by clicking the arrow navigation icons next to the main navigation items, or similarly by clicking on the navigation item itself.

Top navigation area (2)

This Top navigation area (2) presents the Changes and the Status buttons in the top left corner and the Logout button in the top right corner.

Main configuration area (3)

This is the main configuration area of the Web UI. Any navigation unit selected in the Left navigation area (1) presents the configuration details in this Main configuration area (3). The configuration details can be edited in this area.
In case there are already configured parameters, those are displayed in a table in the Main configuration area (3).
In order to add more configuration details, select the New navigation button in the upper right corner.

The Main configuration area (3) provides the following navigation and activity options. Note that some of these activities are also available when the configuration parameters are presented in list view:

6.3.2. Naming Configuration components in the Web UI

When configuring the Proxedo API Security Web UI, name the configuration components with the usage of the English alphabet and numerals. When the name is composed of more than one word, use underscore. It is not allowed to use spacing or any special characters though.

6.4. BRICKS - Configuration units

Bricks are reusable components. They do not provide a complete security function themselves, instead, they are used as building blocks elsewhere (hence the name). They can be used by Plugins (like Selectors), or utilized by other bricks (like Extractors).

Certain Bricks are so called default objects, which are in 'read-only' state and cannot be configured or modified. Such default objects are listed in the following table:

Table 6. Default objects - BRICKS
Default object name Class

Always

Matcher

Never

Matcher

content_type_json

Matcher

content_type_json_regexp

Matcher

json_content

Matcher

content_type_xml_base

Matcher

content_type_xml_dtd

Matcher

content_type_xml_ext_parsed

Matcher

content_type_xml_regexp

Matcher

content_type_xml_text

Matcher

content_type_xml_text_ext_parsed

Matcher

xml_content

Matcher

error_policy

Error policy

enforcer_default

Error policy

insight_default

Error policy

These default objects are listed under the actual classes in the Web UI.

The BRICKS main page in the Web UI is as follows:

Bricks' main page in the Web User Interface
Figure 6. Bricks' main page in the Web User Interface
  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Click on the sub-navigation unit you would like to configure. The details of the sub-navigation menu open up in the Main configuration area.

6.4.1. Error Policy

Error Policies define how to proceed if a Plugin decides to have found an error. For example, when an Enforcer plugin decides that the call is invalid.

It is the error policy that enables the user to act differently in case the error appears in a request or a response.

Every Plugin has a default error policy, namely, the 'error_policy', except for the Enforcer and the Insight Plugins, which have their own default error policies already configured for usage, the enforcer_default and the insight_default error policies.

6.4.1.1. Configuring Error policies

Error policies can be configured from the BRICKS main menu item.

  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select Error Policy.

The configuration window that appears presents the default error policies, as listed in Default objects - BRICKS and the configuration values already set by the user:

Error policy’s main page in the Web User Interface
Figure 7. Error policy’s main page in the Web User Interface
  1. Click on the New navigation button to create an error policy.

Error Policies have default values for each of their fields.

An Error Policy contains the following settings:

Configuring error policies in the Web User Interface
Figure 8. Configuring error policies in the Web User Interface

The following table provides details on what values can be figured for an Error policy and what these values define for an Error policy. Configure the following options:

Table 7. Error policy configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

It is the name identifying the error policy. This name of the error policy can be referenced from other parts of the configuration, that is, the error policy is reusable.

Request

The available values are:

  • abort

  • log

Abort

It defines what action shall take place if there is an error on the request side:

  • abort: the request is denied if the Plugin fails. Use the other parameters to control the content of the error sent to the client.

  • log: the invalid requests are allowed, but are logged.

Request code

The values are available from a drop-down list. If the elements of the drop-down list are selected, it will make the list of the actual request codes visible. The applicable request code can be selected.

422

It provides the HTTP status code to be used when denying invalid requests.

Request message

The message can be provided in free text.

Request error

The reason is provided here in the HTTP response line when denying invalid requests.

Request silent

The parameter can be configured by switching it on or off. When it is switched on, the Plugins do not report on the denial of the invalid request. When it is turned off, the Plugins have the ability to report the error in detail in the body of the HTTP error request.

true

Do not report validation errors of the request to the client.

Response

Response error mode:

  • abort

  • log

Abort

It defines what action shall take place if there is an error on the request side:

  • abort: the request is denied if the Plugin fails. Use the other parameters to control the content of the error sent to the client.

  • log: the invalid requests are allowed, but are logged.

Response code

The values are available from a drop-down list. Note that the response codes are grouped, so that if the elements of the drop-down list are selected, further groups of response codes will be made visible in a tree structure. The applicable request code can be selected.

502

It provides the HTTP status code to be used when denying invalid requests.

Response message

The message can be provided in free text.

Response error

The reason is provided here that can be used in the HTTP response line when denying invalid requests.

Response silent

The parameter can be configured by switching it on or off. When it is switched on, the Plugins do not report on the denial of the invalid response. When it is turned off, the Plugins have the ability to report the error in detail in the body of the HTTP error response.

true

Do not report validation errors of the response to the client.

The default values in the above table represent the hard coded default values. They form a strict security policy: all errors are fatal, and only mistakes made by the client are reported in detail.

For configuring error policies, continue with completing the following steps:

  1. Configure the necessary parameters for the error policy based on the details provided in the table Error policy configuration options.

  2. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  3. Click the Save button.

The default values in the above table represent the hard coded default values. They form a strict security policy: all errors are fatal, and only mistakes made by the client are reported in detail.

The error policies configured here can be used in the Plugin’s configuration, by referencing their name.

6.4.2. Matcher

Matchers decide if the Plugin should be executed for a given call by checking various data in the HTTP message. They provide an extremely versatile way of defining the circumstances that must be met for the Plugin to execute.

Matchers need three pieces of information:

  • Name: The name of the matcher defines what part of the call needs to be checked.

  • Pattern: The pattern defines what it needs to be compared with.

  • Comparator: The Comparator shows by what means the collected value of the call is compared with the provided pattern. (Some comparators also take flags or arguments.)

The matchers can be used in Plugin configurations' match option by referencing their name.

There are some named Matchers available without explicit configuration:

  • always and never are instances of Always matcher and Never matcher.

  • json_content that matches requests with the Content-Type headers representing JSON.

Also note that no other matchers can be defined with these names.

Matchers internally utilize Extractors to fetch the information from the call to compare with. The Name of the matcher resembles the name of the extractor that will be used.

All matchers have a default comparator that is applied implicitly.

If you want to use comparator parameters, the comparator name should be given even if the default comparator is used.
6.4.2.1. Configuring Matchers

Matchers can be configured from the BRICKS main navigation item.

  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select Matcher.

The configuration window that appears presents the default matchers, as listed in Default objects - BRICKS and the configuration values already set by the user:

Matchers' main page in the Web User Interface
Figure 9. Matchers' main page in the Web User Interface
  1. Click on the New navigation button to configure a matcher.

The generic configuration page for matchers provides the following settings:

Configuring matchers in the Web User Interface
Figure 10. Configuring matchers in the Web User Interface

The configuration parameters for matchers are described in details in the following table:

Table 8. Matcher configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name of the matcher defines what part of the call needs to be checked. Matchers internally utilize Extractors to fetch the information from the call to compare with. The Name of the matcher resembles the name of the extractor that will be used.

Type*

It is a mandatory value. For the available values, see Matcher types.

The preferred matcher type has to be selected from the drop-down list.

  1. Provide the name of the matcher.

  2. Choose the type of the matcher from the drop-down list.

Matcher types

Depending on the choice of the matcher type, some more required configuration fields might appear on this page. The following tables describe the matcher types in details and provide the necessary information for the additional configuration fields, required for setting the matcher types:

Table 9. Matcher types and their settings - Simple matchers
Matcher type Description

Always

This matcher always matches.

Never

This matcher never matches. It can be used to turn off a Plugin.

Call direction

It matches the direction of the message (request or response).

Method

It matches the HTTP method of the request. Note that the method is case insensitive by definition, therefore the case will always be ignored.

When choosing the Method matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Header

It matches the value of an HTTP header. Some HTTP headers can be present more than once in a call. To accommodate this, matching is completed against the value of each occurrence of the header. Matching occurs if there is any match. For example, if the Accept header was repeated as follows:

Accept: application/json
Accept: application/xml

Consequently, in this example above both header.accept: application/json and header.accept: application/xml would match.

To match against the header named Server the key will be header.server, possibly completed with comparator specification, like header.server.regex.ignorecase.

While the values are not, the HTTP header names are case insensitive, so you can write them all lowercase in the configuration key.

The syntax of this matcher differs from the others because the name of the Header name must be added.

While the values are not, the HTTP header names are case insensitive, so you can write them all lowercase in the configuration key.

When choosing the Header matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Content type

It matches the content type of the message. It is a more robust solution than using the Header matcher on the Content-Type header because that can contain parameters as well.

When choosing the Content type matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Status

It matches the status code of the response.

See the default Status class comparator which allows convenient matching on HTTP status classes.

The available values for the Expression parameter are: Informational response, Successful response, Redirects, Client errors, Server Errors.

When choosing the Status matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Raw content

It matches the original content of the message. If the content type is JSON, the body will be decompressed but not parsed.

When choosing the Raw content matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

xpath

It matches the data from the body of an XML call with the help of the Xpath expression.

Xpath is a query language for XML. It is a very versatile tool for extracting the needed information from the body of the call, and organizing it according to needs.

A complete explanation on how to write Xpath expressions is not in the scope of this document. To learn more about it visit the main website.

For more details on xpath configuration options, see Xpath extractor configuration options.

When choosing the Call direction matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

JMESPath

It matches the data from the body of a JSON call with the help of the JMESPath expression. JMESPath is a query language for JSON. It is a very versatile tool for extracting the needed information from the body of the call, and for organizing it according to needs. A complete explanation on how to write JMESPath expressions is not in the scope of this document.

To learn more about it visit the: main website:

When choosing the JMESPath matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Table 10. Matcher types and their settings - Compound matchers

Any

Any is a Compound matcher that matches if any of its sub-matchers matches. The sub-matcher can also be a compound matcher.

All

All is a Compound matcher that matches if all of its sub-matchers match. The sub-matcher can also be a compound matcher.

None

None is a Compound matcher that matches if none of its sub-matchers match. The sub-matcher can also be a compound matcher.

One

One is a Compound matcher that matches if exactly one of its sub-matchers matches. The sub-matcher can also be a compound matcher.

Table 11. Matcher types and their settings - URI matchers
Matcher type Description

URI matchers

A range of matchers is available to match different parts of the URI.

The structure of an URI looks as follows:

scheme://[username[:password]@]host[:port][/path][?query][#fragment]

That is, for example:

https://john.doe:secret123@example.com:8443/some/resource?foo=bar&baz=qux#some-anchor
The fragment part is used by the client locally, and is never sent in the HTTP requests, therefore the PAS cannot do anything with it.

These matchers use the URI extractors. It has an extensive list of examples of what each extractor extracts from the URI.

URI

It matches against the whole request URI as received from the client.

When choosing the URI matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI netloc

It matches the network location in the URI.

It includes:

  • scheme

  • host

  • port if present, unless the default port for the scheme is used

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included, even if explicitly sent by the client. Therefore if the client used http://example.com:80/path, then the origin would be http://example.com, not http://example.com:80.

When choosing the URI netloc matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI origin

It matches the origin part of the URI.

It includes:

  • scheme

  • host

  • port if present, unless the default port for the scheme is used

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included, even if explicitly sent by the client. Therefore if the client used http://example.com:80/path, then the origin would be http://example.com, not http://example.com:80.

When choosing the URI origin matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI scheme

It matches the scheme of request (http or https). Note that the scheme is case insensitive by definition, therefore the case will always be ignored.

When choosing the URI scheme matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI username

It matches the username in the request if present.

When choosing the URI username matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI password

It matches the password in the request if present.

When choosing the URI password matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI host

It matches the host in the request.

When choosing the URI host matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI port

It matches the port of the request. Note that this matches the default port —  that is 80 and 443 for HTTP and HTTPS, respectively — even if it is not explicitly in the request.

When choosing the URI port matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI path

It matches the path part of the URI.

It includes:

  • scheme

  • host

  • port if present, unless the default port for the scheme is used

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included, even if explicitly sent by the client. Therefore if the client used http://example.com:80/path, then the origin would be http://example.com, not http://example.com:80.
If you need to match the _path_ exactly as received, use URI raw path matcher.

When choosing the URI path matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI raw path

It matches the path part of the URI, without the normalization of URI path matcher carried out.

If the path is missing, the match still runs against a single forward slash ("/").

It is recommended to use URI path matcher unless there is an explicit need for matching the raw path. One such example would be logging or filtering out badly formed requests.

When choosing the URI raw path matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI raw query

It matches the query part of the URI as a string. It is recommended to use URI query parameter matcher unless there is an explicit need for matching the raw string. An example on this might be if there is a match on foo=barbar or tofoo=bar as well, even though it was not intended.

When choosing the URI raw query matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

URI query parameter

It matches the value of a query parameter.

It is also valid for URIs to include a query parameter more than once. That is, it could be foo=bar&qux=quz&foo=baz. To accommodate this, matching is done against the value of each occurrence of the parameter. Matching occurs if any value is matched.

When choosing the URI query parameter matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

When choosing the URI query parameter matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Table 12. Matcher types and their settings - Soap matchers
Matcher type Description

Soap Matchers

A range of matchers is available to match different parts of the SOAP message.

These matchers extend the [xpath-matcher] matcher with predefined expressions.

They use the [soap-extractors]. It has an extensive list of examples of what each extractor extracts from the SOAP message.

When choosing the SOAP Matchers matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap version

Soap version matches the soap message version. It identifies with the soap namespace.

The possible values are:

  • soapv1_1 - the message version is SOAP v1.1

  • soapv1_2 - the message version is SOAP v1.2

When choosing the SOAP version matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap envelope

It matches the soap envelope.

When choosing the SOAP envelope matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap header

It matches the soap header.

When choosing the SOAP header matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap body

It matches the soap body.

When choosing the SOAP body matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap fault

It matches the soap fault.

When choosing the SOAP fault matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap fault code

Soap matchers extend the xpath matcher with predefined expressions.

They use the SOAP extractors. It has an extensive list of examples of what each extractor extracts from the SOAP message.

It matches the soap fault 'code'. The expression depends on the soap version.

  • faultcode - it is the SOAP v1.1 node tag.

  • Code - it is the SOAP v1.2 node tag.

When choosing the SOAP fault code matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap fault detail

It matches the soap fault 'detail'. The expression depends on the soap version.

  • Detail - it is the SOAP v1.1 node tag.

  • Detail - it is the SOAP v1.2 node tag.

When choosing the SOAP fault details matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap 11 fault faultstring

It matches the soap fault 'faultstring'. This matcher only works with soap version 1.1.

When choosing the Soap 11 fault faultstring matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap 11 fault faultactor

It matches the soap fault 'faultactor'. This matcher only works with soap version 1.1.

When choosing the Soap 11 fault faultactor matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap 12 fault reason

It matches the soap fault 'Reason'. This matcher only works with soap version 1.2.

When choosing the Soap 12 fault reason matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap 12 fault node

It matches the soap fault 'Node'. This matcher only works with soap version 1.2.

When choosing the Soap 12 fault node matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

Soap 12 fault role

It matches the soap fault 'Role'. This matcher only works with soap version 1.2.

When choosing the Soap 12 fault role matcher from the drop-down list, additional parameters appear. For more information on the configuration of these parameters, see Matcher types' additional configuration options.

For details on comparator types, see Types of comparators.

Depending on the matcher type selected, the administrator might need to fill in further parameters. These parameters are described in the following table.

Table 13. Matcher types' additional configuration options
Key Values Default value Description

Comparator

The matchers need the information on the Comparator, which shows by what means the collected value of the call is compared with the provided pattern.

Type

The available comparator types can be checked from the drop-down list.

This configuration option has to be defined for the Comparator. For details on the comparator types, see Types of comparators.

Ignorecase

Off (False)

This configuration option has to be defined for the Comparator. It sets the IGNORECASE flag for the selected comparator type.

Expression*

This configuration option has to be defined for the Comparator. A regular expression specifies a set of strings that match it.

JmesPath Expression

A complete explanation on how to write JMESPath expressions is not in the scope of this document.

To learn more about it visit the: main website:

Query Parameter

It is also valid for URIs to include a query parameter more than once. That is, it could be foo=bar&qux=quz&foo=baz. To accommodate this, matching is done against the value of each occurrence of the parameter. Matching occurs if any value is matched.

Header

It extracts the value of an HTTP header. It is valid for some HTTP headers to be present more than once in a call. In this case, all the values are extracted as a list. It provides the name of the header in the configuration.

Namespaces

It defines the XML namespaces.

Xpath Expression*

The expression to extract the node from the call to match against.

Multiline

It sets the Multiline flag for the Regex comparator.

Minimum*

It matches if the pattern is larger or equal to the value.

Maximum*

It matches if the pattern is smaller or equal to the value.

  1. Configure the necessary parameters with the help of the above tables.

  2. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  3. Click the Save button to save the configured matcher.

6.4.3. Selector

Selectors are responsible for collecting information from the call. They utilize Extractor bricks for this purpose.

Most extractors return simple string values. However, some (might) return dictionaries. For example, you can get all the HTTP headers, or all the URI query parameters.

They are used by Insight.

6.4.3.1. Configuring Selectors

The selector can be configured from the BRICKS main navigation item.

  1. Click on BRICKS main configuration item in the left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select Selectors.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Selector main page in the Web User Interface
Figure 11. Selector main page in the Web User Interface
  1. Click on the New navigation button to configure the Selector.

The following configuration options appear for Selector:

Configuring Selector in the Web User Interface
Figure 12. Configuring Selector in the Web User Interface

The selector accepts the following configuration options:

Table 14. Selector configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name of the parameter can be referenced.

Type*

Choose the selector type from the drop-down list. For more details on the values, see Extractor types.

Extractors are used to extract data from the call. They are utilized by Selector (and Matcher as well). Extractors are included by their type in Selectors, and are used by a special syntax in matchers. For details, see Extractors and Extractor types.

Save as

The key under which the results of a selector are saved in the Insight plugin’s dictionary.

Top

If it is omitted, the result will be directly merged as top level keys. Name the configuration components with the usage of the English alphabet and numerals. When the name is composed of more than one word, use underscore. It is not allowed to use spacing or any special characters though.

Depending on what value is selected for the Type parameter, additional parameters might appear for configuration. The following table provides details on these additional parameters.

Table 15. Additional Selector configuration options
Key Values Default value Description

Clear text

It can be switched On or Off.

Namespaces

It defines the XML namespaces.

Xpath Expression

The expression to extract the node from the call to match against.

JmesPath Expression

A complete explanation on how to write JMESPath expressions is not in the scope of this document.

To learn more about it visit the: main website:

Expression*

A regular expression specifies a set of strings that match it.

Time format*

'YYYY-MM-DDTHH:mm:ss.SSSSSSZZ'

Set the format. See: Timestamp format options

Time zone*

It is the name of the time zone, or the time zone offset.
The time zone can be specified by using the name, for example, "Europe/Budapest", or as the time zone offset in +/-HH:MM format, for example, +01:00).

  1. Name the Selector key.

  2. Fill in any more desired parameters.

  3. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  4. Click the Save button if you have configured all the required parameters.

6.4.4. Target

Target bricks define where the data collected by the Insight will be sent to.

The Target configuration tree contains named Targets with their respective configuration.

Unlike other bricks, target configurations cannot be put inline into a Plugin’s configuration, they must always be configured here.

See the Target configuration options for the available target types and their configuration options.

6.4.4.1. Data flattening

To ensure compatibility with a wide range of target types, the results collected by the Insight plugin are flattened. The path inside the complex data structure is encoded into the key for each value:

  • The merged key describes the path to the value in the data structure as a string.

  • The parts of the path will be separated by a forward slash character ("/").

  • Keys in nested dictionaries are added to the path by name.

  • List items are added to the path by their index.

You can control the separator with the Flatten separator configuration key that every target accepts.
6.4.4.2. Configuring Targets

The Target can be configured from the BRICKS main navigation item.

  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select Target.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Target main page in the Web User Interface
Figure 13. Target main page in the Web User Interface
  1. Click on the New navigation button to configure the Target.

Configuring Target in the Web User Interface
Figure 14. Configuring Target in the Web User Interface

The Target accepts the following configuration options:

Table 16. Target configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

It is the name identifying the Target. This name of the Target can be referenced from other parts of the configuration.

Type*

It is a mandatory value. The values can be selected from the drop-down list. The available values are:

  • Local log

  • Syslog

  • Elastic

Flatten

This parameter can be switched 'on' or 'off'.

On (True)

Flatten the target message.

Flatten separator

/

It is the separator in the flattened message.

Level

3

It is the log level for the logged message.

Message

It is the message of the insight if present, otherwise it is empty.

It is the message part of the log message.

Tag

The value can be selected from a drop-down list.

info

It is the log tag for the logged message.

  1. Provide the name for your Target configuration.

  2. Select the Target type.

  3. Continue with the Syslog, Elastic and Local log configurations with the help of the following tables: Syslog Target configuration parameters, Elastic Target configuration parameters and Local log Target configuration parameters.

The following table presents the configuration parameters for the Local log Target type:

Table 17. Local log Target configuration parameters
Key Values Default value Description

Flatten separator

/

It is the separator in the flattened message.

Level

3

It provides the log level for the logged message.

Message

The message of the insight if present, otherwise it is empty.

It is the message part of the log message.

Tag

info

It is the log tag for the logged message.

The following table presents the configuration parameters for the syslog Target type:

Table 18. Syslog Target configuration parameters
Key Values Default value Description

Data format

The possible values are: sdata, json.

sdata

This is the data format of the insight.

Enable heartbeat

False

It enables sending heartbeat (-- MARK --) messages to the target.

Flatten

True

It flattens the target message.

Flatten Separator

/

It is the separator in the flattened message.

Flush lines

It specifies how many lines are flushed to a destination at a time. The Insights Director waits for this number of lines to accumulate and sends them off in a single batch. Increasing this number increases the throughput, as more messages are sent in a single batch, but also increases the message latency.

Heartbeat

  • Frequency: A number greater than or equal to 1.

  • Mode: The possible values are: 'idle' (heartbeat messages are only sent when there is no traffic towards the target) and 'periodical' (heartbeat messages are sent regardless of activity).

  • Frequency: 30

  • Mode: 'periodical'

  • Frequency: The number of seconds between heartbeat messages.

  • Mode: The operation mode of the heartbeat functionality.

Host*

It is the hostname of the syslog search instance.

IP protocol

The possible values are 4 and 6, corresponding to IPv4 and IPv6.

This determines the internet protocol version of the given driver.

Mask credit card numbers

False

It masks the middle section of recognised credit card numbers in any fields of the log message. Recognised credit cards are from one of the following issuers: American Express, Discover Card, Mastercard, VISA.

Remote Connection

  • Protocol: The available values are: TCP and UDP.

  • Port: The available values are integers.

  • Use TLS: The available values are True or False.

  • Syslog TLS*: Select the Syslog TLS brick you want to use for the target.

  • Protocol: TCP, Port 514

  • Protocol: UDP, Port: 601

  • Use TLS: False

  • Protocol: Add the transport protocol to send messages over. The available values are: TCP and UDP.

  • Port: Add the port number here to connect to the remote system.

  • Use TLS: It enables using TLS for the Syslog communication.

  • Syslog TLS*: It is mandatory if the Use TLS option is set to True.

Report config load

False

It reports the event of a configuration being loaded with a cryptographic hash of the loaded configuration. This ingorms the target about changes in the configuration.

Second fraction digits

Integer between 0 and 6 inclusive

3

The number of digits representing the fractions of seconds in the Syslog timestamp.

Time Zone

See table Time zones for time zone names.

GMT

The name of the time zone (for example, "Europe/Budapest") or the time zone offset in +/-HH:MM format (for example, +01:00).

The following table presents the configuration parameters for the elastic Target type:

Table 19. Elastic Target configuration parameters
Key Values Default value Description

Doc type

_doc

The doc type is used when sending the data.

Flatten

True

It flattens the target message.

Flatten Separator

/

It is the separator in the flattened message.

Host*

It is the hostname of the Elastic search instance.

Index

It is the name of the index in the Elastic search instance.

Mask credit card numbers

False

It masks the middle section of recognised credit card numbers in any fields of the log message. Recognised credit cards are from one of the following issuers: American Express, Discover Card, Mastercard, VISA.

Port

  • 514 for TCP

  • 601 for UDP

Add the port number here to connect to the remote system.

  1. Configure any more desired parameter details.

  2. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  3. Click Save to save your configuration settings for the Target.

6.4.5. TLS

Transport Layer Security (TLS) is the cryptographic protocol that secures HTTPS communications. PAS can apply TLS encryption both when communicating with Clients and Backends.

When HTTPS is used the TLS settings must be configured.

These parameters are used by the Transport director. For options that reference a file the path is relative to /opt/balasys/var/persistent/ inside the Transport Director container. This directory is a docker volume and by default mounted from the /opt/balasys/var/persistent/transport-director directory in the host system.
6.4.5.1. Configuring the TLS

TLS can be configured from the BRICKS main navigation item.

  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select TLS.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

TLS main page in the Web User Interface
Figure 15. TLS main page in the Web User Interface
  1. Click on the New navigation button to configure TLS.

TLS contains the following settings:

Configuring TLS in the Web User Interface
Figure 16. Configuring TLS in the Web User Interface

The configuration of the first two parameters determines the TLS type and from these two steps on, it is either a Client TLS configuration or a Backend TLS configuration.

6.4.5.1.1. Configuring the Client TLS

The following parameters need to be configured for Client TLS:

Configuring TLS in the Web User Interface TLS options
Figure 17. Configuring Client TLS in the Web User Interface, TLS options
Configuring TLS in the Web User Interface Certificate options
Figure 18. Configuring Client TLS in the Web User Interface, Certificate options
  1. Name the Client TLS configuration.

  2. Select the Type of the TLS, Client TLS in this case, from the drop-down list to configure TLS.

For details on these parameters, see the following table:

Table 20. TLS configuration
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name of the parameter can be referenced.

Type*

It is a mandatory value. Choose the required value from the drop-down list.

Client TLS, Backend TLS and Syslog TLS configurations can be defined here.

  1. Configure the mandatory parameters for Client TLS, based on the information provided in Table Client TLS configuration.

Table 21. Client TLS configuration
Key Values Default value Description

Certificate*

Configuration for the X.509 certificate used for TLS connections on the listener.

Certificate File*

It is a mandatory value. You can upload the certificate file.

Provide the path and filename for the certificate file. The certificate must be in PEM format.

Key file*

It is a mandatory value. You can upload the key file.

Provide the path and filename to the private key file. The private key must be in PEM format.

Key passphrase

You can upload the file.

Provide the passphrase used to access the private key specified in the Key file.

Enable Verification*

Off (False)

It is an option for verifying client side X.509 certificates. By default no client verification takes place.

Client verification*

Client verification options

Trusted Certs

You can upload trusted certificates in a ZIP file.

A directory where trusted IP addresses, certificate assignments are stored. When a peer from a specific IP address shows the certificate stored in this directory, it is accepted regardless of its expiration or issuer CA. Each file in the directory should contain a certificate in PEM format. The filename must be the IP address.

Required

The parameter can be switched on or off.

On (true)

If it is set to True, PAS requires a certificate from the peer.

Trust Level

The values can be selected from the drop-down list. The available values are:

  • none

  • untrusted

  • full

full

It defines the trust level for certificate verification:

  • none: Accept even invalid certificates, for example self-signed certificates.

  • untrusted: Both trusted and untrusted certificates are accepted.

  • full: Only valid certificates signed by a trusted CA are accepted.

Verify Depth

4

It defines the length of the longest accepted CA verification chain. PAS will automatically reject longer CA chains.

Ca Dir

You can upload the trusted CAs in a ZIP file

It is a Directory where where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when PAS verifies the certificate of the peer.

Verify Crl

The parameter can be switched on or off.

Off (false)

If it is set to True, PAS checks the CRLs (Certificate Revocation Lists) associated with trusted CAs. CRLs will load automatically if PAS verifies the certificate of the peer.

Intermediate Revocation Check Type

The values can be selected from the drop-down list. The available values are:

  • none

  • soft_fail

  • hard_fail

hard_fail

The revocation check type for all certificates in the chain, except the Leaf Certificate:

  • none: Ignore the result certificate revocation status check

  • soft_fail: It fails if the check is successful and the certificate is revoked, it will pass otherwise

  • hard_fail: It passes only if the check is successful and the certificate is not revoked

Leaf Revocation Check Type

The values can be selected from the drop-down list. The available values are:

  • none

  • soft_fail

  • hard_fail

hard_fail

The revocation check types for the Leaf certificate are as follows:

  • none: With this option the result of the certificate revocation status check is ignored

  • soft_fail: It fails if the check is successful and the certificate is revoked, it passes otherwise

  • hard_fail: It passes only if the check is successful and the certificate is not revoked

Options*

TLS protocol options used on the listener.

Disable TLS v1

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

On (true)

Transport Layer Security v1 (TLS) (successor of the now obsoleted Secure Socket Layer v3 (SSL)) is a widely used crypto protocol, guaranteeing data integrity and confidentiality in many PKI and e-commerce systems.

Disable TLS v1.1

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1.1 in the connection.

On (true)

It does not allow the usage of TLSv1.1 in the connection.

Disable TLS v1.2

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1.2 in the connection.

Off (false)

It does not allow the usage of TLSv1.2 in the connection.

Disable TLS v1.3

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1.3 in the connection.

false

It does not allow the usage of TLSv1.3 in the connection.

Cipher

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

Specifies the allowed ciphers. Can be set to all, high, medium, low, or a string representation of the selected ciphers.

Timeout

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

300

It drops idle connection if the timeout value (in seconds) expires.

Session Cache Size

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

20480

It defines the number of sessions stored in the session cache for SSL session reuse

Disable Session Cache

The parameter can be switched on or off.

Off (false)

Do not store session information in the session cache. Set this option to 'on' to disable SSL session reuse.

Disable Ticket

The parameter can be switched on or off.

Off (false)

Do not store session information in the session cache. Set this option to 'on' to disable SSL session reuse.

Disable Compression

The parameter can be switched on or off.

Off (false)

Set the parameter On to disable support for SSL/TLS compression. Set the parameter Off to enable support for SSL/TLA compression.

Cipher Server Preference

The parameter can be switched on or switched off.

On (true)

Use server and not client preference order when determining which cipher suite, signature algorithm or elliptic curve to use for an incoming connection.

Disable Renegotiation

The parameter can be switched on or off.

On (true)

Set this parameter On to disable client-initiated renegotiation.

Dh Parameter File

You can upload the DH parameter file. The DH parameter file must be in PEM format.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Save the Client TLS configuration by clicking Save.

6.4.5.1.2. Configuring Backend TLS

The following parameters need to be configured for Backend TLS:

Configuring Backend TLS in the Web User Interface TLS options
Figure 19. Configuring Backend TLS in the Web User Interface, TLS options
Configuring Backend TLS in the Web User Interface Certificate options
Figure 20. Configuring Backend TLS in the Web User Interface, Certificate options
  1. Name the Backend TLS configuration.

  2. Select Backend TLS from the drop-down list to configure Backend TLS.

For details on these parameters, see the following table:

Table 22. TLS configuration
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name of the parameter can be referenced.

Type*

It is a mandatory value. Choose the required value from the drop-down list.

Client TLS, Backend TLS and Syslog TLS configurations can be defined here.

  1. Configure the mandatory parameters for Backend TLS, based on the information provided in Table Backend TLS configuration.

The configuration parameters are described in details in the following table:

Table 23. Backend TLS configuration
Key Values Default value Description

Enable Certificate*

Off/False

It is an option for enabling backend side X.509 certificates. By default no backend verification takes place.

Enable Verification*

Off/False

It is an option for verifying Backend side X.509 certificates. By default no backend verification takes place.

Backend verification*

Backend verification options

Trusted Certs

You can upload trusted certificates in a ZIP file.

A directory where trusted IP addresses-certificate assignments are stored. When a peer from a specific IP address shows the certificate stored in this directory, it is accepted regardless of its expiration or issuer CA. Each file in the directory should contain a certificate in PEM format. The filename must be the IP address.

Trust Level

The values can be selected from the drop-down list. The available values are:

  • none

  • untrusted

  • full

full

It defines the trust level for certificate verification:

  • none: Accept even invalid certificates, for example self-signed certificates.

  • untrusted: Both trusted and untrusted certificates are accepted.

  • full: Only valid certificates signed by a trusted CA are accepted.

Verify Depth

4

It defines the length of the longest accepted CA verification chain. PAS will automatically reject longer CA chains.

Ca Dir

You can upload the trusted CAs in a ZIP file.

It is a directory where the trusted CA certificates are stored. CA certificates are loaded on-demand from this directory when PAS verifies the certificate of the peer.

Verify Crl

The parameter can be switched on or off.

Off (false)

If it is set to True PAS checks the CRLs (Certificate Revocation Lists) associated with trusted CAs. CRLs will load automatically if PAS verifies the certificate of the peer.

Intermediate Revocation Check Type

The values can be selected from the drop-down list. The available values are:

  • none

  • soft_fail

  • hard_fail

soft_fail

The revocation check types for all certificates in the chain, except for the Leaf Certificate are as follows:

  • none: If this options is set, the certificate revocation status check results are ignored

  • soft_fail: If this option is set, the certificate revocation check fails, if the check is successful and the certificate is revoked. The check passes otherwise.

  • hard_fail: If this option is set, the check passes only if the check is successful, and the certificate is not revoked.

Leaf Revocation Check Type

The values can be selected from the drop-down list. The available values are:

  • none

  • soft_fail

  • hard_fail

soft_fail

The revocation check type for the Leaf Certificate.

  • none: The result of the Certificate Revocation Status Check is ignored.

  • soft_fail: If this option is set, the certificate revocation check fails, if the check is successful and the certificate is revoked. The check passes otherwise.

  • hard_fail: If this option is set, the check passes only if the check is successful, and the certificate is not revoked.

Check Subject

The parameter can be switched on or off.

Off (false)

If it is set to, PAS compares the subject of the server-side certificate with application-layer information (for example, it checks whether the Subject matches the hostname in the URL).

Options*

TLS protocol options used on the listener.

Disable TLS v1

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

On (true)

Transport Layer Security v1 (TLS) (successor of the now obsoleted Secure Socket Layer v3 (SSL)) is a widely used crypto protocol, guaranteeing data integrity and confidentiality in many PKI and e-commerce systems.

Disable TLS v1.1

The parameter can be switched on or off. If it is set ON it does not allow using TLS v. 1.1 in the connection.

On (true)

It does not allow the usage of TLS v. 1.1 in the connection.

Disable TLS v1.2

The parameter can be switched on or off. If it is set ON it does not allow using TLS v. 1.2 in the connection.

false

It does not allow the usage of TLS v. 1.2 in the connection.

Disable TLS v1.3

The parameter can be switched on or off. If it is set to ON it does not allow using TLS v. 1.3 in the connection.

false

It does not allow the usage of TLS v. 1.3 in the connection.

Cipher

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

Specifies the allowed ciphers. Can be set to all, high, medium, low, or a string representation of the selected ciphers.

Timeout

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

300

It drops idle connection if the timeout value (in seconds) expires.

Session cache size

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

20480

It defines the number of sessions stored in the session cache for SSL session reuse

Disable session cache

The parameter can be switched on or off.

Off (false)

Do not store session information in the session cache. Set this option to 'On' to disable SSL session reuse.

Disable ticket

The parameter can be switched on or off.

Off (false)

Do not store session information in the session cache. Set this option to 'On' to disable SSL session reuse.

Disable compression

The parameter can be switched on or off.

Off (false)

Set the parameter On to disable support for SSL/TLS compression. Set the parameter Off to enable support for SSL/TLA compression.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Click the Save button if you have configured all the required parameters.

6.4.5.1.3. Revocation checks for certificates

The PAS tries both CRL and OCSP-stapling checks for certificates.

The result for a certificate according to the revocation check types:

Table 24. Certificate revocation checks
CRL check OCSP stapling check Soft fail result Hard fail result

PASS

PASS

PASS

PASS

PASS

unsuccessful

PASS

PASS

unsuccessful

PASS

PASS

PASS

unsuccessful

unsuccessful

PASS

FAIL

PASS

FAIL

FAIL

FAIL

FAIL

PASS

FAIL

FAIL

unsuccessful

FAIL

FAIL

FAIL

FAIL

unsuccessful

FAIL

FAIL

FAIL

FAIL

FAIL

FAIL

6.4.5.1.4. Configuring Syslog TLS

The following parameters need to be configured for Syslog TLS:

Configuring Syslog TLS in the Web User Interface
Figure 21. Configuring Syslog TLS in the Web User Interface
  1. Name the Syslog TLS configuration.

  2. Select the Type of the TLS, Syslog TLS in this case, from the drop-down list to configure TLS.

For details on these parameters, see the following table:

Table 25. TLS configuration
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name of the parameter can be referenced.

Type*

It is a mandatory value. Choose the required value from the drop-down list.

Client TLS, Backend TLS and Syslog TLS configurations can be defined here.

  1. Configure the mandatory parameters for Syslog TLS, based on the information provided in Table Syslog TLS configuration.

Table 26. Syslog TLS configuration
Key Values Default value Description

Certificate*

It is the configuration for the X.509 certificate used for TLS connections on the target.

Certificate File*

It is a mandatory value. You must select a File brick of type generic that represents the uploaded certificate.

Provide the name of the selected File brick. The certificate must be in PEM format.

Key file*

It is a mandatory value. You can select a File brick of type generic that represents the uploaded private key.

Provide the name of the selected File brick. The private key must be in PEM format.

Enable Verification*

Off (false)

It is an option for enabling the verification of server side X.509 certificates.

Options*

TLS protocol options used on the Syslog target.

Disable SSL v2

The parameter can be switched on or off.

On (true)

Session tickets are a method for SSL session reuse, described in RFC 5077. Set this option to ON to disable SSL session reuse using session tickets.

Disable SSL v3

The parameter can be switched on or off.

On (true)

Session tickets are a method for SSL session reuse, described in RFC 5077. Set this option to ON to disable SSL session reuse using session tickets.

Disable TLS v1

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1 in the connection.

On (true)

Transport Layer Security v1 (TLS) (successor of the now obsoleted Secure Socket Layer v3 (SSL)) is a widely used crypto protocol, guaranteeing data integrity and confidentiality in many PKI and e-commerce systems.

Disable TLS v1.1

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1.1 in the connection.

On (true)

It does not allow the usage of TLSv1.1 in the connection.

Disable TLS v1.2

The parameter can be switched on or off. If it is set ON it does not allow using TLSv1.2 in the connection.

Off (false)

It does not allow the usage of TLSv1.2 in the connection.

ECDH curve list

Add one or more names of ECDH curves. The possible values are the ones supported by OpenSSL 1.1.1.

Off (false)

This is a list of curves permitted in the connection when using Elliptic Curve Cryptography (ECC).

Peer verify

Select one of the following options in the drop-down menu: optional-trusted, optional-untrusted, required-trusted, required-untrusted

required-trusted

It defines the verification method of the peer. The four possible values are a combination of two properties of validation: whether the peer is required to provide a certificate (required or optional prefix), and whether the certificate provided needs to be valid (trusted or untrusted suffix).

Cipher

It is the colon-separated list of ciphers from the list supported by OpenSSL 1.1.1.

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!aNULL:!MD5:!DSS!aNULL: !MD5: !DSS

It specifies the allowed ciphers.

DH Parameter File

Select a File brick of type generic from the drop-down menu.

It specifies the file containing the Diffie-Hellman parameters, generated using the openssl dhparam utility. It must be in PEM format.

Server verification*

Server verification options are mandatory if Enable Verification is set to True.

Trusted DN

It is a list of the distinguished names of the accepted certificates.

You can list the distinguished names of the accepted certificates in this parameter to accept connections only from hosts using certain certificates signed by the trusted CAs. For example, when using "*, O=Example Inc, ST=Some-State, C=*", it will accept only certificates issued for the Example Inc organization in Some-State state.

CA dir

Select the CA File brick representing your CA directory.

CA directory containing the trusted CA and CRL files.

Verify CRL

Off (false)

It verifies that certificates used in the connection are not revoked by any CRLs in the CA directory.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Save the Syslog TLS configuration by clicking Save.

6.4.6. Files

The Files configuration element enables the administrator to upload any certificate files.

6.4.6.1. Configuring Files

Files can be configured from the BRICKS main navigation item.

  1. Click on BRICKS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of BRICKS.

  2. Select Files.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Files main page in the Web User Interface
Figure 22. Files main page in the Web User Interface
  1. Click on the New navigation button to configure Files.

Files contains the following settings:

Configuring Files in the Web User Interface
Figure 23. Configuring Files in the Web User Interface

Files has the following configuration parameters:

Table 27. Files configuration parameters
Key Values Default Description

Name*

It is a mandatory value. The name can be provided in free text.

It defines the file-related configuration.

Type*

It is a mandatory value. The available values are:

  • Generic

  • Swagger

  • XSD

  • WSDL

  • CA

  • CRL

See table Requirements for specific file types for specific requirements for each type.

The type selected here defines by which PLUGIN it can be used. The file uploaded here with the Type Swagger, for example, can be used by Swagger Plugins.

File*

It is a mandatory value. The required file can be uploaded here.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Save the configuration by clicking the Save button.

Table 28. Requirements for specific file types
File type Requirements

CA

  1. It must be a flat ZIP file with the CA certificates inside.

  2. It must contain not only the certificate files but also copies of them named following the <hash>.0 format. The value of the <hash> part can be produced with the following command: openssl x509 -noout -hash -in /path/to/cert/file.

  3. It can contain CRL files, but then it also needs to contain the copies of them following the <hash_of_the_related_ca_file.r0 format. The hash can be produced as described above.

6.4.7. Common configuration elements for BRICKS

6.4.7.1. Extractors

Extractors are used to extract data from the call.

Extractors are not independent configuration components, but common configuration elements that are utilized by Matchers and Selectors. In fact, when configuring matchers and selectors, it is extractors that are listed at their type fields. Extractors are configured and used as part of matchers and selectors. There are no named extractors.

Most extractors return simple string values. However, some (might) return dictionaries. For example, you can get all the HTTP headers, or all the URI query parameters.

See the Extractor types for more details on extractors and their configuration options.

The following table provides details on extractor types:

Table 29. Extractor types
Key Description

Method

It extracts the HTTP method of the request. It does not require configuration.

Status

It extracts the status code of the response. It does not require configuration.

JMESPath

It extracts data from the body of a JSON call with the help of a JMESPath expression.

JMESPath is a query language for JSON. It is a very versatile tool for extracting the needed information from the body of the call, and organizing it according to requirements. A complete explanation on how to write JMESPath expressions is not in the scope of this document.

To learn more about it visit the: main website:

Header

It extracts the value of an HTTP header. It is valid for some HTTP headers to be present more than once in a call. In this case, all the values are extracted as a list. It provides the name of the header in the configuration.

Header force list

It works like the Header extractor but it returns a list even if there is only a single extracted value.

Header first

It works like header extractor but it only returns the first extracted value even if there is a list of extracted values.

Headers

It extracts all the headers from the call. The results are stored as a dictionary, therefore it is recommended to omit the 'save as' key if you use this from a selector. It is valid for some HTTP headers to be present more than once in a call. In such cases all the values are stored under the header’s key as a list. It does not require configuration.

URI

It matches against the whole request URI as received from the client. It does not require configuration.

URI netloc

It extracts the network location in the URI. It does not require configuration.

It includes:

  • username and password if present

  • host

  • port if present unless scheme default

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included even if explicitly sent by the client. So if the client used http://example.com:80/path then the netloc would be example.com, not example.com:80.

URI origin

It extracts the origin part of the URI. It does not require configuration.

It includes:

  • scheme

  • host

  • port if present, unless the default port for the scheme is used

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included, even if explicitly sent by the client. Therefore if the client used http://example.com:80/path, then the origin would be http://example.com, not http://example.com:80.

URI scheme

It extracts the scheme of the request (http or https). It does not require configuration.

URI username

It extracts the username in the request if present. It does not require configuration.

URI password

It extracts the password in the request if present. It does not require configuration.

URI host

It extracts the host in the request. It does not require configuration.

URI port

It extracts the port of the request, the default port — that is 80 and 443 for HTTP and HTTPS, respectively — even if it is not not displayed explicitly in the request. It does not require configuration.

URI path

It extracts the path part of the URI. It does not require configuration.

It includes:

  • scheme

  • host

  • port if present, unless the default port for the scheme is used

If the port is the default port for the scheme — that is 80 and 443 for HTTP and HTTPS, respectively — the port will not be included, even if explicitly sent by the client. Therefore if the client used http://example.com:80/path, then the origin would be http://example.com, not http://example.com:80.

If you need to extract the path exactly as received, use URI raw path parameter.

URI raw path

It extracts the path part of the URI, without the normalization of URI path carried out.

NOTE: If the path is missing a single forward slash ("/") is extracted.

It does not require configuration.

URI raw query

It extracts the query part of the URI as a string. It does not require configuration.

It does not require configuration.

URI query

It extracts the query part of the URI. It does not require configuration.

It does not require configuration.

URI query parameter

It extracts the value of a query parameter. It is also valid for URIs to include a query parameter more than once. That is, it could be 'foo=bar&qux=quz&foo=baz'. In this case both values are extracted as a list. Provide the name of the parameter in the configuration.

URI query parameter force list

It works like Uri query parameter but it returns a list even if there is only a single extracted value.

URI query parameter first

It works like Uri query parameter but it only returns the first extracted value even if there is a list of extracted values.

Content

It extracts the content. It does not require configuration.

Raw content

It extracts the content as a string. It does not require configuration.

Content type

It extracts the content type from the HTTP header. It does not require configuration.

Content type charset

It extracts the charset from the content type HTTP header. It does not require configuration.

Call direction

It extracts the call direction (request, response). It does not require configuration.

Session ID

It extracts the internal identifier of the HTTP session in keep-alive HTTP connections. Its 'Include request counter' option enables adding a request counter representing the number of requests in the session.

Static

It extracts a string, integer, number, object, array, boolean as string from the configuration.

Timestamp

It extracts the current time. Also see the tables on Configuring timestamps and Timestamp format options.

Xpath

It extracts data from the body of an XML call with the help of a Xpath expression.

Xpath is a query language for XML. It is a very versatile tool for extracting the needed information from the body of the call, and organizing it according to needs.

A complete explanation on how to write Xpath expressions is not in the scope of this document. To learn more about it visit the main website.

Also see table Xpath extractor configuration options.

Provide the Xpath expression in the configuration. Depending on the expression, the return value is a single node or a list of nodes. If you want a single value or a list independent from the expression, use xpath first or xpath force list.

Xpath force list

It works like xpath but it returns a list even if there is only a single extracted value.

Xpath first

It works like xpath but it only returns the first extracted value even if there is a list of extracted values.

Soap version

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap message version. It identify with the soap namespace.

Possible values:

  • soapv1_1 - the message version is SOAP v1.1

  • soapv1_2 - the message version is SOAP v1.2

Soap envelope

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap envelope.

Soap header

It extracts the soap header.

This extractor extends the xpath extractor with predefined expressions.

Soap body

It extracts the soap body.

This extractor extends the xpath extractor with predefined expressions.

Soap fault

It extracts the soap fault.

This extractor extends the xpath extractor with predefined expressions.

Soap fault code

It extracts the soap fault 'code'.

This extractor extends the xpath extractor with predefined expressions.

This extractor expression depends on the soap version.

  • faultcode - it is the SOAP v1.1 node tag

  • Code - it is the SOAP v1.2 node tag

Soap fault detail

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'detail'. This matcher expression depends on the soap version.

  • Detail - it is the SOAP v1.1 node tag

  • Detail - it is the SOAP v1.2 node tag

Soap 1.1 fault faultstring

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'faultstring'. This extractor only works with soap version 1.1.

Soap 1.1 fault faultactor

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'faultactor'. This extractor only works with soap version 1.1.

Soap 1.2 fault reason

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'Reason'. This extractor only works with soap version 1.2.

Soap 1.2 fault node

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'Node'. This extractor only works with soap version 1.2.

Soap 1.2 fault role

This extractor extends the xpath extractor with predefined expressions.

It extracts the soap fault 'Role'. This extractor only works with soap version 1.2.

You can still use Save as for extractors returning dictionaries. For example, you can save all the headers under the headers' key and the URI query parameters under the parameters' key.

Timestamp extractors can be configured as follows:

Table 30. Configuring timestamps
Name Default Description

Time zone

'UTC'

Set the time zone.

  • An str describing a time zone, similar to ‘US/Pacific’, or ‘Europe/Berlin’. See: [appendix-time zone]

  • An str in ISO 8601 style, as in ‘+07:00’.

  • An str, one of the following: ‘local’, ‘utc’, ‘UTC’.

format

'YYYY-MM-DDTHH:mm:ss.SSSSSSZZ'

Set the format. See: Timestamp format options

Table 31. Timestamp format options
Token Output

Year

YYYY
YY

2000, 2001, 2002 … 2012, 2013
00, 01, 02 … 12, 13

Month

MMMM
MMM
MM
M

January, February, March
Jan, Feb, Mar
01, 02, 03 … 11, 12
1, 2, 3 … 11, 12

Day of Year

DDDD
DDD

001, 002, 003 … 364, 365
1, 2, 3 … 364, 365

Day of Month

DD
D
Do

01, 02, 03 … 30, 31
1, 2, 3 … 30, 31
1st, 2nd, 3rd … 30th, 31st

Day of Week

dddd
ddd
d

Monday, Tuesday, Wednesday
Mon, Tue, Wed
1, 2, 3 … 6, 7

Hour

HH
H
hh
h

00, 01, 02 … 23, 24
0, 1, 2 … 23, 24
01, 02, 03 … 11, 12
1, 2, 3 … 11, 12

AM / PM

A
a

AM, PM, am, pm
am, pm

Minute

mm
m

00, 01, 02 … 58, 59
0, 1, 2 … 58, 59

Second

ss
s

00, 01, 02 … 58, 59
0, 1, 2 … 58, 59

Sub-second

S…

0, 02, 003, 000006, 123123123123
the result is truncated to microseconds, with half-to-even rounding

Time zone

ZZZ
ZZ
Z

Asia/Baku, Europe/Warsaw, GMT
-07:00, -06:00 … +06:00, +07:00, +08, Z
-0700, -0600 … +0600, +0700, +08, Z

Seconds Timestamp

X

1381685817, 1381685817.915482

ms or µs Timestamp

x

1569980330813, 1569980330813221

Table 32. Xpath extractor configuration options
Key Default Description

xpath_expression

It is the expression to extract the node from the call to match against.

namespaces

Defines the XML namespaces.

clear_text

False

It removes white spaces at the beginning and at the end of the string.

6.4.7.2. Comparators

Comparators are used for comparing the pattern with the result of the xpath expression.

Table 33. Types of comparators
Key Description Parameters

Equals

It matches if the parameter is exactly the same as the value matched.

Ignore case: Case differences (lower case, upper case) are ignored. When the present VaLuE would match value.

Not equals

It matches if the parameter is not exactly the same as the value matched.

Ignore case: Case differences are ignored. When the present VaLuE would not match vAlUe.

Starts with

It matches if the value starts exactly with the pattern.

Ignore case: Case differences are ignored. When the present VaLuE would match value_given.

Ends with

It matches if the value ends exactly with the pattern.

Ignore case: Case differences are ignored. When the present VaLuE would match given_value.

Substring

It matches if the exact pattern is found somewhere in the value.

Ignore case: Case differences are ignored. When the present VaLuE would match some-value-given.

Pattern

The Pattern treats the input as Unix shell-style wildcards. There are special characters used in shell-style wildcards:

  • '*' Matches everything.

  • '?' Matches a single character.

  • [seq] Matches any character in seq.

  • [|seq] Matches any character in seq.

For a literal match, wrap the meta-characters in brackets. For example, [?] matches a literal question-mark (?).

Ignore case: Case differences are ignored. When the present VaLuE would match some-value-given.

Regex

Regex treats input as a regular expression for matching. Consult Python’s regular expression documentation and their Regular Expression HOWTO.

  • Ignore case: It sets the IGNORECASE flag for the regex.

  • Multiline: It sets the MULTILINE flag for the regex.

Minimum

It matches if the pattern is larger or equal to the value.

Maximum

It matches if the pattern is smaller or equal to the value.

Range

It matches if the value is between the limits in the pattern, including boundaries. The format of the pattern must be minimum..maximum.

Status class

Status class is a special matcher for conveniently matching HTTP status code classes. It takes the name of the class and checks if the status code is in the given range as stated in Checking status code range.

Table 34. Checking status code range
Pattern Status code range Description

info

1xx

Informational response

success

2xx

Successful response

redirect

3xx

Redirects

client_error

4xx

Client Errors

server_error

5xx

Server Errors

6.5. PLUGINS - Configuration units

A plugin is an element of the security flow that applies a specific security function. Plugins have different types based on the role they do:

Plugins' main page in the Web User Interface
Figure 24. PLUGINS' main page in the Web User Interface

Plugins are named, so that they can be referenced in other parts of the configuration.

This means that Plugin configurations are reusable.

Certain Plugins are so called default objects, which are in 'read-only' state and cannot be configured or modified. Such default objects are listed in the following table:

Table 35. Default objects - PLUGINS
Default object name Key

default_json

Serializer

default_xml

Serializer

default_json

Deserializer

default_xml

Deserializer

default

Compressor

default

Decompressor

6.5.1. Common Plugin parameters

Regardless of what plugins do, all plugins share some common parameters.

Table 36. Plugins' common parameters
Key Values Default value Description

Matcher

The Matchers configured under BRICKS main configuration unit are listed here and can be selected from the drop-down list.

Always: If the value is not defined, the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If no matcher is configured the Plugin is always executed.

Error policy

The Error Policy configured under BRICKS are listed here can be selected from the drop-down list.

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. If no error policy is configured, the plugin type’s default error policy is applied. For details see Error Policy.

Both parameters are optional:

  • If no matcher is configured, the Plugin is always executed.

  • If no error policy is configured, the plugin type’s default error policy is applied.

Plugins are always named so that their names refer to a Plugin that represents a certain configuration. The names themselves are referenced from the Security Flow.

6.5.2. Enforcer

An Enforcer Plugin validates calls against externally defined schemas.

The Plugin supports validation against OpenAPI2.0 (Swagger) schemas, XSD schemas or WSDL schema.

Understanding the format of these schemas is not in the scope of this document. Further information is available at:

The Enforcer Plugin uses its own default error policy, that is, the 'enforcer_default' error policy. The Plugin overrides the following fields of the default error policy:

Table 37. Default Enforcer Error Policy
Policy Setting Default

request_code

422

request_message

Validation Error

Problems are considered errors that lead to the termination of the call. Problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

6.5.2.1. Configuring Enforcer Plugins

Enforcer plugins can be configured from the PLUGINS main navigation item.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Enforcer plugin.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

EnforcerPlugin’s main page in the Web User Interface
Figure 25. Enforcer Plugin’s main page in the Web User Interface

The following values can be configured for the Filter Plugin:

Configuring an enforcer plugin in the Web User Interface
Figure 26. Configuring an enforcer plugin in the Web User Interface

The Enforcer Plugin accepts the following configuration options:

Table 38. Enforcer Plugin’s configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

This name identifies the Enforcer Plugin. The name of the plugin can be referenced from other parts of the configuration.

Type*

It is a mandatory value. It can be selected from the drop-down list. The available values are:

  • Swagger

  • XSD

  • WSDL

This identifies the type of the Enforcer plugin.

Error policy

The error policies configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

enforcer_default

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. For details see [errorpolicies].

Matcher

The matchers configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

Always: If the value is not defined the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If omitted the Plugin is always executed.

Swagger/WSDL/Operations*

Depending on which type of the component was selected above, the following values are available:

  • The Swaggers defined under Files are listed here and can be selected from the drop-down list.

  • The WSDL files defined under Files are listed here and can be selected from the drop-down list.

  • XSD enforcer plugin configuration options for Operations can also be selected here. For details on parameters for Operations, see XSD enforcer plugin configuration options for Operations.

The Swagger enforcer Plugin validates against OpenApi2.0 schemas. WSDL enforcer Plugin validates against WSDL 1.0-1.1 schemas. XSD enforcer Plugin validates against XSD schemas.

XSD has the following configuration options for the Operations parameters:

Table 39. XSD enforcer plugin configuration options for Operations
Key Default Description

uri_path

*

It defines the pattern for uri_path.

Choose Method

It defines the method of the HTTP message. The following values are available for Method:

  • get

  • head

  • post

  • put

  • delete

  • connect

  • options

  • trace

  • patch

Status

It defines the status of the HTTP message.

Choose Call direction

It defines the direction of the message, which must be either request or response.

Choose files

It defines the XSD schema.

  1. Name the Enforcer Plugin.

  2. Choose the type of the Enforcer plugin.

  3. Choose an Error policy from the drop-down list. The drop-down list will offer the error policy options configured under Bricks.

  4. Choose a Matcher from the drop-down list. The drop-down list will offer the matcher options configured under Bricks.

  5. Depending on the choice of the Enforcer plugin type selected earlier, different fields appear here for further configuration:

    • Swagger - Upload the Swagger file if the Enforcer type selected at Type field was Swagger.

    • WSDL - Upload the WSDL file if the Enforcer type selected earlier was WSDL.

    • Operations - Fill in the Operations fields according to XSD enforcer plugin configuration options for Operations if the Enforcer type selected earlier was XSD.

  6. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  7. Click the Save button, when all required configuration fields have been defined.

6.5.2.2. Swagger

The Swagger enforcer Plugin validates against OpenApi2.0 schemas.

The Plugin needs the schema definition file of the API Endpoint. This file must be in JSON or YML format.

6.5.2.3. XSD

XSD enforcer Plugin validates against XSD schemas. Both XSD 1.0 and 1.1 are supported.

As XSD enforcer requires parsed XML content an xml deserializer plugin needs to be included before XSD enforcer.

In the XSD enforcer you can define operations. Each operation contains criteria for identifying the call, and path of an XSD schema. If the HTTP message meets all criteria, its content will be validated using the schema.

XSD enforcer schema must contain at least one operation.

6.5.2.4. WSDL

WSDL enforcer Plugin validates against WSDL 1.0-1.1 schemas.

As WSDL enforcer requires parsed XML content, an xml deserializer plugin needs to be included before WSDL enforcer.

The Enforcer Plugin uses its own default error policy, that is, the 'enforcer_default' error policy. The Plugin overrides the following fields of the default error policy:

Table 40. Default Enforcer Error Policy
Policy Setting Default

request_code

422

request_message

Validation Error

Problems are considered errors that lead to the termination of the call. Problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

The plugin needs the schema definition file. This file must be in XML format.

WSDL schema validates request and response as well. Make sure that wsdl enforcer included in request and response flow as well.
In simple cases — when the listener/endpoint is serving a single version of a single API endpoint — a matcher is usually not needed as the schemas define all known URLs in the API. If however multiple API endpoints are consolidated under a single endpoint definition, you can define multiple enforcers each matching on a sub-path by using an URI path matcher and putting them all in the Security Flow.

6.5.3. Filter

Filter Plugins are lightweight alternatives of Enforcer Plugins for filtering unwanted traffic. They only consist of a matcher and an error policy. If the matcher matches, the error policy is applied. This way you can use matchers inline, instead of creating a whole schema-based Enforcer Plugin for the simple use cases.

6.5.3.1. Configuring Filter Plugins

The Filter Plugin can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Filter plugin.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Filter Plugin’s main page in the Web User Interface
Figure 27. Filter Plugin’s main page in the Web User Interface

The following values can be configured for the Filter Plugin:

Configuring a filter plugin in the Web User Interface
Figure 28. Configuring a filter plugin in the Web User Interface

The Filter Plugin accepts the following configuration options:

Table 41. Filter Plugin’s configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name identifying the Filter Plugin. This name of the plugin can be referenced from other parts of the configuration.

Body

It can be defined in free text.

It is the body of the message sent in case an error policy is applied.

Content Type

This field defines the content type of HTTP error request sent, if the filter stops the call. It can be referenced by its name.

Error policy

The error policies configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

error_policy

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. For details see Error Policy.

Matcher

The matchers configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

Always: If the value is not defined the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If omitted the Plugin is always executed.

Make sure that any component referenced in the configuration of this component, for example an Error policy or a Matcher selected from the drop-down lists, must remain part of the configuration later as well. Removing any of the referenced components might lead to invalid configuration.
  1. Add the name of the Filter Plugin.

  2. Add the Body content for the error policy. (Optional)

  3. Define the Content type.

  4. Choose an error policy from the drop-down list. (Optional)

  5. Choose a matcher from the drop-down list. (Optional)

  6. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  7. Click the Save button, when all required configuration fields have been defined.

The Plugin does not override any of the default error policy options.

Problems are considered errors that lead to the termination of the call. Problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

If you omit the matcher, the Plugin will always be executed. For Filter plugins this means aborting all calls.

6.5.4. Insight

It is a Plugin that extracts various data from the call and sends it to external systems (log servers, SIEMs, and other data analysis tools).

6.5.4.1. Configuring Insight Plugins

The Insight Plugin can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Insight plugin.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Insight Plugin’s main page in the Web User Interface
Figure 29. Insight Plugin’s main page in the Web User Interface
  1. Click the New button to create an Insight Plugin configuration. The following values can be configured for the Insight Plugin:

Configuring an insight plugin in the Web User Interface
Figure 30. Configuring an insight plugin in the Web User Interface
Table 42. Insight Plugin’s configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name identifying the insight. This name of the insight can be referenced from other parts of the configuration.

Error policy

The error policies configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

insight_default

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. For details see Error Policy.

Matcher

The matchers configured under BRICKS - Configuration units are listed here and can be selected from the drop-down list.

Always: If the value is not defined the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If omitted the Plugin is always executed.

Message

It is a mandatory value. It can be defined in free text.

""

It is the message part of the log message.

Selectors*

A list of Selector that collect information from the call. They can be referenced by their name or can be defined inline.

Targets*

A list of Insight where the collected information will be sent to.

The Plugin uses the default Error policy by default, that is, the 'insight_default'.

The Plugin overrides the following fields of the default error policy:

Table 43. Default Insight Error Policy
Policy Setting Default

request

log

response

log

Problems are considered errors that only need to be logged. If that is overridden then problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

The Plugin collects the information from all the selectors and sends them to all the targets.

The collected information from all the selectors is arranged into a dictionary: a list of key — value pairs. The key can be configured in each selector. Certain selectors might return complex data structures, that are made up of other dictionaries and/or lists. To ensure compatibility with a wide range of target types, such results are flattened. The path inside the complex data structure is encoded into the key for each value. More details are available on this in Data flattening.

  1. Add the name of the Insight Plugin.

  2. Choose an error policy from the drop-down list. (optional)

  3. Choose a matcher from the drop-down list. (optional)

  4. Add the message content for the error policy. (optional)

  5. Choose a selector from the drop-down list.

  6. Define the target.

  7. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  8. Click the Save button, when all required configuration fields have been defined.

6.5.5. Serializer

The Serializer Plugin is responsible for serializing the structured data to the format of the HTTP message’s body.

Serialization needs to be done before compression. A typical Security Flow configuration starts with a Decompressor followed by a Deserializer and finishes with a Serializer followed by a Compressor. This ensures that transferred HTTP bodies are syntactically correct and that they are reconstructed to avoid transferring potentially crafted content.

The Serializer Plugin understands the Content-Type HTTP header and can work with JSON and XML content.

6.5.5.1. Configuring Serializer Plugins

The Serializer can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Serializer.

The configuration window that appears presents the default Serializers, as listed in Default objects - PLUGINS and the configuration values already set by the user:

Serializer’s main page in the Web User Interface
Figure 31. The serializer main page in the Web User Interface
  1. Click the New button to create a serializer configuration. The following values can be configured for the Serializer Plugin:

Configuring a serializer in the Web User Interface
Figure 32. Configuring a serializer in the Web User Interface

The table describes some more details on the serializer configuration parameters.

Table 44. Serializers' configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

It is the name identifying the serializer. This name of the serializer can be referenced from other parts of the configuration, that is, the Plugin is reusable.

Type*

It is a mandatory value. The value can be selected from a drop-down list. The value can be:

  • JSON

  • XML

There are two types of predefined (de)serializer plugins.

Error policy

The Error Policy configured under BRICKS are listed here can be selected from the drop-down list.

error_policy

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. If no error policy is configured, the plugin type’s default error policy is applied. For details see Error Policy.

Matcher

The Matchers configured under BRICKS main configuration unit are listed here and can be selected from the drop-down list.

Depending on which 'Type' was selected for the Serializer, the default value can be: json_content or xml_content.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If no matcher is configured the Plugin is always executed.

The Plugin does not override any of the default error policy options.

Problems are considered errors that lead to the termination of the call. Problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

Continue configuring the serializer with the following steps:

  1. Add the name of the serializer.

  2. Select the type of the Serializer.

  3. Choose an Error policy from the drop-down list.

  4. Choose a Matcher from the drop-down list.

  5. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  6. Click the Save button, when all required configuration fields have been defined.

6.5.6. Deserializer

It is a Plugin responsible for parsing the HTTP message’s body to structured data. This ensures that a message is well-formed. The structured data will also be consumed by other Plugins that operate on the body of the message.

A typical Security Flow configuration starts with a Decompressor followed by a Deserializer and finishes with a Serializer followed by a Compressor. This ensures that transferred HTTP bodies are syntactically correct and that they are reconstructed to avoid transferring potentially crafted content.

6.5.6.1. Configuring Deserializer Plugins

The Deserializer can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Deserializer plugin.

The configuration window that appears presents the default Deserializers, as listed in Default objects - PLUGINS and the configuration values already set by the user:

Deserializer’s main page in the Web User Interface
Figure 33. The deserializer’s main page in the Web User Interface
  1. Click the New navigation button to create a deserializer configuration.

The following values can be configured for the Deserializer Plugin:

Configuring a deserializer in the Web User Interface
Figure 34. Configuring a deserializer in the Web User Interface

The following table describes the deserializer configuration parameters in details:

Table 45. Deserializers' configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name identifying the deserializer. This name of the deserializer can be referenced from other parts of the configuration.

Type*

It is a mandatory value. The value can be selected from a drop-down list. The value can be:

  • JSON

  • XML

There are two types of predefined (de)serializer plugins.

Charset Conflict

  • drop: If this parameter is set to 'drop', the configuration instructs to drop the call in case there is conflict for the character set in the message’s header.

  • log: If the value is set to 'log', the system will use either type of the character set deifined and will log the error.

This parameter needs to be configured in case the 'Type' of the Deserializer is set to XML. In XML messages, there might be a conflict in the definition of the character set. The XML and the HTTP headers might instruct to use different character sets. The conflicting information on the character set can be configured to be handled in two different ways, that is the call dropped, or the call maintained and the error logged, depending on the settings of this parameter.

Error policy

The error policies configured under BRICKS - Configuration units are listed here can be selected from the drop-down list.

error_policy

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. For details see Error Policy.

Matcher

The matchers configured under BRICKS - Configuration units are listed here can be selected from the drop-down list.

Depending on which 'Type' was selected for the Deserializer, the default value can be: json_content or xml_content.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If omitted the Plugin is always executed.

The Plugin does not override any of the default error policy options.

Problems are considered errors that lead to the termination of the call. Problems in the request are reported back to the client, while errors in the response are suppressed to avoid information leak.

See Error Policy to understand how defaults are applied.

  1. Add the name of the deserializer.

  2. Select the Type of the Deserializer.

  3. Choose an Error policy from the drop-down list.

  4. Choose a Matcher from the drop-down list.

  5. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  6. Click the Save button, when all required configuration fields have been defined.

6.5.7. Compressor

The Compressor Plugin compresses the body of the HTTP message.

Compressors understand the Transfer-Encoding HTTP header and can work with content optionally compressed by the gzip, deflate and brotli algorithms.

6.5.7.1. Configuring Compressors

The Compressor can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Compressor.

The configuration window that appears presents the default Compressor, as listed in Default objects - PLUGINS and the configuration values already set by the user:

The Compressor’s main page in the Web User Interface
Figure 35. The compressor main page in the Web User Interface
  1. Click the New button to create a Compressor configuration. The following values can be configured for the Compressor Plugin:

Configuring a compressor in the Web User Interface
Figure 36. Configuring a compressor in the Web User Interface

The table describes some more details on the Compressor’s configuration parameters.

Table 46. The Compressors' configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

It is the name identifying the compressor. This name of the compressor can be referenced from other parts of the configuration, that is, the Plugin is reusable.

Error policy

The Error Policy configured under BRICKS are listed here can be selected from the drop-down list.

The Plugin has a default error policy.

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. If no error policy is configured, the plugin type’s default error policy is applied. For details see Error Policy.

Matcher

The Matchers configured under BRICKS main configuration unit are listed here and can be selected from the drop-down list.

Always: If the value is not defined the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If no matcher is configured the Plugin is always executed.

Continue configuring the compressor with the following steps:

  1. Add the name of the compressor.

  2. Choose an Error policy from the drop-down list.

  3. Choose a Matcher from the drop-down list.

  4. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  5. Click the Save button, when all required configuration fields have been defined.

6.5.8. Decompressor

The Decompressor Plugin decompresses the body of the HTTP message.

They understand the Transfer-Encoding HTTP header and can work with content optionally compressed by the gzip, deflate and brotli algorithms.

6.5.8.1. Configuring Decompressors

The Decompressor can be configured under the PLUGINS main navigation unit.

  1. Click on PLUGINS main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of PLUGINS.

  2. Select Decompressor.

The configuration window that appears presents the default Decompressor, as listed in Default objects - PLUGINS and the configuration values already set by the user:

Decompressor’s main page in the Web User Interface
Figure 37. The Decompressor’s main page in the Web User Interface
  1. Click the New button to create a Decompressor configuration. The following values can be configured for the Decompressor Plugin:

Configuring a decompressor in the Web User Interface
Figure 38. Configuring a decompressor in the Web User Interface

The table describes some more details on the Decompressor’s configuration parameters.

Table 47. The Decompressors' configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

It is the name identifying the decompressor. This name of the decompressor can be referenced from other parts of the configuration, that is, the Plugin is reusable.

Error policy

The Error Policy configured under BRICKS are listed here can be selected from the drop-down list.

The Plugin has a default error policy.

It defines a custom error policy to be applied if the Plugin reports an error. The settings of the Error policy here override the Security Flow’s default error policy. If no error policy is configured, the plugin type’s default error policy is applied. For details see Error Policy.

Matcher

The Matchers configured under BRICKS main configuration unit are listed here and can be selected from the drop-down list.

Always: If the value is not defined the plugin is always executed.

It decides if the Plugin should be executed based on the call’s details. For details see Matcher. If no matcher is configured the Plugin is always executed.

Continue configuring the decompressor with the following steps:

  1. Add the name of the decompressor.

  2. Choose an Error policy from the drop-down list.

  3. Choose a Matcher from the drop-down list.

  4. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  5. Click the Save button, when all required configuration fields have been defined.

6.6. SERVICE - Configuration units

Proxedo API Security is based on a micro-services architecture.

Services' main page in the Web User Interface
Figure 39. Services' main page in the Web User Interface

6.6.1. Backend

Backends are a set of servers for a given API endpoint.

Their configuration is made up of two main parts:

  • a list of servers: port pairs and how to route traffic to them

  • TLS configuration for talking to the servers

6.6.1.1. Configuring the Backend

Backend can be configured under the SERVICE main navigation item.

  1. Click on the_SERVICE_ main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of SERVICE.

  2. Select Backend.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

The main page for Backend
Figure 40. The main page for Backend
  1. Click the New navigation button to create a Backend configuration.

The following keys are available for Backend configuration:

Configuring backend in the Web User Interface
Figure 41. Configuring backend in the Web User Interface

Backends take the following configuration options:

Table 48. Backend configuration
Key Values Default value Description

Name

It is a mandatory value. It can be defined in free text.

The name identifying the backend. This name of the backend can be referenced from other parts of the configuration.

Backend retry in

If the value is not configured the default value will be added.

600000

It is the timeout in milliseconds before a server -that was down- is restarted again.

Backend timeout

If the value is not configured the default value will be added.

30000

It is the connection timeout in milliseconds of a server that is down.

Backend TLS

The value can be selected from a drop-down list. The drop-down list presents the Backend TLS configurations defined under BRICKS/TLS. If the value is not set, no TLS will be used in this backend.

none

You can define the TLS configuration towards the backend servers. See [backend-side-tls] for details.

Backend use client address

If this parameter is switched on, PAS uses the client’s source address as the source of the server-side connection. Otherwise it uses the IP address of the interface connected to the server. If the value is not configured the default value will be added.

false

The URL by which the backend servers understand incoming requests. When set, two transformations take place:

  • The original URL will be replaced by the new URL in the request.

  • The Host header will be replaced by the host indicated in the backend_url.

Forge Port

The source port can can take on the following values:

  • Any

  • Group

  • Exact

  • Random

If the value is not configured the default value will be added.

Any

This parameter defines the source port that PAS uses in the server-side connection. The values in details are as follows:

  • Any: Select a random port between 1024 and 65535.

  • Group: Select a random port in the same group, in which the port is in, used by the client. The following groups are defined: 0-513, 514-1024,1025-.

  • Exact: Use the same port as that of the client.

  • Random: Select a random port using a cryptographically secure function.

LB method

One of the following methods can be used:

  • Direct: always use the first server

  • Failover: use the first server while available, then fail over to the next

  • RR: use all servers in a round-robin fashion

If the value is not configured the default value will be added.

Direct

Load balancing method to use.

Servers*

It is a mandatory value. There are two values to be configured:

  • Host: The name or IP address of the host to connect to.

  • Port: The port on host to connect to. (You can add the values by clicking the '+' sign.)

The list of servers that serve API endpoint(s). See Backend servers' configuration for details.

  1. Name the Backend configuration.

  2. Provide the values for the Servers parameter:_Host_ and Port.

  3. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  4. Click the Save button, when all required configuration fields have been defined.

6.6.2. Endpoint

An endpoint holds together all the policies that apply to a certain API endpoint:

  • List of URLs

  • The default error policy for the endpoint

  • The backend to which requests will be forwarded

  • The security flow that will be applied to the traffic

6.6.2.1. Security Flow

The Security Flow definition in an endpoint lists what happens to the traffic on a given endpoint.

To understand how requests flow through PAS, see Understanding processing flow. The Security Flow starts when the Transport Director has already set up client connection and routed the request to the Flow Director. At this point the TLS and HTTP layers are already processed, but the content in the body of the request is available only in raw format and has not been parsed yet.

At this stage, the configuration security flow decides on what happens to the traffic by applying a list of Plugins one by one. Plugin is a collective name for Enforcers, Insights, Filters, etc. Once, all the plugins have processed the request, the control is handed back to the Transport Director which routes the request to a backend server, and comes back with the response after handling TLS and HTTP. At this point, the Flow Director applies another list of Plugins to response, and once done, it hands back the response to the Transport Director which in turn returns that to the client.

If at any point an error occurs, the error policy is applied — which might either mean to lead to logging the error or to terminating processing and returning an error indication to the client.

Plugins can override the endpoint’s error policy.

Also note that different Plugins need different data. An Insight that applies a JMESPath query needs parsed JSON, while one that extracts value from an HTTP header field does not. Other Plugins provide these required values, like a JSON deserializer Plugin. It is important that the Plugins are configured in such an order that the required data is made available beforehand.

6.6.2.2. Configuring the Endpoint

Endpoints can be configured under the SERVICE navigation item.

  1. Click on the SERVICE main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of SERVICE.

  2. Select Endpoint.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

The main page for Endpoint
Figure 42. The main page for Endpoint
  1. Click the New navigation button to create an Endpoint configuration.

The following keys are available for endpoint configuration on the main page of endpoint:

Configuring endpoint in the Web User Interface
Figure 43. Configuring endpoint in the Web User Interface

Each endpoint has the following configuration options. The elements marked with * are mandatory to be configured.

Table 49. Endpoint configuration
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name identifying the endpoint. This name of the endpoint can be referenced from other parts of the configuration.

Backend*

It is a mandatory value. Backends are a set of servers for a given API endpoint. For more details, see Security Flow.

The Security Flow definition in an endpoint lists what happens to the traffic on a given endpoint. For more details, see Security Flow.

Backend URL

The URL by which the backend servers understand incoming requests. When set, two transformations take place:

  • The original URL will be replaced by the new URL in the request.

  • The Host header will be replaced by the host indicated in the backend_url.

Failure policy

Two values have to be configured:

  • Silent

  • Code

Silent: True; Code: 500

With the help of the Failure policy, it can be configured whether the use shall receive notification or not, and whether the notification shall contain the code on the type of the failure. The values in details are as follows:

  • Silent: If the silent value is active, the Failure policy is not reported. If the silent value is inactive, the failure policy is reported towards the user.

  • Code: Code is an HTTP response code here, that can be set manually or from the provided drop-down list.

Security flow*

The security flow process requires the configuration of three values, each containing a list of Plugins. All three values are mandatory values.

  • Request*

  • Response*

The values in details are as follows:

  • Request: It is a mandatory value. The Transport Director sets up client connection and routes the request to the Flow Director. The Request has numerous values to be configured. For more details, see Security Flow.

  • Response: It is a mandatory value. The Transport Director routes the request to a backend server, and comes back with the response after handling TLS and HTTP. For more details, see Security Flow.

Urls*

It denotes the URLs which the clients use to address the API endpoint.

  1. Name the Endpoint Service.

  2. Select the Backend parameter from the drop-down list. Backend servers are configured under the SERVICE main navigation item.

  3. Complete a Security Flow from the configured (and the default) plugins. For more details, see Security Flow.

    • Choose the Request plugin from the drop-down list. The Plugin options available from the drop-down list have been configured under PLUGINS main navigation item.

    • Choose the Response plugin from the drop-down list. The Plugin options available from the drop-down list have been configured under PLUGINS main navigation item.

  4. Provide the URL to address the API endpoint.

  5. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  6. Click the Save button, when all required configuration fields have been defined.

Backend and Backend url needs to be the same as for all endpoints configured to the same listener.
All endpoints in the list must have the same backend and backend URL configured.
While ports must be unique, as only one listener can bind to a specific port, it is perfectly valid to route incoming traffic from multiple listeners to the same endpoint.

A typical security flow is configured with the plugins in the following order:

  • a Decompressor Plugin that decompresses the content of the request

  • a Deserializer Plugin that parses the content of the request

  • an Enforcer Plugins that ensure the call is valid

  • Insight Plugins that extract important data from certain calls

  • a Serializer Plugin that rebuilds the contents of the request

  • a Compressor Plugin that compresses the content of the request

The Plugin configurations are reusable.

6.6.3. Listeners

Listeners are network endpoints where services are exposed to the network. They consist of:

  • a listening port

  • an optional client-side TLS configuration if HTTPS is used

  • a list of endpoints that handle the traffic.

Since these are the entry points for client traffic it must be routed here on the network.

6.6.3.1. Configuring Listeners

Listeners can be configured under the SERVICE navigation unit.

  1. Click on the SERVICE main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of SERVICE.

  2. Select Listener.

The configuration window that appears either presents the configuration values already set by the user or shows the configuration values ready to be configured:

Listener main page in the Web User Interface
Figure 44. Listener’s main page in the Web User Interface
  1. Click the New button to create a Listener configuration.

At least one listener must always be configured in the Proxedo API Security configuration.

The following keys are available for listener configuration on the main page of the listener:

Configuring a listener in the Web User Interface
Figure 45. Configuring a listener in the Web User Interface]

The listener’s key elements are described in the following table. The elements marked with * are mandatory to be configured.

Table 50. Listeners’ configuration options
Key Values Default value Description

Name*

It is a mandatory value. It can be defined in free text.

The name identifying the listener. This name of the listener can be referenced from other parts of the configuration.

Client TLS

The default value is ‘none’, which means TLS is not used (and therefore HTTPS). You can alternatively set it to ‘first client tls’ or to ‘second client tls’, which values have to be defined first under Bricks/Client TLS.

None

TLS configuration towards the clients. See TLS for details.

Endpoints*

It is a mandatory value. You can choose the first, the second or the third endpoint values from a drop-down list. The endpoint values have to be defined previously under SERVICE/Endpoint.

The list of endpoint(s), as defined under [endpoints] that serve traffic coming in on the listener.

Port

It is a mandatory value. Any port value can be defined. Note that the port value has to be within the range configured in the docker.

443

The number of the port(s) the listener binds to.

Also consider the followings:

All endpoints in the list must have the same backend and backend URL configured.
Ports must be unique, only one listener can bind to a specific port. It is however perfectly valid to route incoming traffic from multiple listeners to the same endpoint.
  1. Name the Listener Service.

  2. Select the Client TLS parameter from the drop-down list. The client side TLS parameter values have to be defined previously under BRICKS.

  3. Select the Endpoint from the drop-down list. The endpoint values have to be defined previously under SERVICE/Endpoint.

  4. Fill in the Port information. If it is not configured, the default value will be applied.

  5. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  6. Click the Save button, when all required configuration fields have been defined.

6.6.4. Log

If at any point an error occurs during the Security Flow, the error policy is applied and logging takes place if configured so.

6.6.4.1. Configuring Logs

Logging can be configured under the SERVICE main navigation item.

  1. Click on SERVICES main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of SERVICE.

  2. Select Log.

The following keys are available for configuration on the main page of Log:

The main page for Logs
Figure 46. The main page for Logs
Table 51. Log configuration
Key Values Default value Description

Name*

Log has a default name 'default', that cannot be changed.

The name identifying the log configuration.

Log level

The value can take number format.

3

It configures the log level to logging. It must be between 1-9.

Log specification

A single log specification consists of a wildcard matching log category, a colon, and a number specifying the verbosity level of that given category. Categories match from left to right. For example: http.*:5,core:3. The last matching entry will be used as the verbosity of the given category. If no match is found the default verbosity specified with loglevel is used.

*.accounting:4,core.summary:4

Set verbosity mask on a per category basis. Each log message has an assigned multi-level category, where levels are separated by a dot.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Click the Save button, when all required configuration fields have been defined.

6.6.5. Transport director

The Transport Director manages the transport layer of API connections:

  • handles network connections from the client

  • handles network connections towards the backends

  • handles TLS on these connections

  • load-balances between multiple backend servers

  • load-balances between multiple Flow Directors

  • enforces HTTP protocol validity in calls

6.6.5.1. Configuring the Transport Director

The Transport Director can be configured under the SERVICE main navigation item.

  1. Click on the SERVICE main configuration item in the Left navigation area. Alternatively you can also click on the arrow open sign to open up the sub-navigation items of SERVICE.

  2. Select Transport Director.

The following main window appears for the Transport Director:

The main page for Transport Director
Figure 47. The main page for Transport Director

The following settings control the Transport Director container’s startup.

Table 52. Transport Director configuration
Key Values Default value Description

Name*

The Transport Director has a default name 'default', that cannot be changed.

The name identifying the Transport Director configuration. This name of the deserializer can be referenced from other parts of the configuration.

Enable core

It can be configured active or inactive.

false

It enables core dumps on failures.

Threads

0

Set the maximum number of threads that can be used in parallel.

  1. Click the Validate button to check if the defined parameters are suitable and adequate for configuring the component. If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the 'Component validation failed'. Also a warning with information on the missing details appears at the problematic field for the user. If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the 'Component Validation successful' notification.

  2. Click the Save button, when all required configuration fields have been defined.

6.7. Status information on the configuration of Proxedo API Security services

The administrator can check the status of the services and their containers. Whether a certain service runs properly or not might be a helpful piece of information in identifying some of the configuration problems.

The status information is presented for each node separately. Open up the details for each node, by clicking on the plus sign next to the name of the node:

  • Container: It identifies the component the PAS service runs in.

  • Last reloaded: It provides the exact timing of the last reload in ISO format.

  • Reload success: It informs the administrator on whether the reload was successful or not.

  • Configuration load result: It informs the administrator on whether the load of the configuration was successful or not. The possible values are:

    • Successful

    • Failed

  • Actions: Click the Bin button icon to delete the data for complete elements that have not been properly configured.

Status information on the configuration of Proxedo API Security services
Figure 48. Status information on the configuration of Proxedo API Security services

6.8. Checking and finalizing changes in Proxedo API Security configuration

It is possible to list and check any changes made to the PAS configuration until the changes have not been applied with the Apply Configuration button.

Click on the Changes button in the Top-left navigation area to list the changes made to the configuration.

The following pieces of information are displayed:

  • configuration integrity problems

  • changes made to any of the configuration components

Checking changes made to the configuration
Figure 49. Checking changes made to the configuration

Configuration Integrity

For changes on configuration integrity, the following pieces of information are displayed in table format:

  • Type: It denotes the type of the integrity problem, for example cycle detection.

  • Description: Description provides details on the nature of the integrity change.

  • Recommended action: A recommended action might be displayed here for the configuration integrity problem.

Configuration Changes

For changes on the configuration components, the following pieces of information are displayed in table format:

  • Type: Type denotes the category (Brick, Plugin, Service) and the class (for example, Matcher, Filter, Log) of the configuration component, for example Brick/Matcher.

  • Name: The name of the configuration component is displayed here, to which the actual change has been made.

  • Change: The nature of the change made to the configuration component is provided here, that is, added, edited, deleted or no (no change).

  • Valid: This field informs the user on whether the configured component is valid or not, as follows:

    • Not valid - Any instance marked with this sign is invalid.

    • Valid - Any instance marked with this sign is valid.

Click on the Not valid sign to see more information on why the instance was found invalid.

Invalid configuration components can be corrected and revalidated by using the Validate button, available at each component’s configuration page. For more information, see section Component-level validation in chapter Applying and validating Proxedo API Security configuration.

  • Actions: This field provides possibilty to edit the configuration data for a component or to undo any configuration changes to a component. By selecting the undo icon, all changes made to the actual component will be deleted.

If the edit button is disabled, that is, it is not active, it means that the instance has been deleted. If the undo button is disabled, that is, it is not active, no changes have been made to the actual component.

By selecting the Discard button, it is possible to discard all changes made to the configuration. However, the default elements that are created by the system to ease configuration, or the changes that have been applied to the configuration already cannot be discarded.

6.9. Applying and validating Proxedo API Security configuration

PAS configuration can be checked and validated on two levels:

  • component-level validation

  • validating the whole configuration by using the Apply Config button

Component-level validation

Component-level validation takes place while configuring the actual elements of the configuration and by using the Validate button on the Web UI page of the specific component.

If the configuration of the component is erroneous or not adequate, the Web UI provides a warning that the Component validation failed. Also a warning with information on the missing details appears at the problematic field for the user.

Component validation failed
Figure 50. Component validation failed

If the configuration of the component is satisfactory, after clicking the Validate button, the user receives the Component Validation successful notification. For related errors see, section Validation errors.

Component validation successful
Figure 51. Component validation successful

Validating the whole configuration

The Apply Config button is available from the Changes page. To make it available click the Changes button so that all the changes made to any component by the user will be visible. In order to take the changes into effect, click the Apply Config button. Apply the configuration only in case all changes are valid. When applying the configuration by using the Apply Config button, the Web UI provides either of the following messages:

  • Configuration applied successfully.

  • The configuration failed.
    Note, that in case the configuration could not be applied, the Web UI also provides an additional pop-up window with the description of the problem.

Apply Config result - successful
Figure 52. Apply Config result - successful
Apply Config result - failed
Figure 53. Apply Config result - failed

6.9.1. Validation errors

In case the configuration could not be applied, the following result messages help the user to correct the configuration and achieve a valid configuration.

These errors are the results of the validation of the actual components. By correcting these the user can achieve a functioning configuration.

6.9.1.1.1. Missing data for required fields

Each component has compulsory configuration fields that must be filled in. In case any of those fields are left empty, the Web UI provides a Missing data for required field notification when the component is validated, that is, the Validate button is used. Each compulsory field is highlighted with a * sign.

Example
The Target component requires the Host field to be filled in, otherwise the component’s configuration is not valid.

Error message: Missing data for required field.

Missing required field - Target
Figure 54. Missing required field - Target
6.9.1.1.2. Missing reference

This error indicates that the component references a non-existing component.

Example
The user creates an error policy, Error Policy A which error policy is referenced in a Filter. Following that, this specific error policy, Error Policy A is deleted from the configuration. This results in a missing reference in the Filter.

Error message: Reference to a non-existing component: Error Policy A.

To correct the missing reference, navigate to the Filter component. In order to clear the invalid reference to the missing component, the Erease icon icon has to be selected on the right side of the error policy drop-down list. By clicking this icon, the configuration data is cleared from this selection.
6.9.1.1.3. Port conflict

This error indicates that two or more Listeners are configured to use the same port. This leads to a failed configuration.

Example
Two Listeners are configured to use the same port.

Error message: Listener A uses the same port as Listener B.

6.9.1.2. Integrity errors
6.9.1.2.1. Cycle detection

This error indicates that there is a cycle of references between the instances. The cycle of references can only be configured in between compound matchers.

Example
If the compound matcher Matcher A is configured to reference the compound matcher Matcher B and the compound matcher Matcher B is also referencing the compound matcher Matcher A, there will be a cycle of references between these two compound matchers.

Error message: Cyle detected in configuration: BRICK/Matcher/Matcher A→BRICK/Matcher/Matcher B→BRICK/Matcher/Matcher A.

6.9.1.2.2. Required Instance is missing

This error indicates that a required instance is not configured. It is required that at least one Listener service must be configured.

Error message: At least one service/listener must be configured.

6.9.1.2.3. Endpoints of a listener must use the same backend

All endpoints added to a listener must use the same backend with the same backend URL.

Example
Configure two endpoints using different backends and create a listener. Add both endpoints to the same listener.

Error message: All endpoints configured to a listener must use the same backend.

7. Operations

7.1. Operation of dockerd

Dockerd is managed through 'systemd', so common administration tasks are carried out through its interfaces.

Checking the status of docker

systemctl status docker

Example output
docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2017-07-10 08:25:38 CEST; 4h 1min ago
     Docs: https://docs.docker.com
 Main PID: 2148 (dockerd)
    Tasks: 177 (limit: 4915)
   Memory: 119.1M
      CPU: 1min 36.272s
   CGroup: /system.slice/docker.service
           ├─2148 /usr/bin/dockerd
           ├─2185 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcon
           ├─2542 docker-containerd-shim fef20e5205c47b5cc18e612903a33e749ebd89a4bf30fd5bb8fb4a801450c84f /var/run/docker/libcontainerd/fef20e5205c47b5cc18e612903a33e749ebd8
           ├─2582 docker-containerd-shim 410f0bc67c731635a7d60e9f259d2f62ef8a845e09595254217decd3b3885473 /var/run/docker/libcontainerd/410f0bc67c731635a7d60e9f259d2f62ef8a8
           ├─2704 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 5000 -container-ip 172.18.0.2 -container-port 5000
           ├─2732 docker-containerd-shim 3853efde62d1767e70372584812df07968a647f40039691d82ccd5cbc66ee32d /var/run/docker/libcontainerd/3853efde62d1767e70372584812df07968a64
           ├─2770 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8484 -container-ip 172.18.0.2 -container-port 443
           ├─2806 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8181 -container-ip 172.18.0.2 -container-port 80
           ├─2832 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 2222 -container-ip 172.18.0.2 -container-port 22
           ├─2837 docker-containerd-shim e24a8f2f189467601edb6bee0e63451e7230726feab50d43556e6c66a8f9fc56 /var/run/docker/libcontainerd/e24a8f2f189467601edb6bee0e63451e72307
           ├─2921 docker-containerd-shim 8ac62e1eee0d162e632eab95b08ea36aff69abd5d1eeac475bfee3f393cba179 /var/run/docker/libcontainerd/8ac62e1eee0d162e632eab95b08ea36aff69a
           ├─2974 docker-containerd-shim 6df61a17c29a132cb5886a494fc34e38ff38f2cf470919289c783fada579a70c /var/run/docker/libcontainerd/6df61a17c29a132cb5886a494fc34e38ff38f
           ├─3043 docker-containerd-shim d00a1de3994e2b11ecd93d938dc94702f4f6d0364d2f3c1c423ab2a1ec5c843a /var/run/docker/libcontainerd/d00a1de3994e2b11ecd93d938dc94702f4f6d
           ├─3123 docker-containerd-shim b9e93059835c2d343c912c7f7154b14625dcd2e8d242fd67328e9532e5829d64 /var/run/docker/libcontainerd/b9e93059835c2d343c912c7f7154b14625dcd
           ├─3187 docker-containerd-shim 2d058ab3987f2461c5f0029505eca264f94d34ed23c8464bfd83362ad9bcd142 /var/run/docker/libcontainerd/2d058ab3987f2461c5f0029505eca264f94d3
           └─3258 docker-containerd-shim 882c51a1a693230ea2d84f2f1a422655f9051d3a21a5f916a03e62614b17ed4a /var/run/docker/libcontainerd/882c51a1a693230ea2d84f2f1a422655f9051
Starting docker

systemctl start docker

Stopping docker

systemctl stop docker

Configuring docker to start automatically

systemctl enable docker

Configuring docker not to start automatically

systemctl disable docker

7.2. Operation of services

The services of PAS are consolidated under the user pas who has privileges for common administration tasks.

Unless otherwise noted administrative commands should therefore be run as pas and not as root. This is especially true for docker-compose commands.

7.2.1. Helper scripts for PAS in general

To help administrators with frequent PAS-related operations, we provide helper scripts in /opt/balasys/bin. To get the full list of helper scripts, just list this directory.

All script names are prefixed with the name of the component they correspond to. Therefore they follow the scheme pas-<component-name>-script-name except for core where the component-name part is omitted.

7.2.2. Checking configuration with pas-*-checkconfig

Some components of PAS have a textual configuration file, and it is possible to check them without actually starting the component. For different components, the following helper scripts are available.

Component Helper script

HA

pas-ha-checkconfig

Storage

pas-storage-checkconfig

Management

pas-mgmt-checkconfig

pas-*-checkconfig can check the validity of PAS bootstrap configuration. Namely:

  • it makes sure that the mandatory containers are defined in docker-compose.yml.

  • it checks config.yml against the defined constraints one by one.

docker-compose.yml is only checked for making sure that services have a proper image tag.
Currently, there is no configuration checker script for the core component.

7.2.3. Checking services

7.2.3.1. Storage service
Checking the status of PAS management

systemctl status proxedo-api-security-storage

List the status of the services

docker-compose -f /opt/balasys/etc/infrastructure/storage/docker-compose.yml ps

Example output
      Name                    Command               State                      Ports
-----------------------------------------------------------------------------------------------------------
pas_blob-store_1   /usr/bin/dumb-init /usr/lo ...   Up      0.0.0.0:9000->9000/tcp,:::9000->9000/tcp
pas_consul_1       /usr/bin/dumb-init /usr/lo ...   Up      0.0.0.0:8300->8300/tcp,:::8300->8300/tcp, [...]
Check which images are used by the services

docker-compose -f /opt/balasys/etc/infrastructure/storage/docker-compose.yml images

Example output
   Container                        Repository                    Tag      Image Id       Size
------------------------------------------------------------------------------------------------
pas_blob-store_1   docker.balasys.hu/api-security/blob-store     3.0.3   40bdc2d7665e   654.5 MB
pas_consul_1       docker.balasys.hu/api-security/consul         3.0.3   afd247e1e8c4   817 MB
7.2.3.2. Management service
Checking the status of PAS management

systemctl status proxedo-api-security-mgmt

List the status of the services

docker-compose -f /opt/balasys/etc/infrastructure/mgmt/docker-compose.yml ps

Example output
      Name                    Command               State                      Ports
-------------------------------------------------------------------------------------------------------
pas_config-api_1   /usr/bin/dumb-init /usr/lo ...   Up      8080/tcp
pas_frontend_1     /usr/bin/dumb-init /usr/lo ...   Up      0.0.0.0:80->8080/tcp, 0.0.0.0:443->8443/tcp
Check which images are used by the services

docker-compose -f /opt/balasys/etc/infrastructure/mgmt/docker-compose.yml images

Example output
   Container                        Repository                    Tag      Image Id       Size
------------------------------------------------------------------------------------------------
pas_config-api_1   docker.balasys.hu/api-security/config-api     3.0.3   025bf7529113   596.2 MB
pas_frontend_1     docker.balasys.hu/api-security/config-webui   3.0.3   1f2536bf1cf2   583.5 MB
7.2.3.3. Core service
Checking the status of PAS

systemctl status proxedo-api-security

List the status of the services

docker-compose -f /opt/balasys/etc/infrastructure/pas/docker-compose.yml ps

Example output
          Name                        Command               State                         Ports
----------------------------------------------------------------------------------------------------------------------
pas_flow-director_1        /usr/bin/dumb-init /usr/lo ...   Up
pas_flow-director_2        /usr/bin/dumb-init /usr/lo ...   Up
pas_insight-director_1     /usr/bin/dumb-init /usr/lo ...   Up
pas_transport-director_1   /usr/bin/dumb-init /usr/lo ...   Up      0.0.0.0:49000->49000/tcp, 0.0.0.0:49001->49001/tcp
Check which images are used by the services

docker-compose -f /opt/balasys/etc/infrastructure/pas/docker-compose.yml images

Example output
       Container                               Repository                       Tag      Image Id       Size
--------------------------------------------------------------------------------------------------------------
pas_flow-director_1        docker.balasys.hu/api-security/flow-director        3.0.3   a2b7ccc88823   626.3 MB
pas_flow-director_2        docker.balasys.hu/api-security/flow-director        3.0.3   a2b7ccc88823   626.3 MB
pas_insight-director_1     docker.balasys.hu/api-security/insight-director     3.0.3   db005e0fa5b6   573.6 MB
pas_transport-director_1   docker.balasys.hu/api-security/transport-director   3.0.3   c53bfaed2db0   653.1 MB

7.2.4. Starting and stopping services

7.2.4.1. Storage service
Starting PAS storage

systemctl start proxedo-api-security-storage

Stopping PAS storage

systemctl stop proxedo-api-security-storage

Restarting PAS storage

systemctl restart proxedo-api-security-storage

pas-storage-checkconfig is invoked prior to (re)starting and reloading the service. The requested operation is interrupted if pas-storage-checkconfig fails.
Configuring PAS storage to start automatically

systemctl enable proxedo-api-security-storage

Configuring PAS storage not to start automatically

systemctl disable proxedo-api-security-storage

7.2.4.2. Management service
Starting PAS management

systemctl start proxedo-api-security-mgmt

Stopping PAS management

systemctl stop proxedo-api-security-mgmt

Restarting PAS management

systemctl restart proxedo-api-security-mgmt

pas-mgmt-checkconfig is invoked prior to (re)starting and reloading the service. The requested operation is interrupted if pas-mgmt-checkconfig fails.
Configuring PAS management to start automatically

systemctl enable proxedo-api-security-mgmt

Configuring PAS management not to start automatically

systemctl disable proxedo-api-security-mgmt

7.2.4.3. Core service
Starting PAS

systemctl start proxedo-api-security

Stopping PAS

systemctl stop proxedo-api-security

Restarting PAS

systemctl restart proxedo-api-security

Configuring PAS to start automatically

systemctl enable proxedo-api-security

Configuring PAS not to start automatically

systemctl disable proxedo-api-security

The same operations are available for the proxedo-api-security-ha service.

7.2.5. Operational dependencies between the core and the HA services

As the proxedo-api-security-ha service makes PAS highly available, the two services have a specific dependency relation. The proxedo-api-security-ha service can be started alone without PAS running to enable debugging without having to deal with PAS as well.

Although, if the proxed-api-security service is also started, the changes of its state affect the HA service too. Stop and restart operations are propagated to the HA service and if the proxed-api-security service enters failed state, it will also stop the HA service. This is to ensure renouncing MASTER state unless PAS is up and running.

7.2.6. Upgrading services

Prior to upgrading services, make sure that the image tags point to the right version. See section docker-compose.conf for details.

The upgrade process will cause a service disruption.

To upgrade PAS docker images, you need to run the update script of the corresponding components.

  • pas-update

  • pas-mgmt-update

  • pas-storage-update

Major and minor version upgrades also include installing the new .deb package.

7.3. Checking Logs

All the container logs are collected in the system journal. Container logs are identified with the name of the container such as pas-[transport|insight|flow|ha]-director. Management container identifiers are pas-[frontend|config-api]. Storage container identifiers are pas-[consul|blob-store].

You can check the system journal with the journalctl command. It accepts various possibilities for filtering, consult its manual page for details.

When using the --unit option of journalctl, note that the services are docker containers and their logs show up under the docker service, and not under proxedo-api-security.
One option for checking a specific container’s logs is to use the --identifier option for journalctl and specify the identifier of the component.

7.3.1. Understanding logs

As multiple pieces of software run in each container, there are two layers of logs in each containers' output. The first field is always an ISO formatted date. Then the name of the process inside the container follows. The remaining fields are the output of the process itself. In the below example, we see logs from the flow-director container. It prints output for processes called pre, pas-event-handler, flow-director and service-adaptor.

Container log output
2021-04-20T09:15:30 pre Container starts
2021-04-20T09:15:33 pre INFO:confgen: Generating configuration files
2021-04-20T09:15:34 pas-event-handler INFO:SupervisordEventDispatcher:Dispatching event; processname='pre', eventname='PROCESS
2021-04-20T09:15:34 pas-event-handler INFO:SupervisordEventDispatcher:Process exited; processname=pre, success=True
2021-04-20T09:15:34 pas-event-handler INFO:SupervisordEventDispatcher:Starting main processes.
2021-04-20T09:15:34 pas-event-handler INFO:SupervisordEventDispatcher:Starting process; process='flow-director'
[...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_builder.info(3) (nosession): Loaded plugin; [...]
2021-04-20T09:15:37 flow-director 2021-04-20T09:15:37+0200: flow_set.info(3) (nosession): Start building flows
[...]
2021-04-20T09:15:39 pas-event-handler INFO:SupervisordEventDispatcher:Starting process; process='service-adaptor'
[...]
2021-05-07T14:23:55 service-adaptor INFO:PASHealthCheck:All services are healthy.
2021-05-07T14:23:55 service-adaptor [pid: 47|app: 0|req: 223/223] 172.19.0.3 () {28 vars in 350 bytes} [Fri May  7 14:23:55 2021] [...]
7.3.1.1. Flow Director and Transport Director logs

As from the API security perspective, the most important components are Flow Director and Transport Director, we discuss their logs more in detail. There are two important concepts related to these logs: categories and Session IDs.

  • Categories help filtering logs based on their relevance. They are composed of a component, a tag, and a severity, for example: http.info(3).

    • The component helps to identify the part of the solution. For the Transport Director this is usually core or http, for the Flow Director it is either core, or the Plugin’s type, such as serializer or enforcer.

    • The tag helps to define the type of the message. Usually one of info, error, debug, policy or accounting.

    • The severity defines how important the message is. It is a number between 1-9 where 1 is the highest.

  • Session ID helps identifying log lines that belong to the same session. This is especially important as the calls travel between the Transport Director and the Flow Director.

It is usually in the form of svc/default/<listener>:<transport-director-session>/default/http#<http-request-count>/flow:<flow-director-id>/ch:<flow-director-channel>/<plugin_type>/<plugin_name>, for example: svc/default/httpbin:14/default/http#0/flow:1/ch:28/enforcer/manualtest.

Information that is not available at the time, will be missing from the Session ID. Generally, the part until /flow: belongs to the Transport Director. Consequently, the Transport Director will never see that part. The Flow Director however will fetch and include that information. Nevertheless, in early phases it might not be available, and the Session ID will start with flow.

Despite some parts not being always available, the ID is constructed in such a manner that grepping on any part will find other messages with extra information as well.

7.4. Backup and restore

Configuration

The following files and folders need to be backed up or restored:

  • /opt/balasys/etc

  • /opt/docker

Data

The following files or folders need to be backed up or restored:

  • /opt/balasys/var/persistent

Process to backup files or folders
  • Pack files or folders mentioned earlier (optional).

  • Copy (packed) configuration and data to the backup server.

Process to restore files or folders
  • Stop all PAS services.

  • Copy (packed) configuration and data from the remote server.

  • Unpack files or folders mentioned earlier (optional).

  • Start all PAS services.

7.5. Recreating services

Recreating services will cause a service disruption.
Factory reset for PAS services

Remove all persistent data from the host.

This operation must be run as root.
  • /opt/balasys/bin/pas-storage-factory-reset

  • /opt/balasys/bin/pas-factory-reset

  • /opt/balasys/bin/pas-mgmt-factory-reset

    Resetting an individual service without removing persistent data
  • Use docker ps to find the container name of the service, the container of which you want to reset.

  • Stop the services by systemctl stop proxedo-api-security or systemctl stop proxedo-api-security-mgmt or systemctl stop proxedo-api-security-storage.

  • Remove the containers by docker rm <name-of-container>.

  • Start the services by systemctl start proxedo-api-security or systemctl start proxedo-api-security-mgmt or systemctl start proxedo-api-security-storage.

7.6. Troubleshooting services

Inspect running processes inside services
  • docker-compose -f /opt/balasys/etc/infrastructure/pas/docker-compose.yml top [SERVICE]

  • docker-compose -f /opt/balasys/etc/infrastructure/mgmt/docker-compose.yml top [SERVICE]

  • docker-compose -f /opt/balasys/etc/infrastructure/storage/docker-compose.yml top [SERVICE]

You can list available services by running docker-compose -f <docker-compose-file> ps --services.
Example output
pas_flow-director_1
UID     PID    PPID    C   STIME   TTY     TIME                                            CMD
--------------------------------------------------------------------------------------------------------------------------------------
root   26109   26052   0   13:46   ?     00:00:00   /usr/bin/dumb-init /usr/local/bin/supervisord -c /opt/balasys/etc/supervisord.conf
[...]
root   26529   26252   0   13:46   ?     00:00:01   /usr/bin/python3 /usr/local/bin/twistd -ny /opt/balasys/etc/twisted.tac
[...]

pas_flow-director_2
UID     PID    PPID    C   STIME   TTY     TIME                                            CMD
--------------------------------------------------------------------------------------------------------------------------------------
root   26350   26314   0   13:46   ?     00:00:00   /usr/bin/dumb-init /usr/local/bin/supervisord -c /opt/balasys/etc/supervisord.conf
[...]
root   26545   26434   0   13:46   ?     00:00:01   /usr/bin/python3 /usr/local/bin/twistd -ny /opt/balasys/etc/twisted.tac
[...]
Gain a shell to a running service
  • pas-login SERVICE

  • pas-mgmt-login SERVICE

  • pas-storage-login SERVICE

Run these commands without parameters to get the list of available service names.

Appendix A: Time zones

Time zones
Country Code Time zone Name

AD

Europe/Andorra

AE

Asia/Dubai

AF

Asia/Kabul

AG

America/Antigua

AI

America/Anguilla

AL

Europe/Tirane

AM

Asia/Yerevan

AO

Africa/Luanda

AQ

Antarctica/McMurdo

AQ

Antarctica/Casey

AQ

Antarctica/Davis

AQ

Antarctica/DumontDUrville

AQ

Antarctica/Mawson

AQ

Antarctica/Palmer

AQ

Antarctica/Rothera

AQ

Antarctica/Syowa

AQ

Antarctica/Troll

AQ

Antarctica/Vostok

AR

America/Argentina/Buenos_Aires

AR

America/Argentina/Cordoba

AR

America/Argentina/Salta

AR

America/Argentina/Jujuy

AR

America/Argentina/Tucuman

AR

America/Argentina/Catamarca

AR

America/Argentina/La_Rioja

AR

America/Argentina/San_Juan

AR

America/Argentina/Mendoza

AR

America/Argentina/San_Luis

AR

America/Argentina/Rio_Gallegos

AR

America/Argentina/Ushuaia

AS

Pacific/Pago_Pago

AT

Europe/Vienna

AU

Australia/Lord_Howe

AU

Antarctica/Macquarie

AU

Australia/Hobart

AU

Australia/Currie

AU

Australia/Melbourne

AU

Australia/Sydney

AU

Australia/Broken_Hill

AU

Australia/Brisbane

AU

Australia/Lindeman

AU

Australia/Adelaide

AU

Australia/Darwin

AU

Australia/Perth

AU

Australia/Eucla

AW

America/Aruba

AX

Europe/Mariehamn

AZ

Asia/Baku

BA

Europe/Sarajevo

BB

America/Barbados

BD

Asia/Dhaka

BE

Europe/Brussels

BF

Africa/Ouagadougou

BG

Europe/Sofia

BH

Asia/Bahrain

BI

Africa/Bujumbura

BJ

Africa/Porto-Novo

BL

America/St_Barthelemy

BM

Atlantic/Bermuda

BN

Asia/Brunei

BO

America/La_Paz

BQ

America/Kralendijk

BR

America/Noronha

BR

America/Belem

BR

America/Fortaleza

BR

America/Recife

BR

America/Araguaina

BR

America/Maceio

BR

America/Bahia

BR

America/Sao_Paulo

BR

America/Campo_Grande

BR

America/Cuiaba

BR

America/Santarem

BR

America/Porto_Velho

BR

America/Boa_Vista

BR

America/Manaus

BR

America/Eirunepe

BR

America/Rio_Branco

BS

America/Nassau

BT

Asia/Thimphu

BW

Africa/Gaborone

BY

Europe/Minsk

BZ

America/Belize

CA

America/St_Johns

CA

America/Halifax

CA

America/Glace_Bay

CA

America/Moncton

CA

America/Goose_Bay

CA

America/Blanc-Sablon

CA

America/Toronto

CA

America/Nipigon

CA

America/Thunder_Bay

CA

America/Iqaluit

CA

America/Pangnirtung

CA

America/Atikokan

CA

America/Winnipeg

CA

America/Rainy_River

CA

America/Resolute

CA

America/Rankin_Inlet

CA

America/Regina

CA

America/Swift_Current

CA

America/Edmonton

CA

America/Cambridge_Bay

CA

America/Yellowknife

CA

America/Inuvik

CA

America/Creston

CA

America/Dawson_Creek

CA

America/Fort_Nelson

CA

America/Vancouver

CA

America/Whitehorse

CA

America/Dawson

CC

Indian/Cocos

CD

Africa/Kinshasa

CD

Africa/Lubumbashi

CF

Africa/Bangui

CG

Africa/Brazzaville

CH

Europe/Zurich

CI

Africa/Abidjan

CK

Pacific/Rarotonga

CL

America/Santiago

CL

America/Punta_Arenas

CL

Pacific/Easter

CM

Africa/Douala

CN

Asia/Shanghai

CN

Asia/Urumqi

CO

America/Bogota

CR

America/Costa_Rica

CU

America/Havana

CV

Atlantic/Cape_Verde

CW

America/Curacao

CX

Indian/Christmas

CY

Asia/Nicosia

CY

Asia/Famagusta

CZ

Europe/Prague

DE

Europe/Berlin

DE

Europe/Busingen

DJ

Africa/Djibouti

DK

Europe/Copenhagen

DM

America/Dominica

DO

America/Santo_Domingo

DZ

Africa/Algiers

EC

America/Guayaquil

EC

Pacific/Galapagos

EE

Europe/Tallinn

EG

Africa/Cairo

EH

Africa/El_Aaiun

ER

Africa/Asmara

ES

Europe/Madrid

ES

Africa/Ceuta

ES

Atlantic/Canary

ET

Africa/Addis_Ababa

FI

Europe/Helsinki

FJ

Pacific/Fiji

FK

Atlantic/Stanley

FM

Pacific/Chuuk

FM

Pacific/Pohnpei

FM

Pacific/Kosrae

FO

Atlantic/Faroe

FR

Europe/Paris

GA

Africa/Libreville

GB

Europe/London

GD

America/Grenada

GE

Asia/Tbilisi

GF

America/Cayenne

GG

Europe/Guernsey

GH

Africa/Accra

GI

Europe/Gibraltar

GL

America/Godthab

GL

America/Danmarkshavn

GL

America/Scoresbysund

GL

America/Thule

GM

Africa/Banjul

GN

Africa/Conakry

GP

America/Guadeloupe

GQ

Africa/Malabo

GR

Europe/Athens

GS

Atlantic/South_Georgia

GT

America/Guatemala

GU

Pacific/Guam

GW

Africa/Bissau

GY

America/Guyana

HK

Asia/Hong_Kong

HN

America/Tegucigalpa

HR

Europe/Zagreb

HT

America/Port-au-Prince

HU

Europe/Budapest

ID

Asia/Jakarta

ID

Asia/Pontianak

ID

Asia/Makassar

ID

Asia/Jayapura

IE

Europe/Dublin

IL

Asia/Jerusalem

IM

Europe/Isle_of_Man

IN

Asia/Kolkata

IO

Indian/Chagos

IQ

Asia/Baghdad

IR

Asia/Tehran

IS

Atlantic/Reykjavik

IT

Europe/Rome

JE

Europe/Jersey

JM

America/Jamaica

JO

Asia/Amman

JP

Asia/Tokyo

KE

Africa/Nairobi

KG

Asia/Bishkek

KH

Asia/Phnom_Penh

KI

Pacific/Tarawa

KI

Pacific/Enderbury

KI

Pacific/Kiritimati

KM

Indian/Comoro

KN

America/St_Kitts

KP

Asia/Pyongyang

KR

Asia/Seoul

KW

Asia/Kuwait

KY

America/Cayman

KZ

Asia/Almaty

KZ

Asia/Qyzylorda

KZ

Asia/Qostanay

KZ

Asia/Aqtobe

KZ

Asia/Aqtau

KZ

Asia/Atyrau

KZ

Asia/Oral

LA

Asia/Vientiane

LB

Asia/Beirut

LC

America/St_Lucia

LI

Europe/Vaduz

LK

Asia/Colombo

LR

Africa/Monrovia

LS

Africa/Maseru

LT

Europe/Vilnius

LU

Europe/Luxembourg

LV

Europe/Riga

LY

Africa/Tripoli

MA

Africa/Casablanca

MC

Europe/Monaco

MD

Europe/Chisinau

ME

Europe/Podgorica

MF

America/Marigot

MG

Indian/Antananarivo

MH

Pacific/Majuro

MH

Pacific/Kwajalein

MK

Europe/Skopje

ML

Africa/Bamako

MM

Asia/Yangon

MN

Asia/Ulaanbaatar

MN

Asia/Hovd

MN

Asia/Choibalsan

MO

Asia/Macau

MP

Pacific/Saipan

MQ

America/Martinique

MR

Africa/Nouakchott

MS

America/Montserrat

MT

Europe/Malta

MU

Indian/Mauritius

MV

Indian/Maldives

MW

Africa/Blantyre

MX

America/Mexico_City

MX

America/Cancun

MX

America/Merida

MX

America/Monterrey

MX

America/Matamoros

MX

America/Mazatlan

MX

America/Chihuahua

MX

America/Ojinaga

MX

America/Hermosillo

MX

America/Tijuana

MX

America/Bahia_Banderas

MY

Asia/Kuala_Lumpur

MY

Asia/Kuching

MZ

Africa/Maputo

NA

Africa/Windhoek

NC

Pacific/Noumea

NE

Africa/Niamey

NF

Pacific/Norfolk

NG

Africa/Lagos

NI

America/Managua

NL

Europe/Amsterdam

NO

Europe/Oslo

NP

Asia/Kathmandu

NR

Pacific/Nauru

NU

Pacific/Niue

NZ

Pacific/Auckland

NZ

Pacific/Chatham

OM

Asia/Muscat

PA

America/Panama

PE

America/Lima

PF

Pacific/Tahiti

PF

Pacific/Marquesas

PF

Pacific/Gambier

PG

Pacific/Port_Moresby

PG

Pacific/Bougainville

PH

Asia/Manila

PK

Asia/Karachi

PL

Europe/Warsaw

PM

America/Miquelon

PN

Pacific/Pitcairn

PR

America/Puerto_Rico

PS

Asia/Gaza

PS

Asia/Hebron

PT

Europe/Lisbon

PT

Atlantic/Madeira

PT

Atlantic/Azores

PW

Pacific/Palau

PY

America/Asuncion

QA

Asia/Qatar

RE

Indian/Reunion

RO

Europe/Bucharest

RS

Europe/Belgrade

RU

Europe/Kaliningrad

RU

Europe/Moscow

UA

Europe/Simferopol

RU

Europe/Kirov

RU

Europe/Astrakhan

RU

Europe/Volgograd

RU

Europe/Saratov

RU

Europe/Ulyanovsk

RU

Europe/Samara

RU

Asia/Yekaterinburg

RU

Asia/Omsk

RU

Asia/Novosibirsk

RU

Asia/Barnaul

RU

Asia/Tomsk

RU

Asia/Novokuznetsk

RU

Asia/Krasnoyarsk

RU

Asia/Irkutsk

RU

Asia/Chita

RU

Asia/Yakutsk

RU

Asia/Khandyga

RU

Asia/Vladivostok

RU

Asia/Ust-Nera

RU

Asia/Magadan

RU

Asia/Sakhalin

RU

Asia/Srednekolymsk

RU

Asia/Kamchatka

RU

Asia/Anadyr

RW

Africa/Kigali

SA

Asia/Riyadh

SB

Pacific/Guadalcanal

SC

Indian/Mahe

SD

Africa/Khartoum

SE

Europe/Stockholm

SG

Asia/Singapore

SH

Atlantic/St_Helena

SI

Europe/Ljubljana

SJ

Arctic/Longyearbyen

SK

Europe/Bratislava

SL

Africa/Freetown

SM

Europe/San_Marino

SN

Africa/Dakar

SO

Africa/Mogadishu

SR

America/Paramaribo

SS

Africa/Juba

ST

Africa/Sao_Tome

SV

America/El_Salvador

SX

America/Lower_Princes

SY

Asia/Damascus

SZ

Africa/Mbabane

TC

America/Grand_Turk

TD

Africa/Ndjamena

TF

Indian/Kerguelen

TG

Africa/Lome

TH

Asia/Bangkok

TJ

Asia/Dushanbe

TK

Pacific/Fakaofo

TL

Asia/Dili

TM

Asia/Ashgabat

TN

Africa/Tunis

TO

Pacific/Tongatapu

TR

Europe/Istanbul

TT

America/Port_of_Spain

TV

Pacific/Funafuti

TW

Asia/Taipei

TZ

Africa/Dar_es_Salaam

UA

Europe/Kiev

UA

Europe/Uzhgorod

UA

Europe/Zaporozhye

UG

Africa/Kampala

UM

Pacific/Midway

UM

Pacific/Wake

US

America/New_York

US

America/Detroit

US

America/Kentucky/Louisville

US

America/Kentucky/Monticello

US

America/Indiana/Indianapolis

US

America/Indiana/Vincennes

US

America/Indiana/Winamac

US

America/Indiana/Marengo

US

America/Indiana/Petersburg

US

America/Indiana/Vevay

US

America/Chicago

US

America/Indiana/Tell_City

US

America/Indiana/Knox

US

America/Menominee

US

America/North_Dakota/Center

US

America/North_Dakota/New_Salem

US

America/North_Dakota/Beulah

US

America/Denver

US

America/Boise

US

America/Phoenix

US

America/Los_Angeles

US

America/Anchorage

US

America/Juneau

US

America/Sitka

US

America/Metlakatla

US

America/Yakutat

US

America/Nome

US

America/Adak

US

Pacific/Honolulu

UY

America/Montevideo

UZ

Asia/Samarkand

UZ

Asia/Tashkent

VA

Europe/Vatican

VC

America/St_Vincent

VE

America/Caracas

VG

America/Tortola

VI

America/St_Thomas

VN

Asia/Ho_Chi_Minh

VU

Pacific/Efate

WF

Pacific/Wallis

WS

Pacific/Apia

YE

Asia/Aden

YT

Indian/Mayotte

ZA

Africa/Johannesburg

ZM

Africa/Lusaka

ZW

Africa/Harare

Glossary

API

Application Programming Interface

CA

Certification Authority

CRL

Certificate Revocation List

HTTP

HyperText Transport Protocol

HTTPS

HyperText Transport Protocol Secure

JSON

JavaScript Object Notation

PEM

Privacy Enhanced Mail

URL

Simple Object Access Protocol

SSL

Secure Socket Layer

SIEM

Security Information and Event Management

TLS

Transport Layer Security

URI

Universal Resource Indicator

URL

Universal Resource Locator

URL

Web Service Definition Language

URL

Extensible Markup Language

URL

XML Schema Definition