Projet

Général

Profil

Tâche #10149

Scénario #10147: Instabilité du service en cas d'authentifications OTP concurrentes

Plantages du service liées à l'authentification OTP

Ajouté par Bruno Boiget il y a environ 9 ans. Mis à jour il y a environ 9 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
15/12/2014
Echéance:
% réalisé:

100%

Temps estimé:
8.00 h
Temps passé:
Restant à faire (heures):
0.0

Description

L'académie de Besançon a remonté des problèmes d'instabilité du service SSO sur leur serveur Seshat.

Des problèmes équivalents semblent également survenir dans une moindre mesure à la Réunion (Christophe a mis en place une surveillance régulière du service pour le relancer en cas d'arrêt).

message de Sylvain Dubuisson après étude du problème:

Bonjour,

Voici les dernieres nouvelles de mes recherches sur les pb OTP avec seshat (eole-sso) de Besançon.
Le problème ne peut clairement pas être résolu simplement chez nous. Il est necessaire de repenser la manière dont l'authentification OTP est faite par eole-sso pour que l'application puisse supporter des charges importantes.

J'ai ajouté avant et après pam.authenticate() un log.msg pour voir le nombre d'authentification et le temps qu'elles prennent.
Nous sommes à 2 à 3 secondes pour une authentification OTP.
Nous sommes à 140-160 demandes d'authentification OTP par heure sur les périodes où nous subissons les segfault/plantage.
Dès arret du serveur, nous perdons les tickets de session dans le serveur eole-sso ce qui provoque une vague de nouvelle ré-authentification donc un nouveau segfault de l'application.
Nous sommes à plus de 100 connexions OTP par heure sur le serveur en journée de notre coté. (en cette période, nous avons des enseignants qui utilisent Sconet Notes en passant par notre portail d'authentification unique)

Le segfault se fait systématiquement dans le module pam_securid.so. Ce module n'est chargé qu'une seule fois en mémoire par le module pam de python qui est lui même présente une seule fois en mémoire. (c'est par conception que çà se passe comme çà)
La librairie pam_securid.so ne supporte pas deux appels concurrents. Lors du deuxième appel, un segfault se produit au moment de la tentative de nettoyage de la mémoire par la librairie.
Apparemment le module supporte d'être chargé plusieurs fois en mémoire et exécuté plusieurs fois en parallèle mais je n'ai pas de moyen de le tester.

J'ai tenté d'utiliser le module threading.Lock() de Python pour gérer/réguler les accès concurrents et n'est obtenu comme résultat que des désynchronisations de clé OTP lié au temps de déblocage du verrou.

Les solutions possibles après cette analyse sont de mon point de vue :
- L'utilisation des fonctions avancées de Python/Twisted pour limiter à un appel à la fois sur pam
- La séparation dans un processus séparer de l'authentification OTP pour éviter la propagation au cache des tickets de eole-sso
- La mise en place d'un multichargement en python de la librairie pam_securid.so pour permettre les demandes simultanées
Ceci nécessite de toute façon de forte compétence en Python, programmation multithreadé et gestion des accès concurrents et compréhension des mécanismes d'appel de fonction.

C'est aujourd'hui un probleme important dans notre académie qui a mis en place ce portail uniquement qui ne supporte pas une charge importante sur l'authentification OTP.


Demandes liées

Copié depuis EoleSSO - Tâche #9924: Plantages du service liées à l'authentification OTP Reporté 15/12/2014

Révisions associées

Révision 8d4a0348 (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

Réécriture de la gestion des appels PAM/OTP

  • L'appel PAM est lancé par securid_check dans un processus séparé
  • Le service eole-sso se charge de contrôler les entrées/sorties du script
    et de le terminer si besoin
  • le mode 'next token' devrait pouvoir fonctionner à nouveau
  • le module de threading n'est plus utilisé, le contrôle du processus
    est géré uniquement via des callbacks de la boucle principal
  • correction du stockage des identificants personnalisables (annuaire local)

Fixes #10149 @3h

Révision ce53b641 (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

Correction d'une exception dans un log en cas de segfault de securid_check

  • en cas de segfault (tester avec kill -11), le code de retour est None

ref #10149 @15m

Révision 38823a79 (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

Correction d'une possibilité de purge en double du Checker OTP (timeout)

ref #10149

Révision 63c7826a (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

Ajout d'un paramêtre manquant à la fonction de conversation PAM/OTP

  • le paramêtre user_data a été oublié dans securid_check

ref #10149 @30m

Révision 3ffbebcd (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

Correction du cas ou le nom d'utilisateur/le mot de passe ont des accents

  • spawnProcess n'accepte pas d'unicode dans les arguments du processus
  • encodage du mot de passe

ref #10149 @45m

Révision 8a5dc454 (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

securid_check : Correction d'un libellé incohérent avec celui attendu

ref #10149 @45m

Révision 43187514 (diff)
Ajouté par Bruno Boiget il y a environ 9 ans

securid_utils : correction d'une typo (gestion des identifiants configurables)

ref #10149 @15m

Historique

#1 Mis à jour par Joël Cuissinat il y a environ 9 ans

  • Statut changé de En cours à Nouveau
  • Temps estimé changé de 2.00 h à 8.00 h
  • Restant à faire (heures) changé de 4.0 à 8.0

#2 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Statut changé de Nouveau à En cours
  • % réalisé changé de 0 à 80

#3 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Statut changé de En cours à Résolu
  • % réalisé changé de 80 à 100

#4 Mis à jour par Bruno Boiget il y a environ 9 ans

paquets de Dev compilé (2.3-eole107~7) :

eole-sso
eole-sso-client
python-eoleldaptor

Le mode next token (gestion des clés désynchronisées) devrait pouvoir fonctionner à nouveau.
Pour le tester, passer l'option REDIRECT_DESYNC à False dans /usr/share/sso/config.py et relancer le service eole-sso

#5 Mis à jour par Bruno Boiget il y a environ 9 ans

En attente de tests de Besançon et la Réunion.

Une maquette est en cours de montage avec le serveur OTP de Dijon.

#6 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Statut changé de Résolu à En cours

remonté par Sylvain : En cas d'accents dans le nom de l'utilisateur, la commande spawnProcess renvoie une erreur sur le type des arguments

Jan 13 14:11:23 seshat-test eolesso: [TLSProtocolWrapper,54,172.30.33.5] ./securid_utils.py:171: exceptions.DeprecationWarning: Argument strings and environment keys/values passed to reactor.spawnProcess should be str, not unicode.

#7 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Statut changé de En cours à Résolu

problème d'encodage corrigés.

En attente de confirmation de Besançon. D'après les derniers échanges, il semble que des problèmes de fonctionnement liés à la configuration de l'utilisateur 'reader' (LDAP) empêche d'aller au bout de la procédure d'authentification (recherche de l'utilisateur impossible après validation de l'authentification OTP).

#8 Mis à jour par Joël Cuissinat il y a environ 9 ans

  • Restant à faire (heures) changé de 8.0 à 1.0

#9 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Restant à faire (heures) changé de 1.0 à 0.5

Les dernières corrections ont été installées sur un serveur de test à Besançon et semblent corriger les problèmes rencontrés.

Il reste à surveiller le comportement sur un serveur de production. Selon les résultats, on pourra envisager de développer un système limitant le nombre d'authentifications OTP simultanées.

#10 Mis à jour par Bruno Boiget il y a environ 9 ans

  • Statut changé de Résolu à Fermé
  • Restant à faire (heures) changé de 0.5 à 0.0

Le paquet de Dev actuel est en test sur le serveur Seshat de Besançon.

Christophe Léon devrait également faire des tests dans les jours qui viennent

Formats disponibles : Atom PDF