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
IdP : Identity Provider, serveur de gestion d'identité, l'application fournissant l'authentification, l'identification, la fédération.
SP : Service Provider, l'application utilisant l'IdP comme solution d'authentification/identification (cad: JPlatform)
SAML 2.0 : Security Assertion Markup Language (prononcer sam-el) Protocole et format de communication entre IdP et SP
2. Pré-requis
Un accès administrateur à l'IdP
JPlatform 9 SP1 ou au delà
3. Démarrage rapide
Cette section vous propose une installation rapide du module si vous êtes déjà familier avec
les concepts de SAML 2.0
la configuration de JPlatform
la configuration de votre IdP
Cette configuration rapide est adaptée à la mise en œuvre d'un POC.
Pour une mise en production ou pour une explication détaillée de chaque étape, suivez la configuration complète
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
L'IdP est déclaré dans JPlatform grâce au fichier ou à l'URL des metadata de l'IdP
JPlatform est configuré dans l'IdP grâce au fichier ou à l'URL des metadata généré par JPlatform
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
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 :
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 :
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
Placez le certificat sur le filesystem de JPlatform, par exemple dans la webapp : WEB-INF/data/saml2/sp-signing-certificate.jks
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)
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
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 :
Configurer l'authentification JPlatform avec Azure AD Guide réalisé sur Azure AD (fin 2019) , où la synchronisation des utilisateurs est assurée via SAML (Azure AD), avec une configuration de NameID E-Mail Address
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 :
JPlatform + annuaire ActiveDirectory + IdP ADFS
Coté JPlatform, configuration LDAP du login : ldap.mapping.login: userPrincipalName
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)
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).
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
d'envoyer à l'IdP une demande d'authentification (AuthnRequest) dont le format de NameID souhaité est de type transient.
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
pour la demande : configurer le format de NameID souhaité dans la propriété jcmsplugin.saml.websso-profile.nameid-format
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
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
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
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 :
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
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 :
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)
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
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) :
# 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.
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
Merci pour cette documentation ! Du bon jalios
Merci Olivier. Je mets en place ce module chez un client en mode POC et te fait un retour.
Bonjour, nous avons une question : est ce que le module supporte du multi IDP ?
Bonjour. Non, le module n'a pas été spécifié ni testé pour supporter plusieurs IdP.
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
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'IdPsoit 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 ?
Bonjour Cyrille Arzoumanian,
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
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.
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.
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 ?
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
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
validUntiloucacheDurationsi 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 :Vous aurez alors des message de ce type :
(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
Merci pour ce retour Olivier Jaquemet .
Bonne journée
Bonjour, est ce que le plugin permet l'accès aux metadatas distantes (jcmsplugin.saml.IDPSSO.metadata.path) en passant par un proxy?
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 :
(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)
Ç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" :
j'ai tenté la conf suivante (custom.prop) sans succès :
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"
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: fril s'agit en fait de
jcmsplugin.saml.sync.search-group-by-name: fr(je viens de corriger la documentation...)