watt.security.
- watt.security.algorithm.replaceMD5
Specifies whether Integration Server is to stop using the MD5 hashing algorithm and instead use SHA-256 for internal purposes. Set to true to use the stronger SHA-256 algorithm. Set to false only if you must continue using the MD5 algorithm to maintain backward compatibility. The default value is false.
- watt.security.algorithm.replaceSHA1
Specifies whether Integration Server is to stop using the SHA-1 hashing algorithm and instead use SHA-256 for internal purposes. Set to true to use the stronger SHA-256 algorithm. Set to false only if you must continue using the SHA‑1 algorithm to maintain backward compatibility. The default value is false.
- watt.security.allowedDirectories
- Specifies a comma-separated list of directories for which Integration Server
bypasses the path traversal check. If an operation specifies a directory outside of the
Integration Server root directory and the directory is not listed in
watt.security.allowedDirectories, the action that Integration Server takes depends on the value ofwatt.server.file.pathViolation.action. There is no default value for this parameter. - 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 isfalse. - 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 istrue. For improved security, IBM recommends that you set this parameter tofalseand 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 totrue, 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.jaas.restrictSSO
-
Specifies if single sign-on to Integration Server Administrator is supported when a user has already been authenticated via a JAAS login module. When set to false, if JAAS authentication succeeds, access to Integration Server Administrator does not require additional basic authentication credentials. The Integration Server Administrator log in page is skipped and the user is instead redirected to the Dashboard. When set to true, if JAAS authentication succeeds, the user must still provide login credentials when attempting to access Integration Server Administrator. The default is false.
You must restart Integration Server for changes to this parameter to take effect.
- watt.security.CustomJavaServiceExecution
- Specifies whether Integration Server allows the execution of custom Java services. The default value
is
All.Set the parameter to one of the following values:
When set to Integration Server AllAllows the execution of custom Java services.
NoneBlocks the execution of custom Java services.
RestrictedRestricts the execution of all custom Java services. If you want to allow execution of any custom Java services, you can specify them in a comma-separated list within the configuration variable template. For more information, see Configuration Variables Template Assets Configuration Variables Template Assets in .
Note:Nonediffers fromRestricted. When set toNone, Integration Server blocks invocation of a custom Java service, regardless of whether the service is listed in a comma-separated format within the configuration variable template. - 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:
- Add the new keystore type to the list of values for this property.
-
Add the keystore provider, using one of the following methods:
- Using the "Add Security Provider" link in Integration Server Administrator.
-
Modifying the "java.security" file of the JVM (you must use this method for a PKCS11-type keystore).
Note: IBM 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 tofalse, the OPE services are not allowed access to the internal passwords. By default, this parameter is set tofalse.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 tofalse. - 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
trueand 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 IBM 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 totruewhen there are repeated HTTPS requests from the same client. If set tofalse(the default), Integration Server does not cache the sessions and creates a new session for every SSL handshake.Note: Setting the property tofalsemight 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.ignoreExpiredChainssetting totrue. Note that this is less secure than denying connections when a certificate is expired. The default isfalse. - 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 authenticationfor 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,falseandlog.- 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 isfalse. - 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.
- When set to
- 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
trueand:-
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
falseand:-
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.
-
- If watt.security.ssl.resumeClientSessions
is to set to
- watt.security.ssl.skipClientEKUCheck
- Specifies whether Integration Server
validates that the client certificate includes the Client Authentication identifier in its Extended
Key Usage (EKU) field during the SSL/TLS handshake.
When set to true, Integration Server skips validation of the Client Authentication identifier in the EKU field. The server accepts client certificates without this identifier and continues with all other certificate validations.
When set to false, Integration Server enforces EKU validation and requires the Client Authentication identifier. Integration Server rejects certificates without this identifier.
The default value is false.
You do not have to restart Integration Server for the change to take effect.
Note: This server configuration parameter is introduced for PIE-103322 in IS_11.1_Core_Fix10. - watt.security.trustStore.supportedTypes
- Specifies the truststore types supported by Integration Server. Each supported type is separated by a comma. The default values are JKS and PKCS12.
To specify additional truststore types for Integration Server, you need to do the following:
- Add the new truststore type to the list of values for this property.
-
Add the truststore provider, using one of the following methods:
- Using the "Add Security Provider" link in Integration Server Administrator.
-
Modifying the "java.security" file of the JVM.
Note: IBM 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.