Bug #26141
"race condition" sur la création d'un tenant puis la mise à dispo de la clé SAML
0%
Description
- on créé le tenant
- puis on ajoute les clés SAML dessus
Entre ces deux moments, si hobo ou Authentic vient chercher les métadonnées, celle ci ne contiennent pas encore la clé publique. Et comme mellon fait un cache, les métadonnées ne contiennent plus jamais la clé publique.
Selon le code de hobo_deploy, difficile de changer l'ordre des choses. En revanche, peut-être qu'on pourrait faire en sorte que mellon réponde 404 sur les metadonnées tant que la clé publique n'est pas générée ? (et oui, ça serait donc un ticket pour mellon dans ce cas, mais je pose la question ici quand même)
Demandes liées
Historique
Mis à jour par Thomas Noël il y a plus de 5 ans
note: expérience vécue par Emmanuel sur des déploiements via devinst, particulièrement depuis le passage à Django 1.11 qui joue les migrations bien plus rapidement.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Mmm, et simplement modifier le check_operational d'authentic, pour vérifier la disponibilité de metadata, plutôt que la réponse à /manage/users/ ?
Différemment, ajouter un --disabled à la commande create_tenant, qui poserait un marqueur quelconque dans le répertoire, pour laisser le temps au reste de l'hobo_deploy de s'exécuter puis retirer ce marqueur.
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Dupliqué par Bug #26142: Certificat manquant dans les métadonnés de mellon après un déploiement ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
Mmm, et simplement modifier le check_operational d'authentic, pour vérifier la disponibilité de metadata, plutôt que la réponse à /manage/users/ ?
Je relis mieux (avec l'aide de l'autre ticket), et c'est dans l'autre sens, métadonnées exposées par les applications.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Du coup, à mon sens, c'est tout à fait inutile de faire un cache de cette info et ça pourrait être dégagé de mellon.
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
Side note : pas réussi à confirmer l'hypothèse de Thomas (qui semble raisonnable), depuis qu'il m'a pointé cette possibilité, comme par hasard je n'arrive plus à reproduire, très pénible ce truc.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #26143: ne pas faire de cache des métadonnées locales ajouté
Mis à jour par Thomas Noël il y a plus de 5 ans
Emmanuel Cazenave a écrit :
Side note : pas réussi à confirmer l'hypothèse de Thomas (qui semble raisonnable), depuis qu'il m'a pointé cette possibilité, comme par hasard je n'arrive plus à reproduire, très pénible ce truc.
Race condition, plutôt difficile à reproduire, c'est sûr... Surtout qu'on est sur du cache par workers, donc en "vraie" prod, c'est plutôt rare.
Pour ma part, le cache dans le settings._TRUC fait par mellon, je l'aime pas beaucoup non plus, je serais pour le supprimer. Cependant mellon diffusera encore pendant quelques instants des metadonnées erronnées (sans clés publiques) et c'est pas top. Je me demande dans quel cadre un SP SAML peut avoir des metadata sans clé publique ? (auquel cas je préférerais que mellon réponde 404, quitte à avoir un "METADATA_WITHOUT_PUBLIC_KEY = True" possible dans les settings -- qu'on utilisera jamais nous)
Mis à jour par Emmanuel Cazenave il y a plus de 5 ans
- Statut changé de Nouveau à Fermé
Plus d'occurrence chez moi depuis #26143.
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
A défaut de gérer ça au niveau de mellon on pourrait modifier le check de validation de hobo pour qu'il pointe sur /mellon/metadata (ou qu'on ajoute cette URL à celles qui sont vérifiés en plus de la première URL de backoffice déclarée) et vérifier que ça contient bien une clé publique. Si je me souviens bien dès qu'un service devient opérationnel un message de déploiement est relancé (ou alors j'ai rêvé).