Squash TM Main Configuration

Startup file

Memory allocation

The memory allocated to the JVM for running Squash TM can be configured in the startup file via the following properties:

startup.sh file:

JAVA_ARGS="-Xms128m -Xmx20248m -server"

startup.bat file:

set JAVA_ARGS=-Xms128m -Xmx2048m %SERVER_MODE%

The recommended configuration for the maximum Java heap size (-Xmx) is 2GB for a standard sizing of Squash TM.
In case of high volume of data, you can increase this value to guarantee the performance during bulk processing (searches, exports, reports).

Necessary memory

Make sure that the server on which the application is installed has enough RAM to handle all the memory necessary for:

the heap size (-Xms, -Xmx)
the metaspace (-XX:MetaspaceSize, -XX:MaxMetaspaceSize)
the stack of each thread (-Xss)
the code cache (-XX:ReservedCodeCacheSize)
other (arena, byte buffers…)

The server should have more memory than -Xmx + -XX:MaxMetaspaceSize + -XX:ReservedCodeCacheSize + 128MB.
See the Java documentation for more information.

Access Port

You can change the server's default port in the file \bin\startup. Search for the following line and replace port 8080 by the port you want:

[...]
set HTTP_PORT=8080 
[...]

Info

Please note that the system will not verify that the chosen port is available. Thus, make sure that it is the case by contacting the system administrator.

Squash TM's Configuration File

This paragraph describes the configuration parameters available in the configuration file (conf/squash.tm.cfg.properties) of Squash TM.

Focus

Once the changes have been done and the squash.tm.cfg.properties file (or the auxiliary configuration file) has been saved, you must restart Squash TM for them to be taken into account.

Other configuration methods

Squash TM is using Spring Boot which provides many mechanisms, other than modifying the squash.tm.cfg.properties file, to define the values of configuration parameters: environment variables, JSON embedded in SPRING_APPLICATION_JSON… Refer to the Sprint Boot documentation to get the exhaustive list of ways to define these values.
For example, if you want to start Squash TM in Docker while setting squashtm.stack.trace.control.panel.visible to true, you can use:

docker run --name='squash-tm' --env SQUASHTM_STACK_TRACE_CONTROL_PANEL_VISIBLE=true -it -p 8090:8080 squashtest/squash:9.0.8

Configuration Management

Parameter	Description	Default	Notes
`spring.profiles.include`	Allows splitting configuration into multiple files	-	since Squash TM 1.18.0 A Comma-separated list of identifiers. Auxiliary configuration files must be named either `squash.tm.cfg-<ident>.properties` or `application-<ident>.properties`.

Tomcat

Parameter	Description	Default	Notes
`server.servlet.session.timeout`	Sets the session timeout	`3600` (seconds)	-
`server.tomcat.accesslog.enabled`	Enables Tomcat access logs	`false`	-
`server.tomcat.basedir`	Sets the base directory for Tomcat	`${squash.path.root}/tomcat-work`	-
`server.tomcat.use-relative-redirects`	Ensures internal redirections use HTTPS protocol in HTTPS environments	`true`	`true` or `false`
`server.servlet.context-path`	Squash TM context path	`/squash`	Setting `server.servlet.context-path=/foo` will require users to log in via the `<squash-base-url>/foo` URL

When port 80 is blocked for security reasons, it is necessary to set server.tomcat.use-relative-redirects to true so that internal redirections are systematically done via port 443.

Squash TM Paths

Parameter	Description	Default	Notes
`spring.config.location`	Sets the configuration location	`../conf`	-
`squash.path.root`	Sets the root path for Squash TM	`${spring.config.location}/..`	-
`logging.file.path`	Sets the path for log files	`${squash.path.root}/logs`	-
`squash.path.bundles-path`	Sets the path for bundles	`${squash.path.root}/bundles`	-
`squash.path.plugins-path`	Sets the path for plugins	`${squash.path.root}/plugins`	-
`squash.path.languages-path`	Sets the path for language files	`${spring.config.location}/lang`	-
`squash.path.local-git-repositories-folder`	Sets the path for local Git repositories	`${squash.path.root}/git-repositories`	since Squash TM 8.0.0 See this page.
`squash.project-imports.folder-path`	Sets the path for the files in queue and the logs of imports	`${squash.path.root}/imports`	since Squash TM 8.0.0 See this page for Xray imports.
`squash.report-custom-template.folder-path`	Sets the path for the report custom templates	`${spring.config.location}/report.custom.templates`	since Squash TM 9.0.0 See this page for report templates.

