Skip to content

Squash TM Main Configuration

Startup file

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.

Locale

The locale is used for some error messages. It is defined in the \bin\startup file in the Java arguments (JAVA_TOOL_OPTIONS). To modify it, look for the following argument and indicate the desired language:

-Duser.language=en

If the system does not have a locale, it is possible to either:

  • define a system locale
  • add the following argument in JAVA_TOOL_OPTIONS with the desired region:
    -Duser.region=GB
    

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.

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}/.. -
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 -

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.
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) -

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

For the time being, these limits are considered only for the import of test cases.

Parameter Description Default Notes
squash.xls-imports.max-concurrent-imports Defines the maximum number of concurrent imports - since 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 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 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.

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 - -