Integration Server 10.11 | Integration Server Administrator's Guide | Server Configuration Parameters | watt.security.
 
watt.security.
watt.security.cert.wmChainVerifier.enforceExtensionsChecks
Specifies whether Integration Server is to validate (true) or not validate (false) certificate extensions, if any, when the server performs certificate verification. The default is false.
watt.security.cert.wmChainVerifier.trustByDefault
In cases where no truststore alias is set in the Truststore Alias field on the Security > Certificates page, specifies whether Integration Server is to trust:
*Certificates presented by peer servers (in response to this server's outbound request)
*S/MIME signatures
Specifies whether the Integration Server is to trust (true) or not trust (false) certificates and S/MIME signatures in this situation. The default is true. For improved security, Software AG recommends that you set this parameter to false and set a truststore alias in the Truststore Alias field on the Server > Certificates page.
watt.security.decrypt.keyAlias
Specifies the alias of the default private key Integration Server uses for decryption. There is no default value for this parameter.
The watt.security.decrypt.keyAlias parameter displays the value set in the Key Alias field under Decryption Key on the Security > Certificates page.
watt.security.decrypt.keyStoreAlias
Specifies the alias of the keystore containing the default private key Integration Server uses for decryption. There is no default value.
The watt.security.decrypt.keyStoreAlias parameter displays the value set in the Keystore Alias field under Decryption Key on the Security > Certificates page.
watt.security.fips.mode
Specifies whether the server is to support FIPS (Federal Information Processing Standards). The default is false. If this parameter is set to true, the server initializes FIPS as part of server startup. If FIPS initialization fails, the error is logged to server.log and the server shuts down.
watt.security.kerberos.client.useSPNEGO
Specifies whether Integration Server generates a SPNEGO-based Kerberos ticket for all outbound requests that use Kerberos authentication. When set to true, for all outbound requests that use Kerberos authentication, Integration Server generates a SPNEGO token using SPNEGO OID (Object Identifier). When set to false, Integration Server generates a Java Kerberos ticket using the JGSS Kerberos OID. The default value for this property is false.
watt.security.KeystoreAndTruststore.defaultAliasCreated
This is an internal parameter. Do not modify.
watt.security.keyStore.supportedTypes
Specifies the keystore types supported by Integration Server. Each supported type is separated by a comma. The default values are JKS and PKCS12.
To specify additional keystore types for Integration Server, you need to do the following:
1. Add the new keystore type to the list of values for this property.
2. Add the keystore provider, using one of the following methods:
a. Using the "Add Security Provider" link in Integration Server Administrator.
b. Modifying the "java.security" file of the JVM (you must use this method for a PKCS11-type keystore).
Note:Software AG does not guarantee the behavior of additional keystore types, and does not provide support for them.
watt.security.max.contentLength
Specifies the maximum size limit of the payload for an HTTP request. If watt.security.max.contentLength is greater than 0 and Integration Server receives an HTTP request with a Content-Length header greater than watt.security.max.contentLength, Integration Server rejects the request with a 413 Payload Too Large error and then closes the connection. If watt.security.max.contentLength is greater than 0 and Integration Server receives a request with no Content-Length in the request header, Integration Server rejects the request with a 411 Length Required error and then closes the connection. Set this parameter to a value greater than 0 to enforce a maximum Content-Length. The default value for watt.security.max.contentLength is 0 which means that Integration Server does not enforce a maximum Content-Length.
Note:
Take care when setting the watt.security.max* server configuration parameters. If the parameters values are set too low, Integration Server rejects legitimate requests. It is also possible to lock yourself out of Integration Server Administrator by setting the parameters too low. If this happens, you can try changing the configuration parameter values by invoking the wm.server.admin:setSettings service with a command-line HTTP client. If you are still unable to change the value of these parameters, you need to kill the Integration Server process, manually edit the parameters in the Integration Server_directory /instances/instanceName/config/server.cnf file, and restart Integration Server.
watt.security.max.headerLength
Specifies the maximum length of the header for an HTTP request. If watt.security.max.headerLength is greater than 0 and a request received by Integration Server has a header longer than watt.security.max.headerLength, Integration Server rejects the request with a 431 Request Header Fields Too Large error and then closes the connection. When determining the length of the header, Integration Server considers the keys and values of all the request header fields and all the whitespace characters in the request header. Set this parameter to a value greater than 0 to enforce a maximum request header length. The default value for watt.security.max.headerLength is 0 which means that Integration Server does not enforce a maximum header length.
Note:
Take care when setting the watt.security.max* server configuration parameters. If the parameters values are set too low, Integration Server rejects legitimate requests. It is also possible to lock yourself out of Integration Server Administrator by setting the parameters too low. If this happens, you can try changing the configuration parameter values by invoking the wm.server.admin:setSettings service with a command-line HTTP client. If you are still unable to change the value of these parameters, you need to kill the Integration Server process, manually edit the parameters in the Integration Server_directory /instances/instanceName/config/server.cnf file, and restart Integration Server.
watt.security.max.urlLength
Specifies the maximum length of the URL for an HTTP request. If watt.security.max.urlLength is greater than 0 and Integration Server receives a request with a URL longer than watt.security.max.urlLength, Integration Server rejects the request with a 414 URI Too Long error and then closes the connection. When determining the length of the URL, Integration Server considers the path and the query parts of the URL. Set this parameter to a value greater than 0 to enforce a maximum URL length. The default value for watt.security.max.urlLength is 0 which means that Integration Server does not enforce a maximum URL length.
Note:
Take care when setting the watt.security.max* server configuration parameters. If the parameters values are set too low, Integration Server rejects legitimate requests. It is also possible to lock yourself out of Integration Server Administrator by setting the parameters too low. If this happens, you can try changing the configuration parameter values by invoking the wm.server.admin:setSettings service with a command-line HTTP client. If you are still unable to change the value of these parameters, you need to kill the Integration Server process, manually edit the parameters in the Integration Server_directory /instances/instanceName/config/server.cnf file, and restart Integration Server.
watt.security.min.bytesPerSecond
Specifies the minimum rate at which data may arrive at Integration Server. If data arrives more slowly than the watt.security.min.bytesPerSecond value, Integration Server rejects the request with a 408 Request Timeout error and then closes the connection. The rate is calculated for each request. Each time a request is received by Integration Server, the rate at which Integration Server reads bytes from the socket is monitored. When Integration Server reads the end of the socket's InputStream, Integration Server stops the monitoring for that request.
Set this parameter to a value greater than 0 to enforce a minimum rate of data arrival. The default value for watt.security.min.bytesPerSecond is 0 which means that Integration Server does not enforce a minimum rate of data arrival.
Integration Server can enforce the watt.security.min.bytesPerSecond value only for requests where Integration Server is actually reading the bytes. In some cases, the reading of the bytes is controlled by a customer's application or by a third-party library. In these cases, Integration Server is not reading the incoming bytes and cannot monitor the rate at which they arrive. Integration Server does not enforce the watt.security.min.bytesPerSecond value in these scenarios:
*When the request payload is JSON and watt.server.http.jsonFormat is stream
*When the request payload is XML and watt.server.http.xmlFormat is stream
*When the request contains no Content-type header
*When enhanced XML parsing is being used
*When using the pub.xml NodeIterator services
*For SOAP requests
You may need to set watt.security.min.bytesPerSecond to a lower value if your application uses these features.
Take care when setting the watt.security.min.bytesPerSecond configuration parameter. If the parameter value is set too high, Integration Server may reject legitimate requests being sent over a slow network. It is also possible to lock yourself out of the Integration Server Administrator user interface by setting the parameter too high. If this happens, you can try changing the configuration parameter value by invoking the wm.server.admin:setSettings service with a command-line HTTP client. If you are still unable to change the value of this parameter, you need to kill the Integration Server process, manually edit the parameter in the Integration Server_directory /instances/instanceName/config/server.cnf file, and restart Integration Server.
watt.security.ope.AllowInternalPasswordAccess
Specifies whether the built-in services supporting OPE (outbound password encryption) for flow services may access the Integration Server's internal passwords. If this parameter is set to true, the OPE services may access the internal passwords. If it is set to false, the OPE services are not allowed access to the internal passwords. By default, this parameter is set to false.
Internal passwords are passwords for use by the Integration Server itself to access secure resources (e.g., remote Integration Servers, JDBC connection pools, LDAP servers, etc.). Internal passwords are managed using the Integration Server Administrator and are stored in the outbound password store. Flow services are also allowed to store passwords in the outbound password store. However, by default, passwords stored by a flow service are considered public, as opposed to internal. This distinction allows flow services to use the outbound password store as a secure mechanism for storing and retrieving passwords, but protects the Integration Server's internal passwords.
You can allow flow services to access internal passwords (i.e., store, retrieve, and modify) by setting watt.security.ope.AllowInternalPasswordAccess to true. However, this should be done only if you explicitly wish to have a flow service work with internal passwords. Otherwise, it is recommended you deny access to internal passwords by setting watt.security.ope.AllowInternalPasswordAccess to false.
watt.security.openid.logExceptions
Specifies whether Integration Server writes OpenID errors to the error log. When the OpenID authentication process encounters errors, Integration Server returns error and error_description variables in the body of the HTTP response. When watt.security.openid.logExceptions is true, the default, Integration Server throws an exception from the redirection endpoint service, causing the error to be written to the error log. To stop Integration Server from writing OpenID errors to the error log, set watt.security.openid.logExceptions to false.
watt.security.pub.getFile.checkReadAllowed
Specifies whether the pub.file:getFile service is to check the allowedReadPaths property in the fileAccessControl.cnf file to determine if the requested file can be retrieved from the file system. The allowedReadPaths property contains a list of directories to which the services in the pub.file folder have read permission.
When watt.security.pub.getFile.checkReadAllowed is set to true, the pub.file:getFile service checks the allowedReadPaths property in the fileAccessControl.cnf file. If the requested file or file directory is listed, the pub.file:getFile service returns its contents to the pipeline.
If watt.security.pub.getFile.checkReadAllowed is set to true and the file or file directory is not listed in the allowedReadPaths property, the pub.file:getFile service throws an exception.
When watt.security.pub.getFile.checkReadAllowed is set to false, the pub.file:getFile service retrieves the specified file from the local file system without checking the fileAccessControl.cnf file.
The default value is false.
Changes to this property take effect immediately. However, if you modify the fileAccessControl.cnf file, the WmPublic package must be reloaded before the changes take effect.
For more information about the pub.file:getFile service and configuring the fileAccessControl.cnf file, see webMethods Integration Server Built-In Services Reference.
watt.security.session.forceReauthOnExpiration
Specifies whether Integration Server accepts or rejects a request that includes an expired or invalid session. When set to true, Integration Server rejects any request that includes a cookie identifying an expired or invalid session, even if the request includes valid user credentials. The rejection response directs the browser to clear its session identifier and to prompt the user for credentials. When set to false, Integration Server creates a new session using the credentials in the cookie. The default value is true. A value of true offers more secure behavior.
Note:
Integration Server does not support this parameter in the new Integration Server Administrator (<host: port>/WmAdmin) due to a different login mechanism that uses only the session ID. Each time the session ID expires and you do not provide valid user credentials, login fails.
watt.security.sign.keyAlias
Specifies the alias of the default private key Integration Server uses to digitally sign documents. There is no default value for this parameter.
The watt.security.sign.keyAlias parameter displays the value set in the Key Alias field under Signing Key on the Security > Certificates page.
watt.security.sign.keyStoreAlias
Specifies the alias of the keystore containing the default private key Integration Server uses to digitally sign documents. There is no default value for this parameter.
The watt.security.sign.keyStoreAlias parameter displays the value set in the Keystore Alias field under Signing Key on the Security > Certificates page.
watt.security.ssl.cacheClientSessions
Controls whether Integration Server reuses previous SSL session information (for example, client certificates) for connections to the same client. When this property is set to true, Integration Server caches and reuses SSL session information. For example, set this property to true when there are repeated HTTPS requests from the same client. If set to false (the default), Integration Server does not cache the sessions and creates a new session for every SSL handshake.
Note:
Setting the property to false might decrease performance.
watt.security.ssl.cachedClientSessions.sweeperInterval
Specifies, in milliseconds, how often Integration Server checks for and removes expired SSL client sessions from its session cache. The default value is 600000 milliseconds (10 minutes).
watt.security.ssl.client.ignoreEmptyAuthoritiesList
Specifies whether an Integration Server acting as a client sends its certificate chain after a remote SSL server returns an empty list of trusted authorities. When set to true, Integration Server disregards the empty trusted authorities list and sends its chain anyway. When set to false, before sending out its certificate chain, Integration Server requires the presentation of trusted authorities list that proves itself trusted. The default is false.
watt.security.ssl.ignoreExpiredChains
Specifies whether the Integration Server ignores expired CA certificates in a certificate chain it receives from an Internet resource (i.e., a web server, another Integration Server). To have the Integration Server ignore expired CA certificates and allow SSL connections when a certificate is expired, set the watt.security.ssl.ignoreExpiredChains setting to true. Note that this is less secure than denying connections when a certificate is expired. The default is false. For more information about this setting, see Configuring Integration Server for Secure Communications.
watt.security.ssl.keyAlias
Specifies the alias of the Integration Server default SSL private key. There is no default value for this parameter.
The watt.security.ssl.keyAlias parameter displays the value set in the Key Alias field under SSL Key on the Security > Certificates page.
watt.security.ssl.keypurposeverification
When Integration Server is acting as an HTTPS client, this parameter specifies whether the server should restrict outbound HTTPS connections only when a valid Extended Key Purpose field is present in the server's certificate. The content of the Key Purpose field, id-kp-serverAuth, should be in the IETF-mandated format, TLS WWW server authentication for the verification to pass. Refer to the section titled Extended Key Usage, in the document http://www.ietf.org/rfc/rfc3280.txt for more information regarding this format.
Three values are allowed for this watt property - true, false and log.
*When set to true, it will verify the presence of the key purpose field in the server's certificate. If the key purpose verification fails, an error is logged and the connection is aborted. If the verification succeeds, no error is logged.
*When set to false, it will bypass the verification of the key purpose field. The default is false.
*When set to log, it will log a debug message in the server log if the key purpose field verification fails.watt.security.ssl.keyStoreAlias Specifies the alias of the Integration Server default SSL keystore.
watt.security.ssl.keyStoreAlias
Specifies the alias of the Integration Server default SSL keystore. There is no default value for this parameter.
The watt.security.ssl.keyStoreAlias parameter displays the value set in the Keystore Alias field under SSL Key on the Security > Certificates page.
watt.security.ssl.resumeClientSessions
Controls whether Integration Server acting as a client, reuses the previous SSL session information for connections to the same server.
*If watt.security.ssl.resumeClientSessions is to set to true and:
*Integration Server acts as an HTTPS client, then Integration Server caches the SSL sessions and reuses the SSL session information for future requests to the same server.
*Integration Server acts as an FTPS client, then Integration Server uses the same SSL session for command and data channel.
*If watt.security.ssl.resumeClientSessions is to set to false and:
*Integration Server acts as an HTTPS client, then Integration Server does not cache the SSL sessions and creates a new SSL session for every SSL handshake.
*Integration Server acts as a FTPS client, then does not cache the SSL sessions and creates a new SSL session for command and data channel. The default value is false.
watt.security.trustStore.supportedTypes
Specifies the truststore types supported by Integration Server. Each supported type is separated by a comma. The default value is JKS.
To specify additional truststore types for Integration Server, you need to do the following:
1. Add the new truststore type to the list of values for this property.
2. Add the truststore provider, using one of the following methods:
a. Using the "Add Security Provider" link in Integration Server Administrator.
b. Modifying the "java.security" file of the JVM.
Note:Software AG does not guarantee the behavior of additional truststore types, and does not provide support for them.
watt.security.trustStoreAlias
Specifies the alias for the truststore that Integration Server uses as the default truststore.
When Integration Server is acting as a server, it uses the default truststore to verify the trust relation when no truststore is provided. For example, Integration Server uses the default truststore when no truststore is provided for HTTPS/FTPS ports or for web service security when there is no truststore at the provider web service endpoints alias.
When Integration Server is acting as a client, most of the components in Integration Server (for example, HTTPS, FTPS, remote server alias) always use the default truststore to verity the trust relation with the server. However, for web service security, Integration Server only uses the default truststore when the user does not provide a truststore in the consumer endpoint alias.
The watt.security.trustStoreAlias parameter displays the value set in the Truststore Alias field under Truststore on the Security > Certificates page.