Database update

Parameter	Description	Default	Notes
`squash.db.update-mode`	Enables/disables automatic database updates	`interactive`	since Squash TM 9.0.0 See this page for the possible values.

Security

Parameter	Description	Default	Notes
`squash.security.basic.token-charset`	Defines the encoding for basic auth-secured endpoints	-	since Squash TM 1.16.1 For example: `UTF-8`, `ISO-8859-1`…
`squash.crypto.secret`	Defines the encryption key for credentials of third party tools	-	since Squash TM 1.17.0 Logins and passwords entered for connection to third party tools are encrypted in database by using that encryption key. The application is delivered with a default encryption key, this one must immediately be changed. Should be at minimum 12 characters long, but preferably 16+ characters for strong security. Space and tab are not allowed. For example: `jN9$mK5vP#xR2hL8nQ4&` Changing this key later will make previously stored credentials unusable.
`squash.rest-api.disallow-basic-authentication`	Disallows basic authentication for REST API	`false`	since Squash TM 7.1.0
`squash.rest-api.jwt.secret`	Sets the secret used to encrypt tokens for REST API calls	-	since Squash TM 7.1.0 Must be at least 512 bits and base64 encoded (at least 86 characters). For example: `Ym9uam91cmplc3Vpc2RldmVsb3BwZXVzZXN1cnNxdWFzaHRtZXRub3Vzc29tbWVzZW5sYW5uZWUyMDI0ISEhIS`

Deprecation of basic authentication

In Squash TM 7.1.0, the squash.rest-api.disallow-basic-authentication property is set to false by default.
From mid-2025, it will be true by default for new versions of Squash TM.
From mid-2026, basic authentication (login/password) for API calls will no longer be possible, authentication will have to be by token.

JDBC connection pool

Parameter	Description	Default	Notes
`spring.datasource.hikari.maximumPoolSize`	Configures the connection pool size	`20`	Refer to HikariCP documentation for more details.

Administration Features

Parameter	Description	Default	Notes
`squashtm.feature.file.repository`	Activates/deactivates attachment outsourcing	`false`	`true` or `false` Read documentation before activating.
`squashtm.stack.trace.control.panel.visible`	Shows/hides configuration of stack trace display	`false`	`true` or `false` If `true`, the configuration panel to activate/deactivate error details is visible in the page 'System settings'.

Reports

Parameter	Description	Default	Notes
`report.criteria.project.multiselect`	Enables/disables multiple selections in project pickers	`false`	-

Connection to Bugtrackers

Parameter	Description	Default	Notes
`squashtm.bugtracker.timeout`	Sets the timeout for server attempts to reach a bugtracker.	`15` (seconds)	-
`squash.bugtracker.cache-update-delay`	Sets the delay between bugtracker connector cache updates.	`86400` (seconds)	since Squash TM 7.3.0
`squash.bugtracker.cache-update-cron`	Sets a Cron Expression for the cache update of the bug tracker connectors. If defined, it will override the delay.	-	since Squash TM 9.0.0 Example: `0 0 0 * * *` will update the cache every day at midnight. For more information about Spring Cron Expressions, see Spring CronExpression documentation.
`squash.bugtracker.cache-worker-pool-size`	Sets the number of workers used to update the cache of the bug tracker connectors.	`5`	since Squash TM 9.0.0
`squash.bugtracker.max-results-per-search`	Sets the maximum number of results returned for autocomplete searches on issues.	`50` (results)	since Squash TM 9.0.0 The maximum value is `100`. The minimum value is `5`. It is recommended to lower the value if the GitLab projects used contain a large number of issues.

Bugzilla

Parameter	Description	Default	Notes
`plugin.bugtracker.bugzilla.cache.enable`	Enables/disables the Bugzilla fields cache feature	`false`	`true` or `false` Use this feature if retrieving fields takes a long time. If `true`, all fields of Bugzilla servers will be cached in memory once retrieved.
`plugin.bugtracker.bugzilla.cache-at-start.bugtracker-urls`	Defines the URLs of the bugtrackers that should initialize fields cache when Squash TM starts	-	Use a comma-separated list
`plugin.bugtracker.bugzilla.cache-refresh.cron-expression`	Sets the Cron Expression defining when to perform a refresh of the Bugzilla fields cache	-	For more information about Spring Cron Expressions, see Spring CronExpression documentation.

