Retour : Page Principale > sommaire aide > sommaire aide-mémos

---

Intégration du SSO avec le widget d'authentification

Comment faire pour intégrer le SSO à votre nouvelle application ? Y a-t-il du code tout prêt ? Des bonnes pratiques à connaître ? T'habites Bourg-la-Reine ou t'habites Choisy-le-Roi ? Plein de questions qu'il faut se poser pour authentifier correctement ses utilisateurs chéris.

Principe de l'authentification

Les étapes sont les suivantes (voir la doc du service annuaire:auth) :

• on appelle service:annuaire:auth/identite pour savoir si on est connu ou non
• si oui, obtention d'un jeton JWT :
  • on décode ce jeton pour avoir les infos de l'utilisateur (courriel, nom / pseudo, id...)
  • si la couche métier est distincte (webservices) :
    • on stocke le jeton quelque part pour lui passer
    • la couche de webservices doit à chaque appel :
      • récupérer le jeton
      • le vérifier auprès de l'annuaire en appelant service:annuaire:auth/verifierjeton
      • le décoder
      • une fois les infos utilisateur obtenues, vérifier que l'utilisateur en cours a le droit d'exécuter l'action du service
  • sinon :
    • on se débrouille avec l'id / courriel utilisateur qu'on vient de décoder
• si non, pas de jeton :
  • on se connecte en appelant service:annuaire:auth/connexion et on refait un tour
• à la fin, on se déconnecte en appelant service:annuaire:auth/deconnexion

Intégration dans l'interface (applications AJAX)

Le plus simple est d'utiliser le widget d'authentification : http://www.tela-botanica.org/widget:reseau:auth
Celui-ci gère la connexion et la déconnexion, et peut vous rediriger vers la page depuis laquelle vous l'avez appelé.

Typiquement, si on se trouve sur la page http://www.tela-botanica.org/maSuperAppli?tralala=pouet :

