Ce guide explique comment configurer un SSO SAML entre HelloID et Amazon Connect, un processus qui ne se fait pas directement dans Amazon Connect mais via AWS IAM et l'IdP. L'idée principale est que l'authentification est gérée par HelloID (source de vérité), tandis qu'Amazon Connect se contente d'autoriser les utilisateurs déjà authentifiés via un flux IdP-initiated. L'instance Amazon Connect doit être créée en mode SAML dès le départ, car ce paramètre est irréversible.

La configuration implique trois étapes clés : déclarer HelloID comme fournisseur d'identité dans IAM, créer un rôle de fédération avec les droits nécessaires (notamment connect:GetFederationToken), et configurer une application SAML dans HelloID en utilisant des attributs spécifiques (comme Role et RoleSessionName) pour éviter les erreurs de mapping. Deux pièges majeurs sont à éviter : l'absence du certificat de signature dans les métadonnées SAML de HelloID et l'utilisation d'un mapping SAML générique qui nettoie les caractères spéciaux nécessaires aux noms d'attributs AWS.

Enfin, le rôle créé dans IAM doit être configuré pour autoriser l'assomption de rôle via SAML avec une audience spécifique, et l'application HelloID doit être correctement paramétrée pour émettre les attributs requis par AWS. Une fois ces étapes validées, les utilisateurs peuvent accéder à Amazon Connect via HelloID sans saisie de credentials supplémentaires.

L’auteur présente son projet de tablette tactile pour gérer les tâches ménagères en remplacement de l’application payante Sweepy, qu’il juge trop gamifiée. Il souligne que Sweepy repose sur des pièces de la maison, des tâches avec une difficulté (points), un cycle de répétition et un système de suivi pour plusieurs utilisateurs, mais que ces fonctionnalités pourraient être reproduites avec un logiciel libre auto-hébergé. L’article se concentre sur une réflexion autour de la solution technique plutôt que sur un guide de déploiement, tout en mettant en avant les besoins concrets identifiés (multi-utilisateurs, organisation par pièces, cycles de tâches).

L'article propose une approche simplifiée du CQRS (Command Query Responsibility Segregation) en séparant clairement les opérations d'écriture (modification de données) et de lecture (récupération de données) au sein d'un service Node.js, sans recourir à des architectures complexes comme l'event sourcing ou des bases de données distinctes. L'idée centrale est de scinder un service monolithique en deux parties distinctes : une dédiée aux commandes (écritures) et une autre aux requêtes (lectures), afin d'éviter les conflits de responsabilités et d'améliorer la maintenabilité.

L'auteur illustre ce concept avec un exemple concret, comme un OrderService qui mélange des méthodes de gestion des commandes (validation, règles métier) et des méthodes de récupération de données (requêtes, transformations pour l'interface utilisateur). Cette séparation permet de faire évoluer indépendamment les deux parties en fonction des besoins changeants de l'application, réduisant ainsi la complexité et les risques d'erreurs. L'approche reste légère et applicable rapidement dans un projet existant.