Excel import

Parameter	Description	Default	Notes
`squash.xls-imports.max-concurrent-imports`	Defines the maximum number of concurrent imports	-	since Squash TM 7.4.0 Squash TM will refuse to perform an Excel import if this limit is reached. This limit is used to avoid overloading Squash TM; its value depends on the CPU and RAM of the server. No value means no limit, this is the default configuration.
`squash.xls-imports.max-test-cases-per-import`	Defines the maximum number of test cases in an import file	-	since Squash TM 7.4.0 Squash TM will refuse to perform an Excel import if this limit is reached. This limit is used to avoid overloading Squash TM; its value depends on the CPU and RAM of the server. No value means no limit, this is the default configuration.
`squash.xls-imports.max-test-steps-per-import`	Defines the maximum number of test steps in an import file	-	since Squash TM 7.4.0 Squash TM will refuse to perform an Excel import if this limit is reached. This limit is used to avoid overloading Squash TM; its value depends on the CPU and RAM of the server. No value means no limit, this is the default configuration.
`squash.xls-imports.max-requirements-per-import`	Defines the maximum number of requirements in an import file	-	since Squash TM 8.0.0 Squash TM will refuse to perform an Excel import if this limit is reached. This limit is used to avoid overloading Squash TM; its value depends on the CPU and RAM of the server. No value means no limit, this is the default configuration.

Project Import

Currently, only Xray project import is available.

Parameter	Description	Default	Notes
`squash.project-imports.delay`	Sets the delay between two import processes	`3600` (seconds)	since Squash TM 8.0.0

Jira and GitLab Synchronizations

Parameter	Description	Default	Notes
`squash.external.synchronisation.enabled`	Enables/disables scheduled processing of all synchronizations	`true`	since Squash TM 7.0.0 `true` or `false`
`squash.external.synchronisation.delay`	Sets the delay between two synchronizations	`300` (seconds)	-
`squash.external.synchronisation.max-items-per-sync`	Sets the maximum number of items in scope when creating a new synchronization	-	since Squash TM 8.0.0

squash.external.synchronisation.enabled enables or disables the scheduled process for all synchronizations.
This property does not affect the attribute activated of the synchronizations.
Switching this property to false can be useful in situations such as:

You do not use synchronizations;
The instance is a pre-production Squash TM having a copy of the production database and you must avoid the synchronizations recorded in the database to run on this instance to not pollute your Jira/GitLab tickets;
You use another Squash TM instance to handle synchronizations.

squash.external.synchronisation.delay defines the delay between two updates, expressed in seconds. If this property is missing or incorrect, the default delay is set to five minutes (300 seconds) and a warning occurs in the Squash TM logs when the application starts. The shorter the delay is, the more resources Squash TM consumes. For most common uses, a delay between 5 and 15 minutes is enough.

Jira

Parameter	Description	Default	Notes
`plugin.synchronisation.jira.batchSize`	Sets the batch size for Jira REST API requests	`50`	-

Xsquash4Jira plugin has a property,plugin.synchronisation.jira.batchSize, defining the size of the batch to update the information from Jira.
The default value is 50, which must be less than or equal to the value jira.search.views.default.max defined in the jira-config.properties property file. That default value works fine with Jira Server, Data Center, and Cloud, if no configuration changes have been made to the Jira instance.

GitLab

Parameter	Description	Default	Notes
`plugin.synchronisation.gitlab.webhook.secret-token`	Defines the optional token used to validate GitLab webhooks	-	See more details here.
`plugin.synchronisation.gitlab.webhook.show-secret-token`	Shows/hides secret token on the plugin administration screen	`true`	`true` or `false` See more details here.

TM-TA

Parameter	Description	Default	Notes
`tm.test.automation.pollinterval.millis`	Sets the polling interval for test automation	`3000` (milliseconds)	-

LDAP and Active Directory

See this page for more information.

Single LDAP

Use these settings to configure authentication with a single LDAP server.

