Bienvenue

Jalios Community

Tout ce que vous souhaitez savoir sur l'écosystème Jalios

Module SAML - Documentation

  • Rédacteur :
  • Date de modification : 09/01/2024

Présentation, installation et configuration du Module d'authentification SAML , utilisant la norme SAML 2.0, destiné à s'interfacer avec toutes les solutions majeures de gestion d'identité du marché supportant le protocole SAMLv2 : ADFS, OIF, OpenAM, Shibboleth, ...

1. Glossaire

2. Pré-requis

  • Un accès administrateur à l'IdP
  • JPlatform 9 SP1 ou au delà

3. Démarrage rapide

Déployez le module SAML et redémarrez JPlatform
Saisissez l'Entity ID que vous souhaitez affecter à JPlatform dans l'interface d'édition des propriétés du module et enregistrez.

Configuration de l'IdP

  • Déclarez un nouveau Service Provider sur votre IdP à partir des métadonnées issue de JPlatform :
    (après saisie de l'Entity ID et des certificats coté JPlatform)
    • soit en utilisant le fichier WEB-INF/data/saml2/sp-metadata.xml généré automatiquement par JPlatform
    • soit en configurant l'URL d'accès aux metadonnées dans votre IdP :
      Exemple: https://jplatform.example.com/plugins/SAMLPlugin/saml2/metadata.jsp
  • Assurez-vous que l'IdP soit en mesure de répondre à une AuthnRequest demandant un NameID au format transient,
    ou modifiez le format de NameID depuis la configuration du module SAML
  • Configurez les attributs envoyés dans les réponses SAML pour inclure le login de l'utilisateur :
    l'attribut doit être en correspondance avec les login que vous utilisez pour les Membres dans JPlatform
    notez le type de l'attribut renvoyé

Configuration de JPlatform

  • Récupérez le fichier de metadata sur l'IdP
  • Placez ce fichier dans votre webapp JPlatform, WEB-INF/data/saml2/idp-metadata.xml
  • Ouvrez la page d'édition des propriétés du module (Espace d'administration > Gestions des modules > Module SAML)
    Renseignez le champ Nom de l'attribut (aka type de revendication) du login avec la valeur précédemment relevée lors de la configuration de l'IdP et enregistrez
    le message [SAMLManager] - SAML Plugin is enabled doit être visible dans les logs du serveur

Le module est désormais prêt à fonctionner.

Tests

Accédez au formulaire de connexion, un bouton Connexion avec SAML vous permet de tester l'authentification. En cas d'échec de connexion, les logs du serveurs vous indiqueront la raison de l'échec.

Dès que vous avez validé que l'authentification est fonctionnelle, vous pouvez modifier les réglages du module pour activer l'authentification SAML automatique afin que les utilisateurs n'aient pas à utiliser le bouton de connexion.

Suivez la documentation complète pour découvrir toutes les possibilités offertes par le module.

4. Principes

4.1 Configuration

  1. L'IdP est déclaré dans JPlatform grâce au fichier ou à l'URL des metadata de l'IdP
  2. JPlatform est configuré dans l'IdP grâce au fichier ou à l'URL des metadata généré par JPlatform
  3. L'IdP est configuré pour envoyer à JPlatform un attribut de login permettant d'identifier le membre

4.2 Fonctionnement

