Installation du module SSO
- Télécharger ici le package zip de la dernière version du module SSO de Daniel Berthereau. Dans notre cas, il s'agit de la version 3.4.8.
- Copier et décompresser le package dans le répertoire /var/www/html/omeka-s/modules :
# cd /var/www/html/omeka-s/modules
# unzip ./SingleSignOn-3.4.8.zip - Se connecter à l'application Omeka-S puis aller dans le menu "Modules" et cliquer sur "Installer"
Configuration du Service Provider
Récupération des métadata de l'IdP par le SP
Si l'on souhaite récupérer automatiquement les métadata de l'IdP, notamment en cas de renouvellement de certificat, il faut saisir l'URL des metadata dans le champ approprié de la page de configuration du module SSO :
Toutefois dans notre cas, cette opération retourne l'erreur suivante lorsqu'on enregistre la configuration :
- The IdP url "https://adfs01.pic.lan/FederationMetadata/2007-06/FederationMetadata.xml" does not return any metadata.
Si l'on essaie de récupérer le fichier xml en ligne de commande, la commande wget refuse le téléchargement du fichier et indique que l'URL n'est pas de confiance. Cela est normal puisque le certificat TLS utilisé par HTTPS a été signé par une autorité locale inconnue par wget. Pour résoudre le pb, on peut :
- ajouter l'option "--no-check-certificate" à la commande wget
- récupérer le certificat à l'aide d'un navigateur (on accède à l'URL puis au cadenas puis on download les fichiers PEM). Ensuite on ajoute ces certificats dans le magasin de confiance de RHEL en les plaçant dans le répertoire
/etc/pki/ca-trust/source/anchors/puis en lançant la commande update-ca-trust
=> Du coup, cela élimine proprement le message d'erreur de wget, mais cela ne résoud pas le problème de récupération automatique des métadata dans Omeka-S.
Nous partons donc sur une saisie manuelle des métadata requises dans Omeka-s ce qui ne génère pas d'erreur à l'enregistrement cette fois-ci :
Configuration de la partie de confiance dans ADFS
Récupération des métadata du SP par l'IdP
- Récupération du fichier de métadata d'Omeka-s à l'URL de l'application : http://omeka.pic.lan/omeka-s/sso/metadata
- Création dans ADFS de la partie de confiance à l'aide du fichier de métadata
Création des revendications
Dans un premier temps, ne connaissant pas les attentes d'Omeka-S pour identifier de manière unique les comptes authentifiés, je me suis contenté d'émettre une revendication correspondant à l'attribut "username" lui-même issu du Sam-Account-Name d'Active Directory. S'en sont alors suivis une série d'erreurs et de points de blocage que je liste pour mémoire ci-dessous. Une fois ces erreurs résolues, j'ai pu effectuer une authentification unique ADFS basée sur le module SSO installé.
Error details: MSIS3077
Lors du test d'accès à la page d'authentification unique d'Omeka-S http://omeka.pic.lan/omeka-s/sso/login, l'erreur ADFS suivante apparait :
Error details: MSIS3077 : la propriété AssertionConsumerServices n'est pas configurée pour l'approbation de partie de confiance « http://omeka.pic.lan/omeka-s/sso ».
Explication :
Le fichier XML initialement transmis à ADFS lors de l'échange des métadata inclut bien une URL pour l'AssertionConsumerServices mais en HTTP.
Comme ADFS n'autorise que HTTPS (message d'erreur lorsqu'on essaie de saisir manuellement une URL non TLS dans <propriété / Points de terminaison / Ajouter SAML / Consommateur d'assertions SAML>) et que l'URL transmise est du HTTP simple, aucune URL n'est donc prise en compte, d'où le message d'erreur.
Résolution :
Mise en place d'un certificat TLS pour accéder à https://omeka.pic.lan
Erreur liée à AssertionConsumerServiceURL
Lors du test d'accès à la page d'authentification unique d'Omeka-S http://omeka.pic.lan/omeka-s/sso/login, un nouveau message d'erreur concernant la propriété AssertionConsumerServiceUrl apparait.
Explication :
Cela est dû au fait que les URL qui ont été insérées dans cette propriété et dans EntityID correspondent à l'adresse du serveur Omeka-S. En effet, le module SAML semble se baser sur l'adresse de destination des requêtes HTTP pour en déduire les URL de ces propriétés. Or cette méthode ne fonctionne plus si Omeka est dans un réseau privé, derrière un Reverse Proxy. Ce module dans sa version 3.4.8, ne semble pas permettre de spécifier manuellement un EntityID comme cela se fait dans certains autres modules SSO, ce qui à priori, aurait permis de résoudre ce souci.
Résolution :
Ticket ouvert sur gitlab.com auprès du développeur et accès direct au serveur sans passer par le Reverse Proxy.
Déplacement et adaptation du serveur Omeka-S au sein du Labo de test afin de permettre un accès direct sans Reverse proxy.
Erreur : Signature validation failed. SAML Response rejected
Lors du test d'accès à la page d'authentification unique d'Omeka-S http://omeka.pic.lan/omeka-s/sso/login, un problème apparait signalant que la validation de la signature a échouée.
Explication :
Consultation de ce post : https://github.com/SAML-Toolkits/php-saml/issues/216
Résolution :
Effectivement, dans la réponse SAML, il n'y a qu'un certificat retourné (celui pour vérifier la signature, alors qu'au boulot, les tests retournaient 2 certificats, 1 pour la signature et l'autre pour le chiffrement) . Une fois que j'ai eu copié celle de la réponse SAML dans celle enregistrée dans le module, l'erreur a disparu.
Erreur : Omeka S encountered an error
Lors du test d'accès à la page d'authentification unique d'Omeka-S http://omeka.pic.lan/omeka-s/sso/login, une nouvelle erreur obscure apparait : Omeka S encountered an error.
Activation des logs comme préconisé ici https://omeka.org/s/docs/user-manual/errorLogging/ . L'erreur loguée est la suivante :
2023-12-19T20:50:04+00:00 ERR (3): OneLogin\Saml2\ValidationError: NameID not found in the assertion of the Response in /var/www/html/omeka-s/modules/SingleSignOn/vendor/onelogin/php-saml/src/Saml2/Response.php:642
Stack trace:
#0 /var/www/html/omeka-s/modules/SingleSignOn/vendor/onelogin/php-saml/src/Saml2/Response.php(686): OneLogin\Saml2\Response->getNameIdData()
#1 /var/www/html/omeka-s/modules/SingleSignOn/vendor/onelogin/php-saml/src/Saml2/Auth.php(241): OneLogin\Saml2\Response->getNameId()
#2 /var/www/html/omeka-s/modules/SingleSignOn/src/Controller/SsoController.php(238): OneLogin\Saml2\Auth->processResponse()
#3 /var/www/html/omeka-s/vendor/laminas/laminas-mvc/src/Controller/AbstractActionController.php(71): SingleSignOn\Controller\SsoController->acsAction()
#4 /var/www/html/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Laminas\Mvc\Controller\AbstractActionController->onDispatch()
#5 /var/www/html/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(179): Laminas\EventManager\EventManager->triggerListeners()
#6 /var/www/html/omeka-s/vendor/laminas/laminas-mvc/src/Controller/AbstractController.php(97): Laminas\EventManager\EventManager->triggerEventUntil()
#7 /var/www/html/omeka-s/vendor/laminas/laminas-mvc/src/DispatchListener.php(132): Laminas\Mvc\Controller\AbstractController->dispatch()
#8 /var/www/html/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Laminas\Mvc\DispatchListener->onDispatch()
#9 /var/www/html/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(179): Laminas\EventManager\EventManager->triggerListeners()
#10 /var/www/html/omeka-s/vendor/laminas/laminas-mvc/src/Application.php(325): Laminas\EventManager\EventManager->triggerEventUntil()
#11 /var/www/html/omeka-s/index.php(21): Laminas\Mvc\Application->run()
#12 {main}
Résolution :
Problème réglé en créant une règle de revendication qui émet un NameID car cet attribut particulier semble être requis.
Erreur : No email provided to log in or register
Lors du test d'accès à la page d'authentification unique d'Omeka-S http://omeka.pic.lan/omeka-s/sso/login, un nouveau problème est remonté dans l'interface : "No email provided to log in or register."
=> Pb remonté dans le log : "2023-12-20T09:35:46+00:00 ERR (3): No email provided or mapped. Available canonical attributes for this IdP: username, mail. Available friendly attributes for this IdP: ."
Explication :
La bonne pratique pour émettre des attributs à partir d'un IdP est de leur donner un nom principal canonique, c'est-à-dire un nom unique et normalisé qui peut être une URI propre à ADFS (ex : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress) ou mieux un OID propre à SAML (Object IDentifier, ex : urn:oid:0.9.2342.19200300.100.1.3). Il est également possible de donner à l'attribut un nom convivial appelé "FriendlyName". Cependant cette possibilité ne semble pas être permise avec ADFS. ChatGPT prétend qu'ADFS peut créer automatiquement le FriendlyName dans certains cas, mais pas tous. Le problème, c'est que si on souhaite émettre à partir d'ADFS des noms d'attributs conviviaux personnalisés sans format URI ni OID via l'interface des règles de revendication, ils seront alors émis dans la propriété SAML 'Name' et non pas 'FriendlyName'. Côté Service Provider, certains modules SSO s'attendant à trouver le nom convivial sans format dans la propriété 'FriendlyName' et le nom principal au format OID dans la propriété 'Name' de la balise XML <attribute> de la réponse SAML risquent alors de refuser la réponse SAML
Résolution :
Problème résolu par débogage PHP du module. Pour corriger ce problème, il faut créer à la main une règle de revendication personnalisée qui émet l'attribut au format OID. Cela nécessite d'être un peu familiarisé avec le langage de revendication (bouton "Afficher le langage de règle").
Note complémentaire : Après seconde lecture du code PHP + BDD, les seuls attributs utilisateurs spécifiques au compte Omeka et mappables en SAML correspondent aux champs 'email' (contrainte 'UNIQUE'), 'name' (<=> displayName) et 'role' de la table user. La lecture de ces 3 champs dans le jeton SAML se fait selon la propriété Name au format OID ou les attributs déclarés dans le mappage et présent dans la propriété FriendlyName de la balise <Attribute>. Si d'autres attributs configurés dans le module SSO existent, ils seront injectés dans la table user_setting avec un couple id/value. La lecture de ces attributs supplémentaires dans le jeton SAML se fait selon les attributs déclarés dans le mappage et présent dans la propriété FriendlyName OU la propriété Name de la balise <Attribute>. Il n'y a donc pas de format spécifique canonique associés aux attributs supplémentaires et ils seront automatiquement mis à jour ou ajoutés dans la table user_setting.
Listes d'OID SAML :
https://docs.raven.cam.ac.uk/en/latest/saml2-attributes/
https://puhuri.neic.no/idp_integration/attributes/
https://oric.ehe.osu.edu/files/2022/02/Shibboleth-codes-from-Word-2jeef0i.pdf
Noms canoniques attendus par le module pour les 3 attributs principaux si le FriendlyName est absent :
protected $attributesMapCanonical = [
'urn:oid:0.9.2342.19200300.100.1.3' => 'email',
'urn:oid:2.16.840.1.113730.3.1.241' => 'name',
'https://samltest.id/attributes/role' => 'role',
];