Parameter	Description	Default	Notes
`authentication.provider`	Defines the authentication provider	-	`ldap` or `ldap,internal` for multi-source (i.e. `internal` means that the users can also use their local Squash TM account)
`authentication.ldap.server.url`	Defines LDAP server URL	-	For example: `ldap://localhost:389`
`authentication.ldap.server.managerDn`	Defines the manager user DN (if anonymous access is not allowed)	-	For example: `CN=admin,CN=Users,DC=example,DC=com`
`authentication.ldap.server.managerPassword`	Defines the manager password (if anonymous access is not allowed)	-	For example: `something`
`authentication.ldap.user.searchBase`	Defines the search base DN	-	For example: `DC=example,DC=com`
`authentication.ldap.user.searchFilter`	Defines the search filter	-	For example: `(uid={0})`
`authentication.ldap.user.fetchAttributes`	Defines whether to fetch user attributes	`true`	`true` or `false`
`authentication.ldap.user.dnPatterns`	Defines base DN patterns for user lookup	-	For example: `uid={0},ou=people`

Multi-LDAP

Use these settings to configure authentication with multiple LDAP servers.

Parameter	Description	Default	Notes
`authentication.provider`	Defines the authentication provider	-	`ldap-multi` or `ldap-multi,internal` for multi-source (i.e. `internal` means that the users can also use their local Squash TM account)
`authentication.ldap.multi.root.names`	Defines the names of the multiple LDAP servers	-	For example: `ldap1,ldap2`

For each LDAP server (e.g., ldap1, ldap2), use the following properties, prefixed with the server name:

Parameter	Description	Default	Notes
`[name].authentication.ldap.server.url`	Defines LDAP server URL	-	For example: `ldap://localhost:389`
`[name].authentication.ldap.server.managerDn`	Defines the manager user DN (if anonymous access is not allowed)	-	For example: `CN=admin,CN=Users,DC=example,DC=com`
`[name].authentication.ldap.server.managerPassword`	Defines the manager password (if anonymous access is not allowed)	-	For example: `something`
`[name].authentication.ldap.user.searchBase`	Defines the search base DN	-	For example: `DC=example,DC=com`
`[name].authentication.ldap.user.searchFilter`	Defines the search filter	-	For example: `(uid={0})`
`[name].authentication.ldap.user.fetchAttributes`	Defines whether to fetch user attributes	-	For example: `false`
`[name].authentication.ldap.user.dnPatterns`	Defines base DN patterns for user lookup	-	For example: `uid={0},ou=people`

Single Active Directory

Use these settings to configure authentication with a single Active Directory server.

Parameter	Description	Default	Notes
`authentication.provider`	Defines the authentication provider	-	`ad.ldap` or `ad.ldap,internal` for multi-source (i.e. `internal` means that the users can also use their local Squash TM account)
`authentication.ad.server.url`	Defines the AD server URL	-	For example: `ldap://localhost:389`
`authentication.ad.server.domain`	Defines the AD server domain	-	For example: `ad.squashtest.org`
`authentication.ad.server.managerDn`	Defines the manager user DN	-	For example: `admin`
`authentication.ad.server.managerPassword`	Defines the manager password	-	For example: `something`
`authentication.ad.user.searchBase`	Defines the search base	-	-
`authentication.ad.user.searchFilter`	Defines the search filter	-	For example: `(&(objectClass=user)(userPrincipalName={0}))`

Multi-Active Directory

Use these settings to configure authentication with multiple Active Directory servers.

Parameter	Description	Default	Notes
`authentication.provider`	Defines the authentication provider	-	`ad.ldap-multi` or `ad.ldap-multi,internal` for multi-source (i.e. `internal` means that the users can also use their local Squash TM account)
`authentication.ad.multi.root.names`	Defines the names of the multiple AD servers	-	For example: `ad1,ad2`

For each AD server (e.g., ad1, ad2), use the following properties, prefixed with the server name:

Parameter	Description	Default	Notes
`[name].authentication.ad.server.url`	Defines the AD server URL	-	For example: `ldap://localhost:389`
`[name].authentication.ad.server.domain`	Defines the AD server domain	-	For example: `ad.squashtest.org`
`[name].authentication.ad.server.managerDn`	Defines the manager user DN	-	For example: `admin`
`[name].authentication.ad.server.managerPassword`	Defines the manager password	-	For example: `something`
`[name].authentication.ad.user.searchBase`	Defines the search base	-	-
`[name].authentication.ad.user.searchFilter`	Defines the search filter	-	For example: `(&(objectClass=user)(userPrincipalName={0}))`

