OptimaWSI configuration

To configure OptimaWSI, you need to edit the following files:

File Installation path Description

module.xml

/opt/ptv-optima-vv.n.xxxxmodules/com/sistemaits/optima/main

Configuration file for the module API.

log4j.xml

/opt/ptv-optima-vv.n.xxxxoptima/

Configuration file for the logging system.

optima-configuration.xml

/opt/ptv-optima-vv.n.xxxxptv-optima-as/standalone/configuration/optima/optima-configuration.xml

Optima configuration file.

$INSTALL_PATH is the Optima installation path (see → Installation scenarios).

Modification during execution

You can modify the configuration files log4j.xml and optima-configuration.xml during the execution of OptimaWSI. Any changes immediately take effect on the system.

The configuration files are XML files.

The notation parent.child = CONTENT refers to the content of the child node of a parent node: 

                    <parent>
    <child>CONTENT</child>
</parent>

The notation parent.child[attr] = CONTENT refers to the value of the attribute named attr of the parent.child element:

                    <parent>
    <child attr="CONTENT"></child>
</parent>

In the configuration files, you can use an XPath-like notation to refer to a value defined elsewhere in the XML file.The XPath syntax defines an order of exploration of the XML file.

Example

The syntax ${defaults/optimaJSLibrary/urls/auth} is semantically equivalent to “use the value of the XML node defaults.optimaJSLibrary.urls.auth”, that is: 

                    <defaults>
    <optimaJSLibrary>
        <urls>
            <ayth>VALUE</ayth>
        </urls>
    </optimaJSLibrary>
</defaults>

For brevity of notation, the root node <configurations> is omitted in the descriptions. All parameters defined in a certain section of /opt/ptv-optima-vv.n.xxxxptv-optima-as/standalone/configuration/optima/optima-configuration.xml inherit its hierarchy. For example:

Datasource section PATH: configuration.dataSource
jndi JNDI name of the datasource registered in the application server

The XPath full path to the <jndi> node is given by:

                    <configurations>
    <configuration>
        <dataSource>
            <jndi>VALUE</jndi>
        </dataSource>
    </configuration>
</configurations>

XPath: default

This section contains the definition of some of the values ​​used in the various configurations.

XPath: configuration

Each <configuration> node contains a configuration for the installation of Optima.

Parameter Description
configuration[name] Identifier of the configuration. This value must be added to all HTTP requests to the modules of Optima.
configuration[description] Description of the configuration, shown in the Traffic Supervisor login section.

XPath: configuration.dataSource

This section contains information about the connection to the Optima database.

Parameter Description
jndi JNDI connection string to the database as defined in the application server.
validateSchema If TRUE, OptimaWSI verifies the correctness of the database scheme and records any discrepancies in the log file.
buildIfInvalid If TRUE, the module attempts to align the scheme on the current data structure.
hibernate.hibernate_connection_datasource JNDI connection to the database.
hibernate.dialect Type of the database.
hibernate.show_sql If TRUE, OptimaWSI records the SQL queries made in the log file.

XPath: configuration.optimaAuth

This section contains the configuration settings for the authentication module and for user profiling.

Optima DB authentication is always enabled.

You can also add user authentication via the LDAP (<ldap> tag).

Parameter Description

bcrypt-cost

Contains the cost factor used as input for the Bcrypt algorithm, to increase the number of iterations performed and the associated computation time.

The bcrypt-cost value scales the computation power and helps to protect OPTIMA from brute force attacks.

If you want to increase the default value, check the presence:

  • Of a specific security alert suggesting the update.
  • Of the CPU power used to run OPTIMA.

Data type: Integer.

Default value: 12.

sessionTimeout

Validity of the session measured in hours.

Default value: 8

ldap.enabled

Defines if LDAP authentication is enabled.

Possible values:

  • true: LDAP enabled. Both authentication via LDAP and Optima DB work simultaneously.

  • false: LDAP disabled.

