SAML

Présentation

Le plugin SAML ajoute un nouveau point d'entrée pour l'authentification sur Squash TM. Il s'accompagne de nombreux avantages, tels qu'un service d'authentification sécurisé et centralisé, et un service SSO. Ce plugin ne remplace pas le point d'entrée par défaut qu'est le formulaire de connexion. Les utilisateurs et administrateurs peuvent continuer d'utiliser cette interface pour s'authentifier en local s'ils le souhaitent (cette fonctionnalité peut être désactivée).

Squash TM supporte SAML 2.0.

Fonctionnalités

Les fonctionnalités prises en charge sont les suivantes :

• SSO Web ;
• SSO initié par SP ou IdP ;
• Profils HTTP-POST, HTTP Redirect ;
• Vérification de confiance à l'aide de Metadata Interoperability ou ICP (PKIX) ;
• Prise en charge du scoping et des contextes d'authentification ;
• Génération de métadonnées SP ;
• Publication de métadonnées SP.

Points de Terminaison

Le plugin SAML ajoute des points de terminaison (endpoints) :

• /auth/saml/login/{registration-id} : point d'entrée SAML pour l'authentification de l'utilisateur ;
• /auth/saml/sso/{registration-id} : point de terminaison pour les profils SSO, également connus sous le nom de service ACS (Assertion Consumer Service) ;
• /auth/saml/metadata/{registration-id} : l'URI des métadonnées ;
• /auth/saml/SingleLogout : URL de déconnexion simple.

Pour rappel, le chemin de contexte de l'application est toujours requis. Par exemple, pour le déploiement final de Squash TM, l'URL serait semblable à : http://someserver:8080/squash/auth/saml/login/google.

Limites

Le plugin SAML ne prend en charge les métadonnées que pour un seul fournisseur d'identité (IdP) et un seul SP. Pour cette raison, il n'y a pas de services de découverte d'IdP : les utilisateurs sont redirigés vers le seul IdP connu.

Intégrer Squash et le plugin SAML à son environnement

Le schéma ci-dessous illustre les acteurs et les ressources impliquées dans les interactions SAML.

Utilisateurs : Les utilisateurs veulent avoir accès aux ressources détenues par le Fournisseur de service, après avoir réussi à s'authentifier auprès du Fournisseur d'identité.