SAML

See this page for more information.

Property	Description	Default	Notes
	Main configuration
`saml.enabled`	Enables/disables SAML	`false`	`true` or `false`
`authentication.provider`	Defines the authentication provider	-	`saml` or `saml,internal` for multi-source (i.e. `internal` means that the users can also use their local Squash TM account)
`saml.idp.metadata.url`	Defines the URL or path where the IDP metadata can be found	-	Allowed formats: - `file://absolute/path/to/file`: fetches a file locally by its absolute path - `http://` or `https://metadata.remote-host/path/to/file`: remote download of the metadata via HTTP(S) - `relative/path/to/file`: a path relative to the configuration directory of Squash TM (e.g. `saml/idp.xml`)
`saml.sp.metadata.url`	Defines the URL or path where the SP metadata can be found	-	Allows the same formats as `saml.idp.metadata.url`
`saml.keystore.url`	Defines the URL or path where the keystore can be found	-	Only `file://` or relative path are allowed.
`saml.keystore.password`	Defines the password for the keystore	-	-
`saml.keystore.credentials.?`	Defines the list of aliases/passwords for all the public/private key pairs required by Squash	-	Each property is dynamic and is formatted such as `saml.keystore.credentials.<key-alias> = <key-password>` One entry per key pair, there must be at least one entry because a default key is required by `saml.keystore.default-key`. For example: `saml.keystore.credentials.my-own-key = secretp4ssword`
`saml.keystore.default-key`	Defines the default private key that will be used unless stated otherwise (for example `saml.sp.signing-key`)	-	-
	Entry point
`squash.security.preferred-auth-url`	Sets SAML authentication entry point as the main entry point	`/auth/saml/login`	Unauthenticated users will be automatically redirected to the SAML entry point instead of the regular login form.
	SSO options
