Jalios Community
Espaces
Contenus
Il n'y a pas de résultat.
Il n'y a pas de résultat.
S'inscrire

Module SAML - Documentation

  • Rédacteur :
  • Date de modification : 01/10/21

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 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.8 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.9 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