Fournisseur d'identité : Le fournisseur d'identité (ou IdP, de l'anglais Identity Provider) détient l'annuaire des utilisateurs. C'est lui qui se charge de l'authentification des utilisateurs, et, si elle est réussie, de fournir des certificats d'authentification s'il s'agit d'un scénario SSO. Les services SAML pris en charge par l'IdP sont listés et publiés dans un fichier intitulé Métadonnées IdP qui définit quelles données seront échangées et comment elles le seront.

Fournisseur de service : Le fournisseur de services (SP, de l'anglais Service Provider) est le serveur avec lequel l'utilisateur souhaite interagir. Dans notre cas, il s'agit de Squash TM. Ce fournisseur délègue les problèmes d'authentification à l'IdP, mais c'est lui qui détient les autorisations. Comme l'IdP, il publie les fonctionnalités SAML qu'il prend en charge dans des métadonnées SP.

SP/IdP Metadata : Ces fichiers publient les fonctionnalités prises en charge par le serveur qu'elles décrivent. Ils comportent les listes de point de terminaisons, de type de lien SSO préférés (HTTP-POST, redirect, etc.), d'informations attendues sur les utilisateurs (et sous quel format), de certificats utilisés pour le chiffrement, et de signatures.

À son lancement, Squash construit le fichier de métadonnées du SP à partir des propriétés du fichier de configuration et accède aux métadonnées du SP et de l'IdP. Les métadonnées SP sont accessibles via l'URL /auth/saml/metadata/{registration-id} où le registration-id est la valeur entrée dans le fichier de configuration. Les métadonnées de l'IdP peuvent être récupérées soit localement, soit à distance via une connexion HTTP(S). Dans l'exemple, les métadonnées IdP sont téléchargeables directement depuis l'IdP.

L'étape suivante est la validation des métadonnées, qui inclut une validation syntaxique et une vérification de la signature des métadonnées. Les certificats peuvent éventuellement être vérifiés, notamment au niveau de leur chaîne de confiance et de leur révocation (ou il est possible de simplement assumer leur validité si la source est de confiance).

Lorsque toutes les vérifications ont été effectuées, Squash signe ces métadonnées et les publie pour qu'elles puissent être utilisées par des outils tiers. C'est alors qu'il est possible de configurer l'IdP et déclarer l'instance Squash TM comme une source de demandes d'authentification valide, et lui fournir les métadonnées SP si nécessaire.

À ce stade, le plugin est opérationnel. Squash TM interagit avec l'IdP directement ou indirectement (via le navigateur Internet de l'utilisateur), selon le profil de liens SSO choisi. Squash TM peut également être configuré pour fonctionner avec des serveurs mandataires (proxy) si l'un d'entre eux se trouve entre deux serveurs et qu'une communication directe est requise (non-illustré).

Utilisation

Par défaut, les utilisateurs peuvent s'authentifier sur Squash TM en utilisant soit l'interface avec le formulaire d'authentification (/login), soit l'interface SAML SSO (/auth/saml/login/{registration-id}). Chaque interface peut être sélectionnée en tant qu'interface principale. Par défaut, les utilisateurs seront automatiquement redirigés vers cette interface. Si un utilisateur souhaite s'authentifier en utilisant l'autre interface, il peut le faire en accédant directement à son URL.

Une fois que l'utilisateur a réussi à s'identifier via SAML, le contexte utilisateur est créé. Le NameID sera le même que l'identifiant de connexion utilisé et transmis lors de l'authentification (l'identifiant est défini dans les métadonnées). Le compte utilisateur correspondant y sera alors lié, sans quoi l'utilisateur sera authentifié mais ne pourra accéder à aucun projet sur Squash TM.

Un utilisateur s'étant authentifié sur Squash TM via SAML peut changer son mot de passe local sur sa page de Préférences de compte. Par ailleurs, un administrateur peut lui définir un mot de passe via la page d'administration des utilisateurs. Un utilisateur s'étant authentifié via le formulaire de connexion peut changer son mot de passe normalement. En revanche, un utilisateur ne peut pas changer son mot de passe SAML via Squash TM.

Il est possible de n'autoriser l'authentification que via l'interface SAML SSO, voir Sources d'authentification.
Dans ce cas, les utilisateurs ne peuvent pas s'authentifier avec leur compte local et ils ne peuvent pas, ou un administrateur, changer ou définir leur mot de passe local.
S'ils accèdent à la page /login, ils sont redirigés vers l'interface SAML SSO (/auth/saml/login/{registration-id}).

Configuration

Cette partie détaille les étapes de configuration nécessaires à l'installation du plugin SAML. Ici seront abordées les principales actions à réaliser, ainsi que les options pouvant être choisies. La partie sur la configuration avancée est abordée dans la prochaine partie.

Les étapes nécessaires à l'installation du plugin sont les suivantes :

• déploiement du binaire ;
• configuration de l'application ;

Déploiement du binaire

À partir du dossier $SQUASH_HOME/plugin-files/saml/, copier le fichier .jar et coller le dans le dossier du même nom dans votre application Squash TM $SQUASH_HOME/plugins/.

Métadonnées du fournisseur de service

Le plugin SAML génère des métadonnées SP à partir des propriétés de configuration. Pour ce faire, il est nécessaire de fournir une clé privée au format PKCS8 et le certificat X.509. Ces deux éléments sont nécessaires pour signer les métadonnées SP et pour le chiffrement des messages SAML.

Créer une clé privée pour Squash TM

La commande suivante permet de générer une clé privée au format PKCS8 :

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private_key.pem

Exporter un certificat

Ensuite, la commande suivante permet d'exporter la clé privée sous forme de certificat valable un an (ajuster la durée si nécessaire) :

openssl req -x509 -new -key private_key.pem -sha256 -days 365 -out squashtm.cer

Ce certificat est requis pour générer les métadonnées du fournisseur de services (SP). Il inclut la clé publique et est partagé avec le fournisseur d'identité (IdP) afin de vérifier les signatures des requêtes et de chiffrer les assertions.

Configuration

Utilisation d'un fichier dédié

Le plugin SAML propose de nombreuses propriétés de configuration et le fichier de configuration est plutôt lourd, surtout par rapport aux autres plugins de Squash TM. Il est possible de configurer le plugin en utilisant son propre fichier de configuration dédié, ou bien y faire référence dans le fichier de configuration principal plutôt que d'y intégrer le contenu comme cela était requis pour les anciens plugins.

Pour cela, copier le fichier config/squash.tm.cfg-saml.properties et le coller dans le répertoire de configuration home. Dans la distribution de Squash TM en tant qu'application autonome, ce répertoire est en général SQUASH_HOME/conf. Puis, éditer le fichier de configuration principal SQUASH_HOME/conf/squash.tm.cfg.properties et lui associer le fichier de configuration du plugin en lui ajoutant/éditant la propriété suivante :

spring.profiles.include=saml

Si cette propriété était déjà présente, il est possible d'ajouter saml à la liste, séparé par une virgule.

(Alternative) Intégration des propriétés

Si cela est plus pratique, il est également possible de simplement copier et coller le contenu du fichier de configuration du plugin dans le fichier de configuration principal, sans avoir besoin d'ajouter SAML à la liste des profils.

Configuration minimale

Le fichier de configuration propose de nombreuses propriétés, mais seulement certaines d'entre elles sont obligatoires. Squash TM ne démarrera pas ou ne fonctionnera pas correctement si ces propriétés sont laissées vides ou ne sont pas renseignées correctement.

Les propriétés listées ci-dessous sont requises. Les détails (valeurs autorisées, etc.) sont disponibles dans les commentaires du fichier squash.tm.cfg-saml.properties, et plus loin dans cette même documentation.

saml.enabled : Interrupteur principal. Cette propriété permet d'activer ou de désactiver le plugin sans commentaire et sans avoir à supprimer le fichier jar.

saml.idp.metadata-url : L'emplacement des métadonnées du fournisseur d'identité (IdP). Les protocoles file://, http:// et https:// sont autorisés. Par exemple, file:///opt/squash-tm/conf/saml/FederationMetadata.xml ou https://login.microsoftonline.com/entreprise.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml.

saml.sp.registration-id : Identifiant unique utilisé pour enregistrer votre fournisseur de services (SP) dans la configuration SAML du plugin. Par exemple : google.

saml.sp.entity-id : Identifiant unique de l'instance Squash. Cette valeur doit être unique au sein de votre écosystème d'authentification et sera communiquée au fournisseur d'identité (IdP). Par exemple : urn:squash-tm:saml ou https://squash-tm.votre-entreprise.com/saml.

saml.sp.metadata.private-key : Clé privée au format PKCS8 utilisée par le fournisseur de services (SP) pour signer les requêtes et déchiffrer les messages.

saml.sp.metadata.certificate : Certificat X.509 du fournisseur de services (SP) utilisé pour la validation des signatures et le chiffrement.

Sources d'authentification

Par défaut, les utilisateurs peuvent s'authentifier soit avec leur compte local, soit avec leur compte SAML SSO.

Il est possible d'autoriser uniquement l'authentification avec le compte SAML SSO, grâce à la propriété suivante :

authentication.provider=saml

Configuration avancée

Le chapitre précédent présentait les préoccupations générales en ce qui concerne la configuration de Squash-SAML. Dans la plupart des cas, cette configuration devrait bien s'intégrer à l'environnement de travail. Cependant, le plugin propose plusieurs options pour une personnalisation plus poussée comme par exemple des exigences avancées pour le chiffrement RSA, ou encore pour prendre en compte l'organisation de votre réseau. Ce chapitre traite de ces options supplémentaires et revient sur quelques éléments présentés dans le chapitre précédent.

Conventions

Format des chemins de fichiers

Les métadonnées peuvent être récupérées à la lecture en tant que fichiers locaux ou à distance via des appels HTTP(S) en utilisant la propriété saml.idp.metadata-url.

Via HTTP(S) : le chemin du fichier est l'URL à partir de laquelle il peut être téléchargé. Le protocole est soit http://, soit https://. Exemple : https://votre.idp/metadonnees.xml

Via un chemin absolu : URL menant à un fichier local qui fonctionne bien en tant que chemin absolu. Dans ce cas, le protocole est file://. Exemple : file:///dev/squashtm/saml/idp.xml (sous Linux), file://C:/dossierappli/squashtm/conf/idp.xml (sous Windows).

Via un chemin relatif vers le dossier de configuration : Tout chemin qui n'a pas de protocole défini sera considéré comme étant un chemin relatif vers le dossier de configuration. L'emplacement du dossier de configuration peut varier selon l'environnement et le mode d'installation choisi pour Squash TM. Exemple : saml/idp.xml devient $CONF_DIR/saml/idp.xml.

Propriété Espaces de noms

Les propriétés sont regroupées par des espaces de noms en relation avec les acteurs (par exemple l'IdP) ou les ressources (métadonnées). Elles sont listées sans l'espace de nom par souci de concision, et avec l'espace de nom au-dessus de la table correspondante. Ce format est pratique dans un contexte de documentation. Cependant, lors de la modification du fichier de configuration, il sera nécessaire de déclarer le nom complet de la propriété.

Point d'entrée principal

Comme dit précédemment dans le chapitre Utilisation, les utilisateurs peuvent choisir de s'identifier en utilisant l'un des deux systèmes d'authentification (page habituelle du formulaire d'authentification ou point d'entrée SAML). Cependant, l'un de ces deux systèmes est défini comme étant le point d'entrée principal, et si l'utilisateur n'exprime aucune préférence pour l'un des deux systèmes, il sera redirigé vers ce point d'entrée principal lors de l'authentification.

Par défaut, Squash TM instaure la page de formulaire en tant que point d'entrée principal. Ceci peut être modifié dans la configuration.

Options

Espace de nom : squash.security

Propriété

Commentaire

preferred-auth-url

Cette propriété guide le comportement de Squash TM en matière de requêtes d'utilisateurs non-identifiés. Elle définit l'URL vers laquelle ce type d'utilisateurs doit être redirigé, c.-à-d. le point d'entrée principal. Si cette propriété est définie par /auth/saml/login/{registration-id}, le point d'entrée principal sera SAML. Il faut noter que cette propriété appartient à Squash TM et n'est pas spécifique au plugin SAML. Si vous utilisez d'autres plugins d'authentification, il faut vérifier leurs configurations respectives afin d'éviter tout conflit en lien avec ce sujet. Valeur par défaut : /login (page du formulaire d'authentification par défaut).

Traitement des métadonnées

Les métadonnées de Squash TM (en tant que fournisseur de service) sont générées au démarrage de l'application et accessibles via l'URL /auth/saml/metadata/{registration-id}. Celles du fournisseur d'identité peuvent être récupérées localement ou à distance (voir la partie ci-dessus).
Du fait de la nature sensible de ces fichiers, leur contenu doit être contrôlé de près. Il existe deux manières d'effectuer ce contrôle :

• soit les métadonnées sont signées, et la signature vérifiée ;
• soit la source des métadonnées est de confiance et vérifiée par d'autres mécanismes (elles proviennent d'un serveur HTTPS ou d'un dossier très privé).

Options des métadonnées SP

Espace de nom : saml.sp.metadata

Propriété	Commentaire
name-id-format	Définit le format du NameID utilisé pour identifier l'utilisateur dans la requête d'authentification SAML. Exemples : - urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress - urn:oasis:names:tc:SAML:2.0:nameid-format:transient Valeur par défaut : vide
authn-requests-signed	Indique si les requêtes d'authentification SAML envoyées par le SP doivent être signées. Valeur par défaut : false
single-logout-service-binding	Définit le type de binding (protocole de transport) utilisé par le SP pour communiquer avec le Single Logout Service de l'IdP. Exemples : - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect Valeur par défaut : urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

Exposition des métadonnées du Fournisseur de service

Squash TM expose les métadonnées SP à l'URL /auth/saml/metadata/{registration-id} et les signe si vous le souhaitez, sauf si elles étaient déjà signées (les métadonnées ne peuvent être pas signées plus d'une fois).

SSO

Les options listées ici sont en relation avec le processus SSO en lui-même. Il est possible de modifier les éléments et les conditions des échanges de messages. Si les métadonnées SP ont plusieurs alternatives pour une même clause (telle que <NameIDFormat/>), il est également possible d'indiquer au plugin quelle valeur devrait être utilisée pour cette clause au lieu de la valeur par défaut.

Dans certains cas, la valeur property doit être choisie parmi les spécifications SAML. Voici quelques liens utiles :

• Bindings ;
• Name ID, Scoping ;
• Authentication contexts.

Options standard

Espace de nom : saml.sso

Propriété	Commentaire
force-authN	Si cette option est activée, l'utilisateur devra se réauthentifier auprès de l'IdP à chaque fois qu'il s'authentifie sur Squash TM. Cela garantit que l'assertion d'authentification de l'utilisateur est bien à jour. Toutefois, cela peut devenir pénible si le processus d'authentification auprès de l'IdP implique une interaction humaine et cela désactiverait effectivement le mécanisme SSO. Valeur par défaut : false
provider-name	Le nom lisible par un humain qui sera inclus dans les messages envoyés à l'IdP. Utile à des fins d'historique Valeur par défaut : vide
binding	Le type lien que Squash TM utilisera pour initier le SSO avec l'IdP. Ce type de lien doit être présent dans les métadonnées de l'IdP. Exemples : - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect En pratique, il vous faudra extraire la valeur souhaitée des métadonnées de l'IdP. Valeur par défaut : la première méthode de binding listée dans la clause <SingleSignonService> des métadonnées de l'IdP.
assertion-consumer-index	Demande à l'IdP d'envoyer ses réponses au service consommateurs donné. La liste des services consommateurs disponibles peut être retrouvée dans les clauses <AssertionConsumerService> des métadonnées SP. L'ordre des services consommateurs est listé avec l'attribut index au sein du libellé. Valeur par défaut : si laissée vide, la valeur par défaut sera utilisée (avec l'attribut isDefault, ou avec index=0).
nameID	Le NameID qui doit être renvoyé par l'IdP, et celui qui sera utilisé pour représenter le nom principal de l'utilisateur (son identifiant). Exemples : - urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress - urn:oasis:names:tc:SAML:2.0:nameid-format:transient Valeur par défaut : l'IdP choisira parmi celles spécifiées dans sa copie des métadonnées SP.
allow-create	Notifie l'IdP que la création d'un nouvel utilisateur est permise lorsque celui-ci est inconnu. Notez qu'il s'agit ici de la création d'un nouvel utilisateur sur l'IdP. Squash TM ne donne que son opinion sur les actions que devrait effectuer l'IdP ; la décision finale appartient à l'IdP. Dans tous les cas, lorsqu'un utilisateur parvient à s'identifier auprès de l'IdP, Squash TM lui crée un compte utilisateur si ce compte n'existe pas déjà, comme expliqué précédemment dans la partie Utilisation. La propriété ci-présente n'influe aucunement sur cette création. Valeur par défaut : false
passive	Si cette option est activée, Squash TM informera l'IdP qu'il ne considère pas que l'interaction utilisateur soit nécessaire à l'authentification, ce qui peut nuire à l'expérience utilisateur. Notez que l'IdP peut être en désaccord avec cette décision. Valeur par défaut : false
relay-state	Un token arbitraire qui sera échangé avec l'IdP. Cela fait partie des spécifications SAML, mais Squash n'en fait pas d'utilisation concrète. Cette propriété peut prendre toute valeur. Valeur par défaut : vide

Scoping

L'utilisation de l'élément Scoping permet d'avoir des échanges avancés avec le SSO. Par exemple, vous pouvez demander des garanties sur la qualité de l'authentification des utilisateurs du côté de l'IdP (en spécifiant le contexte d'authentification) ou encore restreindre les IdPs de confiance au sein d'une architecture IdP multiniveaux.

Les propriétés suivantes seront prises en compte seulement si le scoping est activé.

Espace de nom : saml.sso (identique à celui des options standard)

Propriété	Commentaire
include-scoping	L'interrupteur principal pour le scoping. Si la valeur est false, les autres options listées ci-dessous seront désactivées. Valeur par défaut : false
allowed-idps	Cette propriété configure la clause <IdPList>. Au sein d'une architecture IdP multiniveaux, cette liste définit les IdPs autorisés à traiter les demandes d'authentification. La valeur est une liste d'entityIDs IdP séparés par des virgules. Valeur par défaut : vide (aucune restriction)
proxy-count	Le nombre maximum de proxys autorisés pour les messages d'authentification. Dans ce contexte, un proxy est égal à un IdP au sein d'une architecture IdP multiniveaux. Une valeur égale à 0 entraîne une interdiction de l'utilisation de proxys. L'IdP qui reçoit la demande d'authentification ne peut pas la déléguer ; c'est lui qui doit identifier l'utilisateur. Valeur par défaut : 2
authn-contexts	Une liste des contextes où l'authentification de l'utilisateur doit être prise en charge par l'IdP ; les contextes sont séparés par des virgules. Cette propriété est utile lorsque la méthode d'authentification standard n'est pas considérée comme étant suffisamment sécurisée et que Squash TM demande les garanties d'un processus plus rigoureux. Exemples : - urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI - urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract Valeur par défaut : vide (aucune restriction)
authn-context-comparison	Les exigences supplémentaires en ce qui concerne le traitement des identifiants fournis par l'utilisateur lors de l'authentification auprès de l'IdP. Les valeurs autorisées sont : exact, minimum, maximum, better. Valeur par défaut : exact.

Expiration de l'authentification

Régulièrement, Squash TM invalidera unilatéralement une assertion d'authentification lorsqu'elle aura dépassé la durée de validité entrée dans sa configuration (tout comme le Fournisseur d'identité peut lui-même établir une date d'expiration pour ses propres assertions d'authentification). Dans ce cas, l'utilisateur devra donc s'authentifier à nouveau auprès du Fournisseur d'identité. Cette expiration peut entraîner une perte de travail si le serveur n'a pas été en mesure de sauvegarder le travail non sauvegardé. Pour cette raison, nous encourageons les utilisateurs à se réauthentifier par eux-mêmes auprès du Fournisseur d'identité lorsqu'ils le souhaitent.

Focus

L'utilisateur doit impérativement se réauthentifier auprès du Fournisseur d'Identité même lorsque sa session sur l'IdP est toujours valide car Squash rejettera l'authentification si la même assertion est présentée.

Options

Espace de nom : saml.session

Propriété	Commentaire
max-auth-time	Définit en secondes la durée de vie d'une assertion d'authentification avant que l'utilisateur doive se réauthentifier auprès du fournisseur d'identité (IdP) . Valeur par défaut : 864000 (dix jours)
max-assertion-time	Définit en secondes la durée de validité d'une assertion d'authentification pendant le déroulement du protocole SSO. La procédure de SSO doit être achevée avant ce délai. Valeur par défaut : 3000
clock-skew	Définit en secondes la tolérance maximale acceptée pour les décalages d'horloge entre le fournisseur de services (SP) et le fournisseur d'identité (IdP). Valeur par défaut : 300

Proxy

Si Squash TM est déployé derrière un mandataire inverse (reverse proxy) ou un équilibreur de charge, les modifications appliquées à vos URLs et projets peuvent conduire à des différences entre la requête actuelle et la requête attendue. Vous pouvez déclarer ce proxy dans la configuration pour indiquer à Squash TM comment effectuer ces remaniements lors des échanges avec le Fournisseur d'identité (IdP).

Options

Espace de nom : saml.proxy

Propriété	Commentaire
enabled	L'interrupteur principal qui active le mandataire (proxy) et les options ci-dessous. Valeur par défaut : false
server-name	Le nom d'hôte du mandataire inverse. Cette propriété n'a pas de valeur par défaut et doit être fournie. Valeur par défaut : vide
scheme	Le protocole utilisé par le mandataire inverse (reverse-proxy) pour les communications sortantes. Valeur par défaut : https
server-port	Le port utilisé par le mandataire inverse pour les communications sortantes. Valeur par défaut : 443
context-path	Le chemin de contexte de l'application, tel que servi par le mandataire inverse (reverse proxy). Valeur par défaut : /squash
include-port-in-url	Cette propriété indique si le numéro de port doit être explicitement inclus dans l'URL de requête (même lorsqu'un port par défaut est utilisé et qu'il pourrait donc être ommis). Valeur par défaut : true

Informations Compte utilisateur

Selon la configuration du serveur IdP, les assertions en réponse aux demandes d'authentification peuvent contenir des informations supplémentaires sur le compte utilisateur. Dans le document de l'assertion, ces attributs supplémentaires sont listés sous le libellé <AttributeStatement>. Les propriétés listées ci-dessous autorisent Squash TM à utiliser ces attributs.

Veuillez noter que Squash TM ne demandera pas ces attributs via une clause Requested Attributes (voir Protocole SAML - Extension pour la demande d'attributs par requête) car cette fonctionnalité n'est pas toujours supportée et dépend de l'IdP. Au lieu de cela, vous devez vous assurer que l'IdP ajoute ces attributs à l'assertion dans tous les cas.

Options

Espace de nom : saml.user-mapping

Propriété	Commentaire
alternate-username	Utilise la valeur de cet attribut en tant que nom d'utilisateur dans Squash TM au lieu du nameID nominal. Cela vous permet de travailler autour des limites de l'IdP si ce dernier ne peut pas vous fournir le nameIDFormat dont vous avez besoin (par ex. : d'anciennes versions d'Azure). Valeur par défaut : aucune (fonctionnalité désactivée)
first-name	Désigne l'une des valeurs d'un attribut supplémentaire en tant que prénom d'un compte utilisateur dans Squash TM. Cette fonctionnalité est seulement utilisée lorsqu'un compte utilisateur est sur le point d'être créé dans Squash TM : les comptes utilisateurs déjà existants ne seront pas mis à jour de cette façon. Valeur par défaut : aucune
last-name	Désigne l'une des valeurs d'un attribut supplémentaire en tant que nom de famille d'un compte utilisateur dans Squash TM. Cette fonctionnalité est seulement utilisée lorsqu'un compte utilisateur est sur le point d'être créé dans Squash TM : les comptes utilisateurs déjà existants ne seront pas mis à jour de cette façon. Valeur par défaut : aucune
email	Désigne l'une des valeurs d'un attribut supplémentaire en tant qu'adresse email d'un compte utilisateur dans Squash TM. Cette fonctionnalité est seulement utilisée lorsqu'un compte utilisateur est sur le point d'être créé dans Squash TM : les comptes utilisateurs déjà existants ne seront pas mis à jour de cette façon. Valeur par défaut : aucune

Historique

Si vous rencontrez des difficultés à utiliser SAML, vous pouvez activer une journalisation plus détaillé afin de savoir ce qui ne fonctionne pas. Pour cela, ajoutez les lignes suivantes à la configuration :

logging.level.org.squashtest.tm.plugin.saml=TRACE
logging.level.sqsaml.org.springframework.security=TRACE
logging.level.org.springframework.security.web.authentication=TRACE
logging.level.org.opensaml=TRACE

TRACE est le niveau d'historique le plus précis. Si vous trouvez cela trop verbeux, vous pouvez plutôt utiliser le niveau DEBUG.

Focus

Squash TM doit être redémarré afin de prendre en compte votre nouvelle configuration.