• on appelle service:annuaire:auth/identite pour savoir si on est connu ou non (avec un appel AJAX $.get() par exemple - attention il faut ajouter xhrFields: withCredentials, voir le fichier .js d'exemple)
• si oui, obtention d'un jeton :
  • on écrit "bonjour $intitule"
  • on propose un lien de déconnexion de la forme : http://www.tela-botanica.org/widget:reseau:auth?action=deconnexion&origine=http://www.tela-botanica.org/maSuperAppli?tralala=pouet
• si non, pas de jeton :
  • on propose un lien de connexion de la forme : http://www.tela-botanica.org/widget:reseau:auth?origine=http://www.tela-botanica.org/maSuperAppli?tralala=pouet

On trouve un exemple de cela dans le code de la barre de navigation (séparé entre le template PHP et le code JS) :

• navigation.js
• bootstrap3.tpl.php

Composant javascript réutilisable (Bower)

à compléter - penser à déclarer un composant dans Bower (2016-03-10)

Intégration dans l'interface (applications non-AJAX)

L'intégration au SSO est facile avec les applications AJAX : elles ont le droit d'appeler l'annuaire tout en bénéficiant des cookies du navigateur. Mais pour les applications classiques sans AJAX, c'est une autre paire de manches. Le problème est le suivant : une application qui se trouve sur un domaine différent du domaine du cookie tb_auth (www.tela-botanica.org) ou qui n'est pas en HTTPS sur ce domaine, ne pourra pas disposer du cookie. Appeler l'annuaire en PHP avec un file_get_contents() ou libcurl ne sert à rien puisqu'on n'a pas le cookie. Il est donc impossible pour ces applications de savoir si l'utilisateur est connecté au SSO ou non. On est bien embêtés, dites-moi.

Solution 1 - employée par le plugin wp-tb-sso

Les applications installées sur un domaine *.tela-botanica.org et fonctionnant sur HTTPS bénéficient du cookie tb_auth, sécurisé mais disponible sur tous les sous-domaines (fait le 2016-03-01). À partir de fin 2016, cela commence à être le cas pour toutes les applications.

En lisant ce cookie, on obtient le dernier jeton valide reçu par l'utilisateur. Ce jeton est généralement expiré (15mn de durée de vie); en appelant le service auth:rafraichir de l'annuaire avec le jeton expiré passé en GET ou dans le header Authorization, on reçoit en retour un jeton rafraîchi, et on a gagné.

Solution 2 - employée par Yeswiki et Papyrus

Faire des triples redirections de ouf tout en n'obtenant qu'une synchronisation partielle. C'est un peu ça ou rien...
Principe:

• rediriger vers l'annuaire pour demander le statut (connecté ou non) - celui-ci sait lire le cookie tb_auth s'il est présent (redirection 1)
• connecté ou non, l'annuaire redirige vers la page d'origine avec un paramètre GET Authorization contenant un jeton SSO, ou une chaîne vide (redirection 2)
• la page d'origine pose un cookie mandataire (voir ci-dessous) de courte durée, contenant le jeton, ou un mot-clef signifiant l'absence de jeton (un cookie nul ne peut pas exister), et prend acte du caractère connecté ou non de l'utilisateur
• afin d'éliminer le paramètre Authorization de l'URL, qui perturbe les copier-coller etc., la page d'origine se redirige vers elle-même en supprimant ce paramètre, et la présence du cookie mandataire empêche de rediriger en boucle (redirection 3)
• ouf !

Afin d'alléger le serveur, un cookie mandataire est posé pour chaque application, d'une durée courte (30s par exemple); ceci permet de ne faire des triples-redirections que toutes les 30 secondes. En outre sur Papyrus, ce cookie est prolongé de 30s tant que l'utilisateur change de page; on considère que le basculement vers une autre application depuis laquelle il se déconnecte, puis le retour sur la page d'origine prend plus de 30 secondes, et n'empêche pas de détecter la déconnexion (stratégie à vérifier sur le long terme).

NOTE importante : pour les URL étant déjà des redirections (ex: http://www.tela-botanica.org/bdtfx-nn-141-synthese ), il est important que ces redirections conservent la Query String sans quoi le paramètre GET Authorization renvoyé par l'annuaire sera ignoré et la redirection bouclera et n'aboutira jamais ! Penser à mettre le flag [QSA] dans le .htaccess où la redirection est déclarée.

Intégration dans les services / couches métier (protection des accès)

Important : en aucun cas un programme autre que le Site Web tela-botanica.org ne doit lire directement la base de données des comptes utilisateurs ! Bah oui c'est à ça que sert l'annuaire : tout est découplé. Les applications qui doivent conserver des informations sur les utilisateurs (ex: CeL, DeL...) dans une table de leur base de données, doivent gérer elles-mêmes la synchronisation avec l'annuaire.

Tout service qui souhaite connaître les informations de l'utilisateur loggé sur le SSO devrait fonctionner à base de jetons. Les services étant généralement sur un domaine différent de www.tela-botanica.org (api. par exemple, ou autre), ils ne peuvent pas se reposer sur le cookie tb_auth. Ils doivent donc être capables de lire un jeton que le client qui les appelle inclura dans ses requêtes.

Ce jeton peut être passé en POST (avec GET, attention à la longueur) mais l'idéal est d'utiliser l'entête Authorization.
Le client devrait appeler le service en ajoutant un entête HTTP de la forme (avec ici un exemple de jeton) :

Le service doit donc décoder cet entête pour récupérer le jeton.
ATTENTION: il est important de valider le jeton auprès de l'annuaire, pour vérifier qu'il est authentique, et éviter l'usurpation d'identité.

Permissions (rôles) et groupes

À compter de la version 2 reposant sur Wordpress, les jetons émis par l'annuaire contiennent deux collections supplémentaires :

• permissions une liste des noms de rôles endossés par l'utilisateur
  • avec l'implémentation reposant sur Wordpress, les permissions correspondent aux rôles Wordpress réglables dans l'interface de modification d'un utilisateur
  • le plugin Wordpress Tela Botanica ajoute des permissions commençant par tb_; ces permissions sont destinées à être interprétées par les applications en utilisant par exemple le composant tb-auth-php et permettent à l'administrateur du site Web de donner facilement des pouvoirs aux utilisateurs sur une application
• groupes : un dictionnaire ayant pour clé les identifiants des groupes auxquels l'utilisateur appartient, et pour valeur le rôle de l'utilisateur dans ce groupe (ex: "adm" pour "administrateur")
  • avec l'implémentation reposant sur Wordpress, les groupes correspondent aux "projets" de l'espace projets, c'est à dire aux groupes Buddypress

Composant PHP réutilisable (Composer)

Une classe toute prête existe pour PHP; elle est disponible avec composer (déclarée sur packagist.org).

Utilisation :

Bon avec ça il y aura éventuellement des problèmes d'avertissements sur la stabilité, alors le mieux est de demander une version précise dans composer.json. Exemple :
ou
puis une fois le fichier mis à jour :

Et voili !

Exemples d'utilisation de ce composant :

• principe sommaire dans le README
• exemple d'agrégation du composant dans la classe de gestion de droits d'ezmlm-php

Sinon, un exemple moins propre de décodage / vérification de jeton en PHP sans ce composant se trouve dans GestionUtilisateur.php de la bibliothèque de services DeL (fonction getUtilisateurIdentifie() et celles qu'elle appelle).

---