`saml.sso.force-authN`	Enables/disables forced reauthentication	`false`	`true` or `false` If enabled, the user will have to reauthenticate with the IDP every time it wants to authenticate with Squash TM. This effectively disables the SSO mechanism.
`saml.sso.provider-name`	Defines a human-readable name that will be included in messages sent to the IDP, useful for logging purposes	(blank)	-
`saml.sso.binding`	Defines which binding Squash TM use to initiate SSO with the IDP	First binding method listed in the `<SingleSignOnService/>` clause of the IDP metadata	For more information, see this document. For example: `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`, `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
`saml.sso.assertion-consumer-index`	Requires the IDP to send its responses to the given consumer service.	The default consumer service in the SP metadata	A non-negative integer or blank The list of available consumer services can be found in the `<AssertionConsumerService/>` clauses in the SP metadata.
`saml.sso.nameID`	Requires the IDP to return the principal with a given NameIDFormat, which is essentially the username of the user in Squash	If blank, the IDP will pick one among those listed in the SP metadata	For example: `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`, `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`
`saml.sso.allow-create`	Notifies the IDP that creating new user is permitted when unknown	`false`	`true` or `false`
`saml.sso.passive`	If enabled Squash TM will inform the IDP that it does not consider user interaction necessary for authentication	-	`true` or `false`
`saml.sso.include-scoping`	If enabled, Squash will add additional scoping constraints when a user authenticates.	`false`	`true` or `false`
`saml.sso.allowed-idps`	Defines, in a multi-layered IDP architecture, which IDPs are allowed to process an authentication requests	-	A comma-separated list of IDPs Note: scoping must be enabled.
`saml.sso.proxy-count`	Defines the maximum proxy hops allowed for authentication messages	`2`	A non-negative integer In this context a proxy is an IDP within a chain of IDPs that can delegate one to the next. A value of 0 forbids the use of proxies and the IDP that receives the authentication request cannot delegate and must authenticate the user himself. Note: scoping must be enabled.
`saml.sso.authn-contexts`	Defines the authentication contexts that should be honored by the IDP when it authenticates the user	(blank, i.e. no specific requirements)	A comma-separated list Useful when the default IDP authentication challenge is not deemed sure enough and Squash TM asks for guarantees of a more stringent process. For example: `urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI`, `urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract` Note: scoping must be enabled. For more information, see this document.
`saml.sso.authn-context-comparison`	Instructs the IDP on how it should process the credentials presented by the user during authentication	`exact`	`exact`, `minimum`, `maximum`, or `better` Note: scoping must be enabled. For more information, see this document.
`saml.sso.relay-state`	Defines an arbitrary token to be sent back and forth to the IDP	(blank)	Part of the SAML specification but Squash TM has no use case for it.
	IDP metadata options
`saml.idp.metadata.require-signature`	If enabled, Squash will require the IDP metadata file itself to be signed	`false`	`true` or `false` Typical use is when the file is downloaded from a remote provider that do not serve HTTPS or you want to apply additional checks on the metadata anyway. IDP MetadataProperties that are not signed will be rejected.
`saml.idp.metadata.check-signature`	If enabled, and if the IDP metadata are signed, will check the signature	`true`	`true` or `false` This involves checking the metadata digest and trust of the certificate. Has no effect if the metadata are not signed.
`saml.idp.metadata.check-certificate-revocation`	If enabled, in addition of checking the trust chain of the certificate, the system will check the expiration/revocation of certificate	`false`	`true` or `false` The exact infrastructure involved in this verification (CLR, OSCP…) is beyond the scope of this configuration file and depends on the JCE provider and the configuration of the keystore, and would be driven by the corresponding system properties.
`saml.idp.metadata.trusted-keys`	Defines the keys considered as trust anchors for PKIX verification of the IDP metadata file	`all`	`all` (all keys in the keystore will be trusted), blank (equivalent to `all`), `none` (none of the keys in the keystore will be trusted), or a comma-separated list of keys (the keys must exist in the keystore).
	IDP options
`saml.idp.signing-key`	Defines an alias of the public IDP key for checking inbound SAML messages signatures	(blank, i.e. the metadata will be used)	A public IDP key alias in the keystore. Useful when the IDP signing key is not publicly available in the metadata nor the messages but is known to the keystore.
`saml.idp.encryption-key`	Defines an alias of the public IDP key for encryption of outbound SAML messages	(blank, i.e. the metadata will be used)	A public key alias in the keystore Useful when the IDP encryption key is not publicly available in the metadata but is known to the keystore.
`saml.idp.trusted-keys`	Defines the keys considered as trust anchors for PKIX verification of inbound messages from the IDP	`all`	`all` (all keys in the keystore will be trusted), blank (equivalent to `all`), `none` (none of the keys in the keystore will be trusted), or a comma-separated list of keys (the keys must exist in the keystore).
`saml.idp.require-logout-request-signed`	Indicates that the IDP requires that any logout request initiated by the SP must be signed	`true`	`true` or `false`
`saml.idp.require-logout-response-signed`	Indicates that the IDP requires that any responses to IDP-initiated logout requests must be signed	`false`	`true` or `false`
`saml.idp.require-artifact-resolve-signed`	If enabled, requests sent to that IDP through the HTTP-Artifact profile will be signed	`true`	`true` or `false`
`saml.idp.allow-idp-initiated-sso`	Indicate that this IDP is permitted to initiate SSO	`true`	`true` or `false` Of course the SP will still be able to initiate SSO too.
`saml.idp.proxy-host`	Defines the hostname of the proxy	-	In case a proxy lies between Squash TM and the IDP and direct connection is required (e.g. HTTP-Artifact profile) Example: `localhost`
`saml.idp.proxy-port`	Defines the connection port of the proxy	`8080`	In case a proxy lies between Squash TM and the IDP and direct connection is required (e.g. HTTP-Artifact profile)
`saml.idp.basic-username`	Defines the username in case the IDP challenges Squash TM with basic authentication upon HTTP-Artifact resolution	-	-
`saml.idp.basic-password`	Defines the password for the above	-	-
	SP metadata options
`saml.sp.metadata.require-signature`	If enabled, Squash will require its SP metadata file itself to be signed	`false`	`true` or `false` Typical use is when the file is downloaded from a remote provider that does not serves https or you want to apply additional checks on the metadata anyway. SP MetadataProperties that are not signed will be rejected.
`saml.sp.metadata.check-signature`	If enabled and if the SP metadata are signed, will check the signature	`true`	`true` or `false` This involves checking the metadata digest and trust of the certificate. Has no effect if the metadata are not signed.
`saml.sp.metadata.check-certificate-revocation`	If enabled, in addition of checking the trust chain of the certificate, the system will check the expiration/revocation of certificate	`false`	`true` or `false` The exact infrastructure involved in this verification is beyond the scope of this configuration file and depends on the JCE provider and the configuration of the keystore, and would be driven by the corresponding system properties.
`saml.sp.metadata.trusted-keys`	Defines which keys should be considered as trust anchors for PKIX verification of the SP metadata file	`all`	`all` (all keys in the keystore will be trusted), blank (equivalent to `all`), `none` (none of the keys in the keystore will be trusted), or a comma-separated list of keys (the keys must exist in the keystore).
	SP metadata exposition
`saml.sp.metadata-exposition.signed`	If enabled, the SP metadata published by Squash TM at URL `/auth/saml/metadata` will be signed if not already	`false`	`true` or `false` This allows you to use your own trust verifications on Squash TM. In case the SP metadata are already signed, this option is ignored and the original signature will be preserved.
`saml.sp.metadata-exposition.signing-algorithm`	If the published metadata must be signed, indicates which signature algorithm will be used	The algorithm associated to the key resolved for property `saml.sp.signing-key`	Possible values are those listed in the XML-Security Reference. For example: `http://www.w3.org/2000/09/xmldsig#rsa-sha1`, `http://www.w3.org/2001/04/xmldsig-more#rsa-sha256`
`saml.sp.metadata-exposition.digest-algorithm`	If the published metadata must be signed, indicates which digest algorithm will be used.	`http://www.w3.org/2000/09/xmldsig#sha1`	Possible values are those listed in the XML-Security Reference. For example: `http://www.w3.org/2000/09/xmldsig#sha1`, `http://www.w3.org/2001/04/xmldsig-more#sha224`
	SP options