Example:

<ldap>
	<enabled>true</enabled>
	<server-name>...</server-name>
	<domain-name>...</domain-name>
	<provider-url>ldap://<LDAP_IP_ADDRESS>:<PORT_NUMBER></provider-url>
	<username>...</username>
	<password>...</password>
</ldap>

You can disable LDAP authentication also by deleting the entire node <ldap>...</ldap>.

ldap.server-name

Name of the LDAP server that contains the user directory.

Mandatory only if:

userProvider = java:module/ldapUserProvider.

ldap.domain-name

String type.

Name of the LDAP domain, specified as a dot separated string.

Example: dom.5t.torino.it.

This string corresponds to the root directory hosting Active Directory users.

Example: DC=dom,DC=5t,DC=torino,DC=it

Mandatory only if:

userProvider = java:module/ldapUserProvider.

provider-url

URL of the LDAP server. The common format is:

ldap://<LDAP_IP_ADDRESS>:<PORT_NUMBER>

The default <PORT_NUMBER> is 389.

ldap.username

ldap.password

Username and password to access the LDAP Active Directory.

These credentials are provided by the customer.

Mandatory only if:

userProvider = java:module/ldapUserProvider.
cache.users.enabled

Boolean parameter:

  • true: activates caching of sessions and users.
  • false:otherwise.

Caching can really improve system performance.

cache.users.settings

Additional settings for the cache.

cache.users.track-stats

Boolean parameter:

  • true: enables statistical data collections on the use of the cache; highly impacting for performances, can be limited to debug activity.
  • false:default value for production systems.

cookie.sameSite

Defines a property to limit the possibility to send Optima cookies.

Possible values:

  • Strict: Cookies are not sent with requests initiated by third party websites.
  • Lax: Cookies are not sent on normal cross-sites (for example, to load images or frames into a third party site), but they are sent when a user is navigating to the origin site (for example, following a link).
  • None: Cookies are sent in all contexts.

A setting different from Strict is necessary only if there is some specific requirement external to Optima to send Optima cookies to a third party site.

Default value: Strict

An example of configuration:

                                    <cookie>
     <sameSite>Strict</sameSite>
     <secure>true</secure>
     <httpOnly>true</httpOnly>
</cookie>

cookie.secure

Defines the management of the Optima cookies.

Possible values:

  • true: A cookie is sent to the server only with an encrypted request over the HTTPS protocol, never with unsecured HTTP.
  • 1: Identical as true.
  • false: A cookie is sent to the server both on HTTPS/HTTP, useful if some customer wants to use any installed GUIs using Optima authentication, indifferently via HTTPS/HTTP.
  • 0: Identical as false.

Default value: false.

Important:  Do not assume that cookie.secure=true prevents all access to sensitive information in cookies. For example, it can be read and modified by someone with access to the client's hard disk (or JavaScript if the cookie.httpOnly= true is not set).

cookie.httpOnly

Defines a property to mitigate attacks via JavaScript.

Possible values:

  • true: The cookie is sent only to the server. For example, cookies that persist in server-side sessions don't need to be available to JavaScript, and should have cookie.httpOnly=true.
  • 1: Identical as true.

  • false: If some custom GUI uses JavaScript to manipulate the session cookie. The listed Optima GUIs support cookie.httpOnly=true:

  • 0: Identical as false.

Default value: false

XPath: configuration.tre

You can configure different instances of TRE. All necessary configurations are listed in the table:

Parameter Description
url Contains the URL of the active TRE instance.

exec

String value.

Contains the application name: TRE.exe.

execPath

String value.

Contains the installation path of the application exec.

flog

String value.

Contains the log file name: optima_LogFile_TRE.log.

tablePrefix

Not applicable.

tableSuffix

Not applicable.

enableMessagingForTime

Boolean value.

