Skip to main content

​
Protocole utilisé

Serenest utilise SAML 2.0 (Security Assertion Markup Language) comme standard pour la gestion des intégrations SSO entre les fournisseurs d’identité tiers (IdP) et Serenest (fournisseur de service / SP). L’objectif est de permettre aux utilisateurs connectés à un système tiers (ex. une application d’entreprise) d’accéder aux Webviews Serenest sans avoir à se reconnecter manuellement.

​
Flux SAML détaillé

Flux SAML complet
1

Clic utilisateur

L’utilisateur clique sur un bouton dans l’application tierce pour accéder à Serenest.
2

Requête au backend

L’application tierce ouvre un navigateur interne et envoie une requête à son propre backend avec le token d’authentification de l’utilisateur et l’URL de destination souhaitée (paramètre url).
3

Génération de la réponse SAML

Le backend tiers génère une réponse SAML, l’encode en base64 et effectue une requête POST vers l’URL ACS de Serenest.
4

Vérification par Serenest

Serenest décode et vérifie la signature SAML (via le certificat .crt fourni).
5

Extraction et token

Serenest extrait les données utilisateur et génère un token d’accès interne.
6

Connexion automatique

Ce token est envoyé à l’application tierce, qui connecte automatiquement l’utilisateur.

​
URLs ACS

​
Structure de la SAMLResponse

Le payload de la SAMLResponse doit contenir les champs suivants : Format attendu : POST form-data avec un seul champ nommé SAMLResponse contenant le XML encodé en Base64.

​
Certificats et sécurité

Le tiers doit fournir à Serenest :
  • Un certificat X.509 (.crt)
  • Une clé publique (.pub)
Ces fichiers sont utilisés pour :
  • Authentifier la source de la requête SAML
  • Valider la signature de la réponse
  • Optionnellement générer un fichier de métadonnées IdP

​
Flux de test

1

Partage du certificat

Le tiers partage son certificat .crt avec l’équipe Serenest.
2

Configuration de l'IdP

Serenest configure l’IdP dans son backend.
3

Échange de comptes de test

Un compte de test est échangé entre les deux parties.
4

Intégration du bouton SSO

Un bouton d’accès SSO est intégré dans l’application tierce.
5

Tests en pré-production

La réponse SAML est testée en environnement de pré-production.
6

Mise en production

Une fois validée, la configuration est répliquée en production.

​
Bonnes pratiques et recommandations

Ne pas créer automatiquement un compte dans Serenest si l’utilisateur n’existe pas (conformité RGPD).
  • Vérifier la période de validité de la réponse SAML (via NotOnOrAfter).
  • En cas d’erreur, fournir des logs incluant :
    • L’horodatage de la requête
    • L’ID de la réponse SAML
    • L’adresse email de l’utilisateur