Comment nous avons construit le proxy d'authentification Composer qui sert nos modules Magento

Chaque module eTechFlow s'installe via Composer à partir d'un dépôt privé sur repo.etechflow.com. Le dépôt est protégé par des identifiants par client qui correspondent à un droit de licence spécifique. Cet article présente l'ingénierie derrière cette protection : le proxy d'authentification, le cycle de vie des identifiants et les modes de défaillance que nous avons conçus.

Le problème que nous devions résoudre

Lorsqu'un client achète un module Magento chez nous, il doit faire deux choses pour l'installer. Tout d'abord, ajouter notre dépôt Composer à son composer.json. Ensuite, s'authentifier contre ce dépôt avec des identifiants qui fonctionnent pour lui et uniquement pour lui.

La plupart des fournisseurs de modules Magento résolvent cela avec des identifiants partagés par fournisseur (tout le monde qui achète chez Amasty utilise un ensemble d'identifiants Amasty) ou avec des identifiants basés sur l'email (votre email de compte et numéro de commande). Les deux présentent des problèmes. Les identifiants partagés ne peuvent pas être révoqués lorsqu'une licence est remboursée. Les identifiants par email fuient à travers des captures d'écran et des rapports de bogues.

Nous avions besoin d'identifiants qui soient par licence, révocables, rotatifs et audités.

L'architecture

Trois composants gèrent l'authentification à chaque installation.

Composant 1 : le proxy d'authentification. Un petit service Node devant le dépôt Composer réel. Chaque requête à repo.etechflow.com passe d'abord par le proxy. Le proxy lit les identifiants d'authentification de base HTTP à partir de la requête, les vérifie dans notre base de données de licences et décide s'il doit transmettre la requête.

Composant 2 : la base de données des licences. Stocke les identifiants associés à l'ID de licence. Chaque ligne contient l'ID du client, le slug du module acheté, la paire d'identifiants (nom d'utilisateur plus mot de passe haché bcrypt), la date d'émission, une éventuelle date d'expiration, le statut de révocation et l'horodatage de la dernière validation.

Composant 3 : le journal d'audit. Chaque tentative d'authentification (réussite ou échec) écrit une ligne avec l'adresse IP, l'horodatage, le package demandé et l'ID de licence correspondant. Le journal d'audit est interrogeable et constitue la base des alertes d'activité suspecte.

Le flux de requête complet sur un composer require etechflow/some-module :

1. Composer envoie une authentification de base HTTP au proxy d'authentification.
2. Le proxy vérifie la paire d'identifiants dans la base de données des licences.
3. Si valide et non révoqué, le proxy transmet la requête au registre Composer interne.
4. Le registre interne renvoie le package demandé.
5. Le proxy enregistre le succès et renvoie la réponse à Composer.

Latence totale supplémentaire : moins de 50 millisecondes par récupération de package. Une installation Composer typique récupère de 1 à 3 packages chez nous, donc le surcoût est invisible pour le client.

Le cycle de vie des identifiants

Un identifiant est généré au moment de l'achat du module. L'email du client reçoit la paire d'identifiants ainsi que les instructions d'installation immédiatement. Les identifiants sont liés à l'ID de licence, ce qui signifie qu'ils sont révoqués de manière atomique si le client demande un remboursement (fenêtre de remboursement de 30 jours).

Après 12 mois, nous expirons l'identifiant et envoyons un identifiant de renouvellement par email. L'ancien identifiant continue de fonctionner pendant 90 jours durant la période de transition afin que les clients puissent mettre à jour leur auth.json sans urgence.

Si un client soupçonne une fuite d'identifiants (commise dans un dépôt public, capturée dans un ticket de bogue), il peut faire une rotation depuis son tableau de bord de compte. La rotation révoque immédiatement l'ancien identifiant et en émet un nouveau.

Le mode de défaillance que nous avons conçu

Le plus grand risque avec cette architecture est l'indisponibilité du proxy d'authentification. Si repo.etechflow.com tombe en panne, chaque client qui essaie d'installer ou de mettre à jour un module échoue. Nous avons trois couches de protection :

Redondance géographique. Le proxy d'authentification fonctionne dans deux régions avec un routage actif-actif. Une panne régionale bascule en moins de 60 secondes.

Répliques de lecture de base de données. Les recherches d'identifiants se font contre des répliques de lecture avec un retard de réplication de 10 secondes. Les écritures (nouveaux identifiants, révocations) touchent le primaire. Les chemins en lecture seule survivent à un basculement primaire.

Dégradation gracieuse. Lorsque la base de données est complètement inaccessible, le proxy revient à un cache d'identifiants de 60 minutes qui conserve la dernière recherche réussie. Les clients qui installent pendant cette fenêtre réussissent toujours. Les nouveaux achats de modules sont suspendus jusqu'à ce que la base de données se rétablisse.

Le chemin de dégradation gracieuse a été déclenché trois fois depuis le lancement. Chaque fois, les clients ont signalé qu'il n'y avait pas de problèmes.

Ce que nous publions aux clients

Les clients voient l'architecture indirectement à travers trois surfaces.

L'extrait auth.json dans leur email d'achat leur indique exactement ce qu'ils doivent ajouter à leur boutique. Le format est une authentification de base HTTP standard dans la structure attendue par Composer, donc tout ingénieur familiarisé avec Composer peut le lire.

Le tableau de bord de compte leur montre tous leurs identifiants actifs, quand chacun a été émis, et un bouton de rotation en un clic. Nous ne montrons pas la valeur du mot de passe après sa création ; la rotation en génère un nouveau.

Le journal d'audit est par défaut interne uniquement. Les clients peuvent demander une exportation de leur propre activité d'identifiants pour des examens de sécurité.

Ce que nous ferions différemment

Deux choix de conception que nous revisiterions si nous devions recommencer.

Nous utiliserions des tokens d'authentification HTTP au lieu de l'authentification de base. Composer a pris en charge les tokens d'authentification depuis quelques années maintenant et ils sont plus propres à révoquer sans casser les attentes de l'installateur. Nous avons choisi l'authentification de base au début car elle fonctionne avec les anciennes versions de Composer ; les anciennes versions sont maintenant suffisamment rares pour que nous puissions avancer.

Nous envisagerions le flux de périphérique OAuth pour la première installation. Aujourd'hui, le client doit coller manuellement les identifiants dans auth.json ou exécuter une commande de configuration Composer. Le flux de périphérique OAuth permettrait que l'installation soit approuvée depuis la session de navigateur du client. Cela ajoute de l'infrastructure mais réduit la friction de la première installation.

Pourquoi cela compte pour l'écosystème Magento

La plupart des fournisseurs de modules Magento n'ont pas construit d'infrastructure d'identifiants appropriée. Le schéma courant (identifiants partagés, accès lié à l'email, pas de journal d'audit) crée de réelles lacunes en matière de sécurité. Lorsqu'une boutique Magento est compromise par un module tiers, la trace d'audit vers l'infrastructure de distribution du fournisseur est généralement vide car aucune infrastructure n'existait pour enregistrer.

Si vous évaluez des fournisseurs de modules Magento, demandez-leur comment fonctionne leur authentification Composer. La réponse révèle à quel point ils prennent au sérieux la sécurité de la chaîne d'approvisionnement.

Liens connexes

• Authentification Composer pour les dépôts Magento privés couvre la configuration côté client.
• Guide d'achat d'extensions Magento couvre les critères d'évaluation des fournisseurs.