`saml.sp.signing-key`	Defines the alias of the private SP key for signing outbound SAML messages, in case that key is different from the default key	If blank, `saml.keystore.default-key` is used	A private key alias in the keystore
`saml.sp.encryption-key`	Defines the alias of the private SP key for decryption of inbound SAML messages, in case that key is different from the default key	If blank, `saml.keystore.default-key` is used	A private key alias in the keystore
`saml.sp.tls-key`	Defines the alias of the private SP key for client authentication in SSL/TLS scenario, primarily when Squash resolves a HTTP-Artifact binding	If blank, `saml.keystore.default-key` is used	A private key alias in the keystore
`saml.sp.require-logout-request-signed`	Indicates that Squash TM requires that any inbound logout request must be signed	`true`	`true` or `false`
`saml.sp.require-logout-response-signed`	Indicates that Squash TM requires that any response to Squash-initiated logout requests must be signed	`false`	`true` or `false`
`saml.sp.signature-security-profile`	States how the inbound messages signatures will be handled	`metaiop`	`metaiop` (skips the trust verification part and only checks the signature. Typically used when the metadata has been checked thoroughly earlier and deemed trustworthy) or `pkix` (complete verification)
`saml.sp.ssl-security-profile`	States how SSL/TLS connection certificates should be handled	`pkix`	`metaiop` (skips the trust verification part and only checks the signature. Typically used when the metadata has been checked thoroughly earlier and deemed trustworthy) or `pkix` (complete verification)
`saml.sp.ssl-hostname-verification`	In case Squash TM must call the IDP directly (e.g. for HTTP-Artifact profile) using https, indicates how Squash will verify the end point	`default`	`default`, `defaultAndLocalhost`, `strict`, or `allowAll`
	SP session options
`saml.session.max-assertion-time`	Defines the validity interval of an authentication assertion during the SSO process	`3000` (seconds)	If the process has not completed by that time the process has failed and SSO must be reinitiated from scratch. Note that the default value is large enough for most situations.
`saml.session.max-auth-time`	Defines the validity interval of an IDP authentication	`864000` (seconds, i.e. 10 days)	On expiration Squash TM will consider that the user must re-authenticate with the IDP.
	Reverse proxy / load balancer options
`saml.proxy.enabled`	Enables/disables reverse proxy support	`false`	`true` or `false`
`saml.proxy.server-name`	Declares the hostname of the reverse proxy	-	This must be defined if proxy support is enabled, since it has no default value.
`saml.proxy.scheme`	Declares the scheme used by the reverse proxy for outbound communications	`https`	`http` or `https`
`saml.proxy.server-port`	Declares the port used by the reverse proxy for outbound communications	`443`	A valid port number
`saml.proxy.context-path`	Declares the context path of the application as served by the reverse proxy	`/squash`	A context path, starting with a forward slash `/`
`saml.proxy.include-port-in-url`	Indicates whether the port number should be explicitly included in the request URL	`true`	`true` or `false`
	Assertion extra attributes		The assertion returned by the IDP may contain extra attributes about the user account that you may wish to use in Squash TM. The following properties allows you to map some of those attributes to Squash TM user account. Their default value is null (no mapping defined for that attribute). This is different from a blank value, i.e. if you do not need them, keep them commented out.