It can be set to:

  • true: Enables you to query TRE about the time.
  • false: Otherwise.

enableMessagingForStatus

Boolean value.

It can be set to:

  • true: Enables you to query TRE about the status of the message.
  • false: Otherwise.

pollingInterval

Integer value.

Contains the time period, measured in milliseconds, used for polling the TRE web service to query the system time.

The example shows all available parameters to configure two distinct instances, TRE_lab and TRE_tattico.

<configurations>
....
        <tre reloadingTimer="-1">
        <!-- If you need more instances of TRE add more nodes. The name of the node will be the name of the instance -->
            <TRE_lab>
                <url>http://127.0.0.1:1800/tre</url>
                <exec>TRE.exe</exec>
                <execPath>C:\optima\TRE\</execPath>
                <flog>optima_LogFile_TRE.log</flog> 
                <tablePrefix></tablePrefix>
                <tableSuffix></tableSuffix> 
                <enableMessagingForTime>true</enableMessagingForTime>
                <enableMessagingForStatus>true</enableMessagingForStatus>
                <pollingInterval>10000</pollingInterval>
            </TRE_lab>
            <TRE_tattico>
                <url>http://127.0.0.1:6666/tre</url>
                <exec>TRE.exe</exec>
                <execPath>C:\optima\TRE_finto\</execPath>
                <flog>optima_LogFile_TRE.log</flog> 
                <tablePrefix></tablePrefix>
                <tableSuffix></tableSuffix> 
                <enableMessagingForTime>true</enableMessagingForTime>
                <enableMessagingForStatus>true</enableMessagingForStatus>
                <pollingInterval>10000</pollingInterval>
            </TRE_tattico>
        </tre>
....
</configurations>

XPath: configuration.proxy

Each proxy must be configured in a separate node. The node’s name represents the ID of the service (→ OptimaWSI proxy service).

You can configure several <idproxyK>.

The configuration of the type of proxy depends on the identifier specified in:

  • The <url> tag.
  • The <file> tag.
  • The <filedownload> tag.
  • The <exec> tag.

The following example shows the definition of two proxies: one HTTP proxy and one file proxy.

                    <proxy>
    <idproxy1>
        <url>http://www.google.com</url>
    </idproxy1>
    <idproxy2>
        <file>/opt/test.xml</file>
    </idproxy2>
</proxy>

Important:   In case of a file proxy, OptimaWSI must have the required permissions to access the file system.

In the following table, <idproxy> refers to the value given to the identifier node.

Parameter Description

<idproxy>.url

Specifies the HTTP address to which the POST or GET request can be sent.

<idproxy>.file

Absolute path to the file to be sent as a response to a request.

You can define a path consisting of parameters whose value is extrapolated from the query string of the HTTP request.

Example:

  • Path: /opt/test_%(value).xml
  • Query: /proxy/<idproxy/?value=100
  • Result: /opt/test_100.xml

<idproxy>.fileDownload

Absolute path to the file to be downloaded.

<idproxy>.exec

Absolute path to the executable file.

The path must be separated from the name of the executable file with a comma. Optional parameters to pass to the executable file can be added by separating them with a comma.

Example:

<path>,<fileName>[,param1[,param2…]]

XPath: configuration.admin-dashboard

You can define the list of modules from which you can invoke remote commands.

All the modules that expose a SOAP service based on a WSDL publication can be integrated into the administration dashboard (→ OptimaWSI administration dashboard).

Parameter Description
rpc.<name> URL of the module’s SOAP interface.

For each entry, an item will be defined in the Management menu of the administration dashboard. The name of the menu item is defined by <name>.

The following table shows the root node of the configuration of additional Optima modules.

Root node Description
configuration.TrafficSupervisor Nodes with the configuration of the operator interface of Traffic Supervisor.
configuration.vms-interface Configuration of the SI.MO.NE Interface.
configuration.datex-interface Configuration of the DATEX Interface.