Le module SAML supporte 2 profiles de SSO définis dans la spécification SAML 2.0

  • Pour l'authentification : le Web Browser SSO Profile
    Le module suit les recommandations de la spécification d’interopérabilité SAML2int 0.2.1 
    Information : SAML2int n'est pas une spécification officielle OASIS (entité ayant ratifié SAML 2.0), il s'agit du mode de fonctionnement le plus communément utilisé et qui garantit une interopérabilité maximum avec tous les IdP
    En synthèse :
    • Envoi de la demande d'authentification (AuthnRequest) signée, en HTTP-Redirect binding, avec un NameID au format transient,
    • Réception de la réponse en HTTP-POST binding,
    • Support des assertions signées (obligatoires) et chiffrées (fortement recommandé notamment si HTTPS n'est pas utilisé),
    • Support des demandes d'authentification initiées par l'IdP.
  • Pour la déconnexion : le Single Logout Profile
    en utilisant le HTTP-POST binding
    • une déconnexion de l'IdP et des autres services initiée depuis JPlatform,
    • une déconnexion de JPlatform initiée par un autre SP,
    • une déconnexion de JPlatform initiée par l'IdP.

5. Configuration

Toutes les étapes ci-dessous sont requises pour une mise en œuvre du module en environnement de production.

5.1 JPlatform : Entity ID

Il est impératif de définir un nom globalement unique et stable qui identifie JPlatform en tant que Service Provider, c'est l'entity ID.
En général, l'entity ID est une URL absolue, mais il s'agit bien d'un nom, pas d'un emplacement. L'entity ID n'a pas besoin de pointer une ressource web existante.

Le module SAML utilise par défaut l'URL du site comme Entity ID.
Vous pouvez modifier ce réglage :

  • soit via l'interface d'édition des propriétés du module
  • soit directement dans custom.prop 
    jcmsplugin.saml.SPSSO.entityID: https://jcms.example.com/

5.2 JPlatform : Certificat de signature et de chiffrement

Des certificats sont nécessaires pour la signature et pour le chiffrement des messages échangés entre le SP et l'IdP.

Au premier démarrage de JPlatform avec le module, un keystore contenant une clé privé et un certificat auto-signé est généré pour la signature ET l'encryption :
Ce certificat est enregistré dans WEB-INF/data/saml2/default-keystore.jks

  • son mot de passe est "changeit", il peut être affiché comme ceci :
$ keytool -list -keystore default-keystore.jks -storepass changeit -keypass changeit
  • il est valable 10 ans et peut être utilisé pour une mise en place rapide

Cependant, la génération de certificats dédiés à la production (distinct pour la signature et le chiffrement) est préférable et doit se faire comme indiqué ci après :

  1. Générez le certificat avec keytool.exe
    • choisissez une durée de validité appropriée,
      pour l'usage de signature et de chiffrement dans SAML, un certificat valable longtemps est envisageable
    • utilisez un mot de passe identique pour le fichier et pour l'entrée
    • le nom de l'alias n'a pas d'importance
    • Exemple de génération d'un certificat auto-signé valable 10 ans 
      $ keytool.exe -genkey -keyalg RSA -alias "SAML Signing" -keystore signing.jks -validity 3650 -keysize 1024
   Entrez le mot de passe du fichier de clés :  changeit
   Ressaisissez le nouveau mot de passe : changeit
   Quels sont vos nom et prénom ?
     [Unknown]:  SAML Signing - jcms.example.com
   Quel est le nom de votre unité organisationnelle ?
     [Unknown]:
   Quel est le nom de votre entreprise ?
     [Unknown]:
   Quel est le nom de votre ville de résidence ?
     [Unknown]:
   Quel est le nom de votre état ou province ?
     [Unknown]:
   Quel est le code pays à deux lettres pour cette unité ?
     [Unknown]:
   Est-ce CN=SAML Signing - jcms.example.com, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown ?
     [non]:  oui

   Entrez le mot de passe de la clé pour <SAML Signing>
         (appuyez sur Entrée s'il s'agit du mot de passe du fichier de clés) :  changeit
   Ressaisissez le nouveau mot de passe : changeit
  2. Placez le certificat sur le filesystem de JPlatform, par exemple dans la webapp : WEB-INF/data/saml2/sp-signing-certificate.jks
  3. Référencez ce fichier et son mot de passe dans les propriétés :
    • soit via l'interface d'édition des propriétés du module
    • soit directement dans custom.prop (auquel cas un redémarrage est nécessaire) 
      jcmsplugin.saml.SPSSO.signing-certificate.path: WEB-INF/data/saml2/sp-signing-certificate.jks
jcmsplugin.saml.SPSSO.signing-certificate.password: changeit
  4. Puis recommencez la procédure pour générer et référencer le certificat utilisé pour le chiffrement : 
    jcmsplugin.saml.SPSSO.encryption-certificate.path: WEB-INF/data/saml2/sp-encryption-certificate.jks
jcmsplugin.saml.SPSSO.encryption-certificate.password: changeit

Notes :

  • Le module accepte 2 formats pour les fichiers de stockage :
    • keystore JKS (extension .jks)
    • PKCS12 (avec l'extension .pfx ou .p12)
      ce format a l'avantage d'être rapidement consultable sur environnement Windows
  • Le chemin peut être absolu, ou relatif à la racine de la webapp.

5.3 JPlatform : Enregistrement de l'IdP

L'enregistrement de l'IdP auprès de JPlatform s'effectue en indiquant les métadonnées de l'IdP à JPlatform.
Voici quelques exemples d'URL communes permettant de récupérer les métadonnées de l'IdP :

  • AD FS :
    https://adfs.example.local/FederationMetadata/2007-06/FederationMetadata.xml
  • Oracle Identity Federation
    http://oif.example.local/fed/idp/metadata
  • Shibboleth :
    https://shib.example.local/idp/profile/Metadata/SAML
  • OpenAM :
    https://openam.example.local/openam/saml2/jsp/exportmetadata.jsp?realm=MYREALM&entityid=https://idp.example.local/openam

Pour référencer ces métadonnées dans JPlatform, 2 possibilités : 

  • Option 1 à partir de l'URL :
    Si le serveur de l'IdP est accessible depuis le serveur JPlatform (en HTTP/HTTPS)
    • Saisissez l'URL d'accès aux métadonnées de l'IdP dans la configuration du module SAML de JPlatform
      • soit via l'interface d'édition des propriétés du module
      • soit directement dans custom.prop (auquel cas un redémarrage est nécessaire)
        jcmsplugin.saml.IDPSSO.metadata.path: https://idp.example.local/path/to/metadata
    Cette configuration est possible depuis l'évolution SAML-22 intégrée dans la version 2.2 du module SAML

  • Option 2 à partir du fichier de métadonnées :
    Si le serveur de l'IdP n'est pas accessible à JPlatform  : 
    • Récupérez le fichier de metadata de l'IdP en suivant la documentation de votre IdP.
    • Placez le fichier sur le filesystem de JPlatform.
    • Référencez le fichier dans les propriétés :
      Le chemin peut être absolu, ou relatif à la racine de la webapp.
      • soit via l'interface d'édition des propriétés du module
      • soit directement dans custom.prop (auquel cas un redémarrage est nécessaire) 
        jcmsplugin.saml.IDPSSO.metadata.path: WEB-INF/data/saml2/myidp-metadata.xml

5.4 IdP : Enregistrement de JPlatform en tant que Service Provider

Pour enregistrer JPlatform en tant que Service Provider sur votre IdP, vous devez récupérer le fichier de metadata de JPlatform.
Avant de procéder à cette étape, assurez-vous que la configuration de l'Entity ID et des certificats a été effectuée et prise en compte par JPlatform et le module SAML (soit par un redémarrage, soit par modification depuis l'interface d'édition des propriétés).

Le module SAML génère le fichier de metadonnées dans le chemin suivant de la webapp : WEB-INF/data/saml2/sp-metadata.xml.
Le fichier est régénéré à chaque démarrage ou chaque modification de configuration.

Le fichier est également accessible via une URL (publique par défaut, mais modifiable depuis le module)
https://jplatform.example.com/plugins/SAMLPlugin/saml2/metadata.jsp

Récupérez ce fichier et procédez à son ajout dans l'IdP, en suivant la documentation spécifique à votre IdP.

5.4.1 Exemple : Configuration de Microsoft AD FS

Pour Microsoft AD FS, vous pouvez suivre l'un des guides suivant :

  • AD FS : Ajout d'un site JPlatform
    Guide réalisé sur AD FS 2.1 (Windows Server 2012) , où la synchronisation des utilisateurs est effectué via le LDAP (Active Directory), avec une configuration de NameID transient.
  • AD FS 4.0 : Ajout d'un site JPlatform
    Guide réalisé sur AD FS 4.0 (Windows Server 2016) , où la synchronisation des utilisateurs peut être assurée soit via le LDAP (Active Directory) soit via SAML (AD FS), avec une configuration de NameID E-Mail Address

5.4.2 Exemple : Configuration de Microsoft Azure AD

Pour Microsoft Azure AD, vous pouvez suivre le guide suivant :

5.5 IdP et JPlatform : Configuration de l'attribut de login

Dans la configuration par défaut du module, la réponse d'authentification SAML envoyée par l'IdP doit contenir un attribut permettant à JPlatform d'identifier l'utilisateur dans la base des membres.

Il est important de configurer un attribut en correspondance avec la configuration des logins dans JPlatform.

Quelques exemples de mises en œuvre :

Il s'agit ici d'exemples, pas de recommandations. Les configurations possibles sont multiples ; il faut s'assurer de respecter les règles de votre IdP et leur cohérence avec les choix effectués dans JPlatform.

Pour procéder à la configuration :

  • Coté IdP : Consultez la documentation de votre IdP pour inclure l'attribut de votre choix dans la réponse, et définir son nom
  • Coté JPlatform : Configurez le Nom de l'attribut (aka type de revendication) du login à chercher dans la réponse
    • soit via l'interface d'édition des propriétés du module
    • soit directement dans custom.prop (auquel cas un redémarrage est nécessaire) 
      jcmsplugin.saml.authn-response.attribute-statement-mbr-mapping.login: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

6. Configurations avancées

6.1 Authentification manuelle ou automatique

Par défaut le comportement du module SAML est de ne PAS procéder à une authentification automatique des utilisateurs auprès de l'IdP.
Lorsque l'utilisateur arrive sur le formulaire d'authentification, un bouton Connexion avec SAML lui est proposé.

Il est possible de modifier la configuration du module pour permettre une redirection systématique des utilisateurs anonymes vers l'IdP, pour authentification.
Modifiez l'option Activer l'authentification SAML

  • soit via l'interface d'édition des propriétés du module
  • soit directement dans custom.prop (auquel cas un redémarrage est nécessaire) 
    jcmsplugin.saml.automatic-saml-auth: true

Notes :

  • Le bouton sera toujours visible dans les formulaires après une déconnexion de l'utilisateur
  • Si une règle d'accès est configurée (voir section suivante), l'authentification automatique ne sera PAS active pour les utilisateurs exclus par la règle d'accès, et le bouton ne leur sera pas proposé.

Quelle que soit la configuration, le bouton de connexion peut être personnalisé :

  • En surchargeant l'icône grâce à la propriété icon.jcmsplugin-saml: plugins/SAMLPlugin/docs/images/icon.gif
    à mettre dans le plugin.prop de votre module de site
  • En surchargeant le libellé grâce aux propriétés de traduction jcmsplugin.saml.authenticate-with-saml
    à mettre dans les fichiers de localisation (fr.prop, en.prop, ...) de votre module de site

6.2 Règles d'accès (aka AccessRules)

Comme tous les modules de SSO proposés par Jalios, le module SAML permet de définir une ou plusieurs règles d'accès qui permettent d'identifier deux populations :

  • les utilisateurs bénéficiant du SSO SAML
  • les autres, qui devront s'authentifier par des moyens classiques (formulaire de connexion par login / mot de passe, ou autres méthodes d'authentification disponibles sur le site).

Pour connaitre en détail le fonctionnement et la mise en place de règles d'accès, consultez l'article : Règles d'accès des modules de SSO (aka AccessRules)

Dans le module SAML, la configuration des règles d'accès s'effectue par propriété, avec le préfixe jcmsplugin.saml..

Voici un exemple (totalement fictif) pour proposer l'authentification SAML uniquement aux utilisateurs de Firefox sur le réseau local :

jcmsplugin.saml.access-rule.class: MetaAccessRule
jcmsplugin.saml.meta-access-rule.expression: (firefox && localnetwork) 
jcmsplugin.saml.meta-access-rule.firefox.class:  UserAgentAccessRule
jcmsplugin.saml.meta-access-rule.firefox.regex:  .*Firefox.*
jcmsplugin.saml.meta-access-rule.localnetwork.class:  IpAccessRule
jcmsplugin.saml.meta-access-rule.localnetwork.regex:  ^192\\.168\\.0\\..*

 

Il est également possible de changer l'objectif de la règle d'accès du module SAML en modifiant la propriété jcmsplugin.saml.access-rule.behavior :

  • Dans le mode userAuthorize(comportement par défaut) : la règle d'accès sert à déterminer si on peut proposer l'authentification SAML aux utilisateurs (que l'authentification soit automatique ou manuelle)
    -> utilisez ce mode pour permettre l'authentification SAML à une population (e.g: les utilisateurs connectés au réseau interne de l'enterprise), mais pas à d'autre (e.g : les utilisateurs en dehors du réseaux de l'enteprise)
  • Dans le mode userWithAutomaticConnexion : la règle d'accès déclenche l'authentification automatique pour les utilisateurs qui valide la règle, pour les autres utilisateur l'authentification reste possible depuis le formulaire de login
    (conséquence de ce mode, si le module est activé, l'authentification SAML est toujours disponible dans le formulaire de login)
    -> utilisez ce mode pour automatiser de façon systématique l'authentification SAML pour une population (e.g : les utilisateurs connectés au réseau interne), mais pour laisser le choix de l'authentification (login/pass ou SAML) aux autres

(Cette dernière possibilité de configuration est disponible depuis l'évolution SAML-27 intégrée dans les version 2.2 du module SAML)

6.3 NameIdPolicy et identifiant utilisateur

Le comportement par défaut du module SAML est

  1. d'envoyer à l'IdP une demande d'authentification (AuthnRequest) dont le format de NameID souhaité est de type transient.
  2. d'attendre dans la réponse d'authentification un attribut SAML spécifique contenant l'identifiant utilisateur
    (comme décrit section "IdP et JPlatform : Configuration de l'attribut de login" ci-dessus)

Il est cependant possible de modifier la configuration du module pour demander un format de NameID spécifique afin de lire l'identifiant utilisateur dans le NameID reçu en réponse. Pour cela

  1. pour la demande : configurer le format de NameID souhaité dans la propriété jcmsplugin.saml.websso-profile.nameid-format
  2. pour la réponse : configurer la propriété jcmsplugin.saml.authn-response.attribute-statement-mbr-mapping.login à une valeur vide pour utiliser le NameID reçu en réponse.

Cette configuration est possible depuis l'évolution SAML-19 intégrée dans les version 1.2 et 2.1 du module SAML

6.4 Durée de validité de l'authentification

Le comportement par défaut du module SAML est d'accepter les réponses d'authentification SAML si et seulement si l'authentification de l'utilisateur effectué par l'IdP date de moins de 2 heures (7200 secondes), avec une marge d'erreur de 60 secondes (en cas de différence d'horodatage entre l'IdP et le SP).

Ces options peuvent être modifiées via les propriétés suivantes (en secondes) : 

  • Durée de validité : jcmsplugin.saml.websso-profile.max-auth-age: 7200
  • Marge d'erreur : jcmsplugin.saml.websso-profile.time-margin: 60

Il est recommandée de paramétrer une durée d'expiration identique dans l'IdP et le SP (JPlatform).

Cette configuration est possible depuis l'évolution SAML-12 intégrée dans les version 1.2 et 2.0 du module SAML

6.5 Persistance de l'authentification SAML

Le comportement par défaut du module SAML est de conserver l'authentification SAML valide tant que le navigateur du client reste ouvert (en respectant les durée de validité de cookie configuré dans JPlatform).
Ainsi, dès que l'utilisateur ferme son navigateur, une authentification SAML auprès de l'IdP devra à nouveau être effectuée lors sa prochaine session de navigation.

En positionnant la propriété suivante, il est possible de persister l'authentification :
jcmsplugin.saml.auth.use-persistent-cookie: true

Dans tous les cas c'est la configuration des cookies d'authentification de JPlatform qui s'applique.
Voir à ce sujet : Quelle est la durée maximum des cookies de connexion ?

Cette configuration est possible depuis l'évolution SAML-28 intégrée dans les version 2.2 du module SAML

6.6 URL de base multiples

Le comportement par défaut du module SAML est d'utiliser l'unique URL de base du site dans les endpoint communiqués à l'IdP dans les métadonnées SAML.
La conséquence est que l'IdP redirige systématiquement l'utilisateur vers cette URL configurée dans les propriétés du site (propriété channel.url) 

Si votre site est accessible via plusieurs URLs (comme par exemple https://intranet.example.com/ et https://extranet.example.com/), il est possible de déclarer les autres URLs dans la propriété jcmsplugin.saml.SPSSO.additional-base-urls

Exemple :

channel.url: https://intranet.example.com/

jcmsplugin.saml.SPSSO.additional-base-urls: https://extranet.example.com/ https://other.example.com/

La modification de cette configuration nécessite le rechargement des propriétés du module ou le redémarrage du site, afin de provoquer la régénération des métadonnées SAML. Les nouvelles métadonnées doivent être relus par l'IdP pour prise en compte (rappel : les métadonnées sont accessibles via le fichier WEB-INF/data/saml2/sp-metadata.xmlou via l'URL/plugins/SAMLPlugin/saml2/metadata.jsp ).

Cette configuration est possible depuis l'évolution SAML-23 intégrée dans les version 2.2 du module SAML

6.7 Configurer la synchronisation des utilisateurs

Vous pouvez activez la synchronisation des utilisateurs à partir des informations issus de l'IdP.

Le principe est de configurer l'IdP pour envoyer les informations utilisateurs dans la réponse SAML, afin de permettre à JPlatform de créer et/ou mettre à jour les membres existants avec ces informations.

Pour cela

  • Configurer l'IdP pour inclure des attributs spécifiques dans les assertions SAML, contenant les informations de l'utilisateur.
    Consultez la documentation de votre IdP pour déterminer comment ajouter des attributs dans la réponse d'authentification.
  • Activez la synchronisation avec SAML dans le module SAML
    jcmsplugin.saml.sync-with-saml: true
  • Configurez le nom de l'attribut SAML à utiliser pour renseigner le login et le nom du Membre dans JPlatform
    • Login  : voir section "IdP et JPlatform : Configuration de l'attribut de login"  plus haut
    • Nom : propriété jcmsplugin.saml.mapping.name
  • [optionnel] Pour chaque information utilisateur, configurez le nom de l'attributs SAML que JPlatform doit utiliser pour récupérer la valeur à assigner au membre
    Description Propriété
    Nom jcmsplugin.saml.mapping.name
    Prénom jcmsplugin.saml.mapping.f-name
    Civilité jcmsplugin.saml.mapping.salut
    Organisation jcmsplugin.saml.mapping.organization
    Service jcmsplugin.saml.mapping.department
    Fonction jcmsplugin.saml.mapping.job
    E-mail jcmsplugin.saml.mapping.mail
    Téléphone jcmsplugin.saml.mapping.phone
    Mobile  jcmsplugin.saml.mapping.mobile
    Voie et numéro jcmsplugin.saml.mapping.street
    Code postal jcmsplugin.saml.mapping.postalCode
    Boîte postale  jcmsplugin.saml.mapping.postOfficeBox
    Ville jcmsplugin.saml.mapping.locality
    Département / Région jcmsplugin.saml.mapping.region
    Pays jcmsplugin.saml.mapping.country

    Langue  

    Option disponible depuis SAML-52, version 2.4.1 du module

    		 jcmsplugin.saml.mapping.language
    Coordonnées  jcmsplugin.saml.mapping.address
    Informations jcmsplugin.saml.mapping.info

    Responsable

    Option disponible depuis SAML-49, version 2.4 du module 

    		 jcmsplugin.saml.mapping.manager

    Assistant

    Option disponible depuis SAML-49, version 2.4 du module 

    		 jcmsplugin.saml.mapping.assistant

    Groupes

    Consultez la section suivante pour plus de détails sur la configuration de la synchronisation des groupes.

    		 jcmsplugin.saml.mapping.groups

Options avancées : 

Propriétés Valeur par défaut Description
jcmsplugin.saml.sync.create-new-account true

Active ou désactive la création automatique d'un nouveau Membre après l'authentification SAML, si aucun Membre n'a pu être trouvé pour les informations de connexion reçues.
jcmsplugin.saml.sync.update-existing-account true

Active ou désactive la mise à jour automatique des comptes existants à partir des informations SAML.
jcmsplugin.saml.sync.create-db-member false

Active la création de Membres DB (au lieu de Membre JStore par défaut)

 

Cette configuration est possible depuis l'évolution SAML-1 intégrée dans les version 2.2 du module SAML

6.8 Configurer la synchronisation des groupes

Si vous activez la synchronisation des utilisateurs à partir des informations issus de l'IdP, il est également possible de configurer la synchronisation pour inclure les groupes de l'utilisateur.
La synchronisation des groupes est désactivée par défaut.

2 approches peuvent être utilisées pour la synchronisation des groupes :

  1. L'IdP est configuré pour renvoyer le nom des groupes en attribut,
    JPlatform trouve et assigne le groupe correspondant à chaque nom reçu.
    • Avantage : c'est très simple et facilement compréhensible
    • Inconvénient : il y a un risque qu'un groupe de l'IdP est une correspondance de Groupe dans JPlatform qui attribut plus de droit que nécéssaire

  2. L'IdP est configuré pour renvoyer un identifiant unique des groupes (SID, ou autre),
    JPlatform recherche cette information unique dans les groupes et assigne le groupe correspondant à chaque identifiant reçu.
    • Avantage : sécurité accrue en raison du périmètre réduit des groupes concernés
    • Inconvénient : nécéssite une saisie manuelle par un administrateur coté JPlatform
      -> c'est l'approche recommandée pour garantir la sécurité des habilitations

Quelque soit l'approche retenue, les limites suivantes s'appliquent :

  • les groupes ne sont PAS créés ou mis à jour dans JPlatform à partir de SAML : le groupe doit exister dans JPlatform au moment de la synchronisation afin d'être ajouté au membre
  • les groupes ne sont PAS supprimés du Membre : si un groupe précédemment reçu n'est plus envoyé dans les attributs SAML, il n'est PAS retiré du membre

Configuration (coté JPlatform) :

L'attribut SAML dans lequel le module va lire l'information des groupes se renseigne dans la propriété jcmsplugin.saml.mapping.groups.
Par exemple :

jcmsplugin.saml.mapping.groups: http://schemas.xmlsoap.org/claims/Group

 

Les groupes existant sont trouvés dans JPlatform, en cherchant une des informations suivantes (en utilisant la valeur récupérée dans l'attribut SAML)

  1. par nom (désactivé par défaut) : s'active en renseignant la propriété suivante jcmsplugin.saml.sync.search-group-by-name, la valeur de cette propriété doit être le code de langue ISO-639 du nom du Groupe à rechercher
    si un groupe JPlatform a son nom (dans la langue spécifiée) égal à la valeur de l'attribut récupéré depuis SAML, alors le groupe est ajouté dans le Membre en cours de synchronisation.
    Exemple : 
    jcmsplugin.saml.sync.search-group-by-name: fr
  2. par identifiant issu des ExtraData (désactivé par défaut) : s'active en renseignant la propriété suivante : jcmsplugin.saml.sync.search-group-by-extradata, sa valeur doit être le nom de l'extradata de Group à rechercher
    si un groupe JPlatform a cette extradata égale à la valeur de l'attribut récupéré depuis SAML, alors le groupe est ajouté dans le Membre en cours de synchronisation.

    Exemple de mise en oeuvre (aucune de ces propriétés n'est fourni en standard, mais en les déclarant alors la configuration est complète) :

     

    1. # Declare Group ExtraData
extra.Group.saml-group-mapping:

# Provide I18N properties for field modification in Group edit form
en.extra.Group.saml-group-mapping: IdP Group ID
en.extra.Group.saml-group-mapping.help: Unique value returned by the Identity Provider, used during SAML member synchronization to retrieve the corresponding group in JPlatform

fr.extra.Group.saml-group-mapping: ID de groupe dans l'IdP
fr.extra.Group.saml-group-mapping.help: Valeur unique retournée par l'Identity Provider,  utilisée lors de la synchronisation SAML d'un membre pour trouver le groupe correspondant dans JPlatform.
    2. Configuration du module SAML pour indiquer de chercher les groupes à partir des identifiants renseigné dans cette ExtraData 
      # Configure SAML plugin to search for this ExtraData during member sync
jcmsplugin.saml.sync.search-group-by-extradata: extra.Group.saml-group-mapping

Cette configuration est possible depuis l'évolution SAML-1 intégrée dans les version 2.2 du module SAML

6.9 Désactiver la Synchronisation LDAP à l'authentification

Lorsque la configuration LDAP est active sur le site, les utlisateurs sont synchronisés avec le LDAP à chaque authentification SAML.
Il peut être utile de désactiver la synchronisation LDAP à l'authentication pour améliorer les performances, si l'utilisation du LDAP est activé et déjà synchronisé périodiquement.

Cette configuration peut s'effectuer depuis l'interface d'édition des propriétés du module.
La propriété correspondante est la suivante : 

jcmsplugin.saml.sync-with-ldap: false

Cette configuration est possible depuis l'évolution SAML-8 intégrée dans les version 1.1 du module SAML

6.10 Algorithme de signature

Il est possible de modifier l'algorithme à utiliser avec la propriété suivante qui accepte les valeurs SHA-1, SHA-256, SHA-384, et SHA-512: 

jcmsplugin.saml.sig-algo: SHA-512

Cette configuration est possible depuis l'évolution SAML-24 intégrée dans les version 2.2 du module SAML

Depuis la version 2.2 du module, l'algorithme de signature par défaut a été modifié pour passer de SHA-1 à SHA-256. 

7. Limites

Les points suivants ne sont PAS supportés par le module

7.1 HTTP-Artifact Binding

Ce binding n'est pas supporté.
Pour plus d'informations à ce sujet, rejoignez (Lien en accès restreint) puis consultez le sondage (Lien en accès restreint) .

7.2 Synchronisation des utilisateurs à partir de l'IdP

Lorsque la synchronisation des utilisateurs à partir de l'IdP est activée, les limites suivantes s'appliquent : 

  • Il n'y a pas de provisionning automatique : les utilisateurs sont créés ou mis à jour lors de leur authentification via SAML.
    Pour bénéficier d'un provisionning des utilisateurs, utilisez la synchronisation LDAP.
  • Il n'y a pas de suppression/désactivation automatique : si un utilisateur est supprimé
    Pour bénéficier d'une désactivation automatique des utilisateurs, utilisez la synchronisation LDAP.
  • La synchronisation des données de l'utilisateur ne permet pas la récupération d'une image de profil.
  • Concernant la synchronisation des groupes :
    • les groupes ne sont PAS créés ou mis à jour dans JPlatform à partir de SAML : le groupe doit exister dans JPlatform au moment de la synchronisation afin d'être ajouté au membre
    • les groupes ne sont PAS supprimés du Membre : si un groupe précédemment reçu n'est plus envoyé dans les attributs SAML, il n'est PAS retiré du membre

8. Diagnostics

En cas de problème avec le modules, vous pouvez activer les logs suivants pour obtenir plus de détail sur le comportement des différents composants.
 
Diagnostic des traitements effectués par le module : réception de jeton SAML, redirection, synchronisation des membres/groupes, ... 
<logger name="jcmsplugin.SAMLPlugin"> <level value="TRACE" /> </logger>
<logger name="com.jalios.jcmsplugin.saml"> <level value="TRACE" /> </logger>
 
Diagnostic des règles d'accès (aka AccessRules) configurées sur le module : 
<logger name="com.jalios.jcms.authentication.rules"> <level value="TRACE" /> </logger>
 
Diagnostic des échanges liés au protocole SAML (activation des logs de la librairie OpenSAML). ⚠ logs très verbeux 
<logger name="org.opensaml"> <level value="TRACE" /> </logger>
 
Diagnostic des interractions avec les autres briques d'authentification de JPlatform. ⚠ logs très verbeux 
<logger name="com.jalios.jcms.authentication"> <level value="TRACE" /> </logger>

11 votes :

43 commentaires

Cyrille Arzoumanian

2 votes :

le 04/01/2016 à 11:01
#1

Merci pour cette documentation ! Du bon jalios

Jean-Charles FELICITE
le 22/01/2016 à 11:34
#2

Merci Olivier. Je mets en place ce module chez un client en mode POC et te fait un retour.

fabrice mathieu
le 18/01/2017 à 15:50
#3

Bonjour, nous avons une question : est ce que le module supporte du multi IDP ?

Olivier Jaquemet
le 18/01/2017 à 15:58
#4

Bonjour. Non, le module n'a pas été spécifié ni testé pour supporter plusieurs IdP.

Ronan Kerdudou
le 02/01/2019 à 14:37
#5

REX pour les IdP (tels de ADFS) qui utilisent un niveau de chiffrement élevé :  Longueur de clé de cryptage trop importante lors de l'authentification SAML

Cyrille Arzoumanian
le 07/05/2019 à 15:26
#6

Voici une réponse du support :

 

Il faut que l'expiration de l'authentification configurée dans l'IdP soit la même dans le SP (JPlatform).

Donc :

  • soit vous modifiez le SP (JPlatform) pour utiliser une valeur de jcmsplugin.saml.websso-profile.max-auth-age...max-auth-agesimilaire à celle de l'IdP

  • soit vous modifiez l'IdP pour utiliser expirer l'authentification de la même façon que ce que vous avez indiqué dans le SP (JPlatform)

 

Pourquoi aucune note sur ce paramétrage possible dans la doc ?

Olivier Jaquemet
le 07/05/2019 à 15:49
#7

Bonjour Cyrille Arzoumanian,

Pourquoi aucune note sur ce paramétrage possible dans la doc ?

Car on ne pense pas toujours à tout, c'est un oubli suite à l'évolution SAML-12. C'est désormais documenté dans la section "6.4 Durée de validité de l'authentification". Merci de ton retour.
Cyrille Arzoumanian
le 07/05/2019 à 16:18
#8

merci  Olivier Jaquemet . Effectivement on pense pas à tout toujours :) .

J'ai juste tournée en rond pendant un certain temps  ? on teste et on revient vers vous. 

Belle journée

Franck Alcaraz
le 08/07/2019 à 17:49
#9

Bonjour pour info le lien fourni en exemple pour récupérer les métadata d'ADFS, chapitre 5.3,  (https://adfs.example.local/FederationMetadata/2007-06/FederationMetadata.xml) n'est plus valide.

Ronan Kerdudou
le 10/07/2019 à 12:36
#10

Bonjour, il s'agit d'un exemple de lien pour la forme de l'URL, le domaine "example.local" n'existant pas, je viens de retirer la possibilité de cliquer dessus.

Franck Alcaraz
le 12/07/2019 à 17:33
#11

Bonjour,

Nous avons un message d'erreur sur notre serveur ADFS 3 lorsque nous tentons de charger le fichier de sp-Metadata.xml : "Some of the content in the federation metadata was skipped because it is not supported by AD FS. Review the properties of the trust carefully before you save the trust to the ADFS configuration database."

Le fichier généré par JCMS est il normalement compatible avec ADFS 3 ?

Olivier RAGOT
le 31/01/2020 à 11:42
#12

Bonjour,

Actuellement en version 2.1 du module nous sommes interessés par l'évolution en 2.2 pour la récupération du fichier de méta-données via une URL plutôt que de copier celui-ci à la main à chaque mise à jour des certificats de notre IdP.

Par contre, la documentation ne précise pas si, lorsque le chemin est une URL, le SP Jalios mets à jour régulièrement (quotidiennement?) les informations (notamment certificats de signature) ou s'il faut éditer les propriétés du module pour "forcer" leur mise à jour.

Merci d'avance pour votre retour

Olivier Jaquemet

3 votes :

le 31/01/2020 à 12:12
#13

Bonjour Olivier RAGOT ,

Je vous confirme que lorsque vous configurez le module SAML 2.2 pour référencer les méta-données via une URL, un rechargement automatique aura lieu.
La fréquence de rechargement est calculée automatiquement à partir des informations validUntil ou cacheDuration si elles sont présentes dans les méta-données (1).  Autrement un réglage par défaut s'applique (2).

 

Vous pouvez modifier le niveau de log (dans le fichier de configuration log4j.xml) pour provoquer l'affichage des dates de rechargement dans les logs de l'application :

<logger name="org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider"> <level value="INFO" /> </logger>

Vous aurez alors des message de ce type : 

[AbstractReloadingMetadataProvider] - New metadata succesfully loaded for 'https://[...]/metadata.xml'
[AbstractReloadingMetadataProvider] - Next refresh cycle for metadata provider 'https://.../metadata.xml' will occur on '2019-11-26T15:45:05.688Z' ('2019-11-26T16:45:05.688+01:00' local time)

 

(1) cf section 2.3.1 de spécifications des méta-données SAML
(2) cf javadoc de la classe AbstractReloadingMetadataProvider de la librairie OpenSAML2 pour une description complète de l'algo utilisé pour déterminer la fréquence de rechargement

Olivier RAGOT
le 04/02/2020 à 14:14
#14

Merci pour ce retour Olivier Jaquemet .

Bonne journée

Patrice Maziero
le 30/09/2021 à 15:46
#15

Bonjour, est ce que le plugin permet l'accès aux metadatas distantes (jcmsplugin.saml.IDPSSO.metadata.path) en passant par un proxy?

Olivier Jaquemet

1 vote :

le 30/09/2021 à 16:49
#16

Bonjour Patrice Maziero ,

Oui. Si votre proxy de sortie est renseigné dans les propriétés du site, ce proxy sera utilisé pour la récupération des métadonnées SAML distantes.

Le paramétrage du proxy de sortie positionne les propriétés suivante : 

http.proxy.enabled: true
http.nonProxyHosts: ...      
http.proxyHost: ...
http.proxyPort: ...
http.proxy.login: ...
http.proxy.password: ...

(Notez que ces propriétés JPlatform sont automatiquement propagée en tant que propriétés système Java pour être utilisé par toutes les APIs de requête d'accès distant)

Patrice Maziero
le 30/09/2021 à 17:47
#17

Ça fonctionne, merci!

Autre point, j'essaye de synchroniser les groupes avec ceux de l'idp.

Je reçoit de l'idp le groupe "900" dans l'attribut "roles" :

<saml2:Attribute FriendlyName="roles" Name="roles" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue>900</saml2:AttributeValue></saml2:Attribute>

 

j'ai tenté la conf suivante (custom.prop) sans succès :

jcmsplugin.saml.mapping.groups: roles
jcmsplugin.saml.saml.sync.search-group-by-name: fr

Le groupe "900" existe déjà dans JPlatform mais à la connexion le nouveau Member créé n'a pas de groupe associé, pourtant l'idp transmet bien "roles"="900"

Olivier Jaquemet

2 votes :

le 01/10/2021 à 18:30
#18

Patrice Maziero l'exemple dans la documentation contenait une erreur, que vous avez très logiquement repris...

Vous avez positionné la propriété jcmsplugin.saml.saml.sync.search-group-by-name: fr
il s'agit en fait de jcmsplugin.saml.sync.search-group-by-name: fr

(je viens de corriger la documentation...)

Loïc de Chantérac
le 03/12/2021 à 10:00
#19

Bonjour Patrice Maziero ,

Est-il possible de configurer la synchronisation des groupes avec plusieurs attributs du compte ?

JPlatform trouve et assigne au compte le groupe correspondant à la valeur de chaque attribut configuré.

Jean-Charles FELICITE
le 29/09/2022 à 15:56
#20

Bonjour,

Les liens public sur 10SP5 ne semblent pas fonctionner avec SAML, une authentification est demandé systématiquement, et les partenaires externes ne peuvent pas ouvrir le document alors que le but est pourtant de partagez un document avec une personne qui n'aurait pas d'accès à l'application. 

Avez-vous une astuce pour éviter cette authentification SAML avec les liens publics?

Je ne trouve rien sur la communauté, j'ai l'impression que personne n'a été confronté au problème

Merci 

Olivier Jaquemet

3 votes :

le 29/09/2022 à 16:04
#21

Bonjour Jean-Charles FELICITE 

Le bug SAML-47 est enregistré à ce sujet. Sa correction est d'ores et déjà planifié pour la prochaine version corrective 2.3.2 du module SAML.

En attendant, vous pouvez mettre en place une règle d'accès pour contourner le souci, quelque chose dans ce genre :

jcmsplugin.saml.access-rule.class: com.jalios.jcms.authentication.rules.UriAccessRule
jcmsplugin.saml.uri-access-rule.regex: ^(/front/publicLink/publicDownload\.jsp)|(/BinaryFile)$
Cyrille Arzoumanian

1 vote :

le 29/09/2022 à 16:05
#22

Jean-Charles FELICITE  nous sommes dans le meme cas que vous et dans l'attente depuis plusieurs mois maintenant d'une réponse de part de jalios.

Les différents contournement proposé ne fonctionnent tjrs pas et la correction aura lieu sur le module prochainement d'après la réponse dans leur ticket.

Je suis confiant ils vont corriger

Cyrille Arzoumanian
le 29/09/2022 à 16:06
#23

ah bah on s'est croisé avec Olivier Jaquemet ... 

Alors en revanche ca fonctionne pas chez nous :

 

jcmsplugin.saml.access-rule.class: com.jalios.jcms.authentication.rules.UriAccessRule
Jean-Charles FELICITE
le 29/09/2022 à 16:22
#24

Merci Olivier Jaquemet  pour la réponse rapide.

Pierre MORIN
le 29/09/2022 à 16:53
#25

Bonjour Olivier Jaquemet ,

La JSP publicDownload.jsp est déclarée comme "publique" dans les propriétés de JPlatform. (channel.public-path.public-download: front/publicLink/publicDownload.jsp)

Le module SAML va t-il donc "s'activer" pour toutes les JSP "publiques" ? Si oui, est-ce normal ?

Olivier Jaquemet

1 vote :

le 29/09/2022 à 17:11
#26

Bonjour Pierre MORIN 

Le module SAML va t-il donc "s'activer" pour toutes les JSP "publiques" ?

Après la correction SAML-47, la redirection vers l'IdP ne se déclenchera plus pour les URLs "publiques".

C'est par exemple ce qui a été fait pour d'autres modules de SSO :

  • WAFFLE-40 - Do request SSO for request to public path
  • JCMSSSO-24 - Do request SSO for request to public path 

Si oui, est-ce normal ?

Le comportement actuel n'est pas normal, c'est un bug.

Le comportement sera normal après la correction.

Pierre MORIN
le 29/09/2022 à 17:20
#27

Merci Olivier Jaquemet pour votre retour. 😊

De ce que je comprend, la correction va se faire dans les modules. J'en déduis que le comportement de JPlatform (le coeur) est de faire appel aux AuthentificationHandlers même pour les JSP publiques.

Ai-je bien compris ? Cela veut-il dire que nous devons faire en sorte que nos AuthentificationHandlers spécifiques prennent ce cas en compte ?

Merci.

Cordialement

 

P.S. : La REGEX à appliquer ne devrait-elle pas plutôt être ^(/front/publicLink/publicDownload\.jsp?id=.*)|(/BinaryFile)$ ?

Jean-Charles FELICITE
le 29/09/2022 à 17:35
#28

Le contournement ne fonctionne pas en effet, j'ai testé plusieurs REGEX dont celle que Pierre à mis dans son PS (pour info Pierre c'est un de mes tests), idem cela ne fonctionne pas.

Cordialement,

Olivier Jaquemet

2 votes :

le 29/09/2022 à 18:00
#29

De ce que je comprend, la correction va se faire dans les modules. J'en déduis que le comportement de JPlatform (le coeur) est de faire appel aux AuthentificationHandlers même pour les JSP publiques.

Ai-je bien compris ? Cela veut-il dire que nous devons faire en sorte que nos AuthentificationHandlers spécifiques prennent ce cas en compte ?

C'est une très bonne question !

La particularité des authentifications SAML, Waffle, JcmsSSO, c'est qu'ils redirigent l'utilisateur (saml/jcmsso) ou bloque la requete HTTP de l'utilisateur (waffle), dès qu'ils doivent se déclencher.
Contrairement à d'autre type d'authentification qui ne font que consommer des informations externes qui sont présentes ou pas dans la requête ! (cookie, authkey, header HTTP issue d'un frontal, ... )
A ce titre, ces modules ont effectivement besoin de prendre en compte dans leur comportement certaines spécificités de comportement de JPlatform, comme notamment les JSP/chemins publics.

Est-ce que vos modules d'authentifications doivent faire pareil ?
-> S'ils redirigent/bloquent les requetes HTTP de l'utilisateur, oui. S'ils ne font que consommer une information externe, non.

Est-ce que ça ne devrait pas être le comportement du coeur, ne pas invoquer les mécaniques d'authentifications pour les JSP publics ?
-> 😮 ça parait évident au premier abord ...
Coté + : tous les modules en bénéficie sans devoir refaire le boulot chacun de leur coté,
Coté - : si on veut suivre/modifier/adapter l'authentification courante dans un JSP publique, on ne peut pas
Je vais réfléchir à la question, mais effectivement ça pourrait  😅

Olivier Jaquemet

2 votes :

le 29/09/2022 à 18:28
#30

Concernant le contournement utilisant la UriAccessRule

  1. elle ne s'applique que sur le chemin des servlets/JSP, pas sur les paramètres :
    -> pas besoin de préciser quoi que ce soit sur les querystring/param dans la regex
  2. elle s'applique sur le chemin en incluant le contexte path,
    la regex que j'ai indiqué est valable pour les applications installées sur le contexte racine, (e.g: https/jplatform.example.com/)
    --> si votre application est installée dans un contexte spécifique (e.g.https/jplatform.example.com/moncontexte/) alors il faut adapter la regex et l'inclure dedans : 
    jcmsplugin.saml.access-rule.class: com.jalios.jcms.authentication.rules.UriAccessRule
jcmsplugin.saml.uri-access-rule.regex: ^(/moncontexte/front/publicLink/publicDownload\.jsp)|(/moncontexte/BinaryFile)$
fabrice mathieu
le 30/09/2022 à 08:35
#31

Bonjour,

Cela fonctionne maintenant chez nous avec la regex suivante : jcmsplugin.saml.uri-access-rule.regex:  ^(/front/publicLink/publicDownload\.jsp)|(/BinaryFile)$

Mais la regex n'est pas suffisante côté Jalios : il a fallu aussi whitelister côté sso ces urls ainsi que les contenus statiques (js, css).

Nous avons également du désactiver le smartphonePlugin qui demandait encore de désactiver d'autres URLs.

Jean-Charles FELICITE
le 30/09/2022 à 09:24
#32

Merci Olivier Jaquemet 

Effectivement cela fonctionne beaucoup mieux avec le nom de contexte applicatif.

En tant normal, nous installons sous ROOT, mais le client chez qui j'ai fait les tests l'application a bien un nom de contexte différent.

Merci encore

Patrice Maziero
le 07/12/2022 à 09:13
#33

Bonjour Olivier Jaquemet ,

Est-il possible de donner les droit d'administration centrale via l'IDP?

Si ce n'est pas possible quel est est le process pour donner les droits d'administration centrale à un ou plusieurs utilisateurs ? Passer par le compte admin par defaut ?

Ronan Kerdudou

1 vote :

le 09/12/2022 à 09:32
#34

De manière générale il n'est pas souhaitable de donner les droits d'administration centrale à un compte utilisateur. Cette capacité ne devrait être présente que sur un ou plusieurs comptes de services, accessible par délégation à certains utilisateurs.

Le mapping des groupes avec l'IDP permet de faire rejoindre un groupe qui donnerait des ACL par exemple (généralement suffisant pour répondre au besoin), mais il n'est pas possible de piloter l'état "admin central" de cette manière.

Patrice Maziero
le 13/12/2022 à 16:50
#35

Ok, dommage.

Autre question, lorsque j'active l'option " Authentification SAML automatique" je n'ai plus accès à la mire d'authentification (pour l'accès avec le compte admin central par exemple). Est ce normal? Comment accèder via la mire quand cette option est activée?

Olivier Jaquemet
le 14/12/2022 à 09:34
#36

Autre question, lorsque j'active l'option " Authentification SAML automatique" je n'ai plus accès à la mire d'authentification (pour l'accès avec le compte admin central par exemple). Est ce normal? Comment accèder via la mire quand cette option est activée?

Vous trouverez la réponse à cette question dans la section 6.2 Règles d'accès (aka AccessRules) ci-dessus.

Michel Remacle
le 03/02/2023 à 14:14
#37

Bonjour, est-il prévu d'avoir un multi idp à l'avenir? Exemple concret d'utilisation : dans le cadre d'une fusion de deux entreprises, cela permettrait aux personnel de chacune des deux de s'identifier sur une plateforme temporaire (qui peut être assez long selon le type d'entreprises) commune.

Olivier Jaquemet
le 03/02/2023 à 14:17
#38

Bonjour Michel Remacle 

À ce jour, ça n'est pas prévu.

Michel Remacle
le 03/02/2023 à 14:55
#39

Dommage 😭 😉

Olivier Jaquemet

2 votes :

le 11/05/2023 à 15:17
#40

Bonjour à tous,

La version 2.4 du module SAML est disponible au téléchargement :
https://community.jalios.com/plugin/saml

Elle inclut notamment

  • le correctif SAML-47 pour ne pas contrôler l'accès aux URL public (comme les liens publics de téléchargement), comme évoqué dans les précédents commentaires.
  • la synchronisation possible les champs suivant d'un membre
    • [SAML-52] la langue de l'utilisateur
    • [SAML-49] le responsable 
    • [SAML-49] l'assistant (nécessite JPlatform 10 SP6 ou au dela)
  • [SAML-37] la configuration depuis les propriétés du module des réglages de "Marge de temps" et "d'Âge maximal de l'authentification", avec une aide en ligne pour expliquer les usages les plus répandus
  • [SAML-51] une petite amélioration des logs lors des diagnostics
Olivier Jaquemet
le 23/11/2023 à 08:47
#41

Bonjour à tous.

Une nouvelle section "diagnostics" a été ajoutée à la fiche ci-dessus afin d'indiquer quels logs activer en cas de dysfonctionnement.

Pierre MORIN
le 08/01/2024 à 14:52
#42

Olivier Jaquemet , je rebondis sur votre avant-dernier commentaire : serait-il possible d'avoir la liste exhaustive des champs synchronisables dans la présente documentation ?

On parle ici du mapping des groupes, mais pas de celui des membres.

J'ai trouvé ça dans le plugin.prop du module 2.4.1, mais ça ne vaut pas une documentation :

jcmsplugin.saml.mapping.name: 
jcmsplugin.saml.mapping.f-name: 
jcmsplugin.saml.mapping.salut: 
jcmsplugin.saml.mapping.organization: 
jcmsplugin.saml.mapping.department: 
jcmsplugin.saml.mapping.job: 
jcmsplugin.saml.mapping.mail: 
jcmsplugin.saml.mapping.phone: 
jcmsplugin.saml.mapping.mobile: 
jcmsplugin.saml.mapping.street: 
jcmsplugin.saml.mapping.postalCode: 
jcmsplugin.saml.mapping.postOfficeBox: 
jcmsplugin.saml.mapping.locality: 
jcmsplugin.saml.mapping.region: 
jcmsplugin.saml.mapping.country:
jcmsplugin.saml.mapping.language: 
jcmsplugin.saml.mapping.address: 
jcmsplugin.saml.mapping.info: 
jcmsplugin.saml.mapping.manager:
jcmsplugin.saml.mapping.assistant:
jcmsplugin.saml.mapping.groups: 

Olivier Jaquemet

2 votes :

le 09/01/2024 à 10:24
#43

Bonjour Pierre MORIN ,

J'ai ajouté une section "Configurer la synchronisation des utilisateurs" dans la documentation ci-dessus.