`saml.user-mapping.alternate-username`	Defines an extra attribute value as the username in Squash TM (instead of the nominal NameID)	-	A property name
`saml.user-mapping.first-name`	Defines an extra attribute value as the first name of a user account in Squash TM	-	A property name
`saml.user-mapping.last-name`	Defines an extra attribute value as the last name of a user account in Squash TM	-	A property name
`saml.user-mapping.email`	Defines an extra attribute value as the email of a user account in Squash TM	-	A property name

OpenId Connect

See this page for more information.
<idp-name> should be replaced with the lowercase name of the IDP.

Parameter	Description	Default	Notes
	Main configuration
`oidc.access.whitelist`	Restricts access based on user's email domain	-	A comma separated list of domains By default, access to Squash TM and restriction of users is to be configured directly in the IDP. This property handles restriction of access on Squash TM's side in case the IDP does not offer that possibility. It verifies that the connecting user's e-mail domain matches one or more of the domain values indicated via this property. If this property is left blank, no restrictions will be applied. For example: `@company-name.com,@domain.fr`
`preferred-auth-url`	Sets the main entry point for unauthenticated user requests	`/login` (i.e. login page for form-based basic authentication)	This property handles Squash TM's behavior in terms of unauthenticated user requests. It defines the URL to which the user will be redirected for login, in other words, it sets the main entry point. If the set value matches the pattern `/oidc/authorization/<idp-name>` , the login will be redirected to the specified IDP's login page or logged in directly if they are already connected to their IDP. Note: this is a generic Squash TM property and is not exclusive to OpenId Connect.
	IDP provider options		The options below allow you to declare a new custom IDP to use with Squash. For some providers (Google, Facebook, GitHub, Okta…), some of these properties are pre-configured and can be omitted. The OpenID Connect configuration values for an IDP are often accessible from the provider's well-known Configuration Endpoint: `<issuer-uri>/.well-known/openid-configuration`
`spring.security.oauth2.client.provider.<idp-name>.user-name-attribute`	Specifies which attribute to use as username in Squash TM	-	-
`spring.security.oauth2.client.provider.<idp-name>.issuer-uri`	Specifies the issuer identifier URL	-	-
`spring.security.oauth2.client.provider.<idp-name>.authorization-uri`	Specifies the IDP endpoint to start the authorization request	-	-
`spring.security.oauth2.client.provider.<idp-name>.token-uri`	Specifies the endpoint for retrieving access tokens	-	-
`spring.security.oauth2.client.provider.<idp-name>.user-info-uri`	Specifies the endpoint for retrieving user data	-	-
`spring.security.oauth2.client.provider.<idp-name>.jwk-set-uri`	Specifies the URI to retrieve the Auth provider's public key	-	This is used to verify JWT tokens
	IDP client options
`spring.security.oauth2.client.registration.<idp-name>.client-id`	Specifies the OAuth2 client identifier	-	Provided by the IDP when registering your Squash TM instance.
`spring.security.oauth2.client.registration.<idp-name>.client-secret`	Specifies the OAuth2 client secret	-	Provided by the IDP when registering your Squash TM instance.
`spring.security.oauth2.client.registration.<idp-name>.authorization-grant-type`	Specifies the OAuth2 grant type	-	Squash TM supports `authorization_code`.
`spring.security.oauth2.client.registration.<idp-name>.redirect-uri`	Specifies the URL to which the authentication response will be sent	-	Must match the `/oidc/code/*`pattern This is the redirect URI configured in the IDP.
`spring.security.oauth2.client.registration.<idp-name>.scope`	Defines the information the IDP will provide about the user	-	The available scopes can vary from one IDP to another. OpenId Connect requires the `openid` scope, but additional scopes can be specified.
`spring.security.oauth2.client.registration.<idp-name>.client-name`	Specifies the name of the IDP client	-	-