API7 Enterprise v3.2.15 : Authentification multi-identifiants

Alors que les services API deviennent de plus en plus complexes, les méthodes traditionnelles de contrôle d'accès reposant uniquement sur les adresses IP ou les en-têtes de requête de base ne suffisent plus. API7 Enterprise introduit le concept de "Consumers", permettant aux développeurs de lier des consommateurs à des routes ou services API spécifiques avec les mêmes plugins d'authentification activés. Lorsqu'un consommateur effectue une requête, la passerelle API identifie le consommateur en fonction des informations d'identification fournies dans la requête et applique les politiques de contrôle d'accès correspondantes selon les relations de liaison.

API7 Enterprise v3.2.15 améliore les mécanismes d'authentification des consommateurs existants. Il optimise les interactions des plugins couramment utilisés, améliore le contrôle des permissions et prend en charge plusieurs informations d'identification par plugin. Cela permet une gestion et une rotation des informations d'identification plus flexibles.

Optimisation de l'interaction des plugins d'authentification des consommateurs

Vous pouvez facilement ajouter plusieurs informations d'identification dans un seul plugin d'authentification. La configuration a été améliorée, passant du codage à des opérations de formulaire intuitives, rendant le processus de configuration plus simple.

Actuellement, le consommateur prend en charge les quatre méthodes d'authentification suivantes avec plusieurs informations d'identification.

Authentification par clé

L'authentification par clé est une méthode basée sur une clé. Les consommateurs doivent inclure une clé unique dans leurs requêtes, qui peut être incluse dans les paramètres de la chaîne de requête ou les en-têtes HTTP. Lors de la configuration des requêtes, les consommateurs doivent s'assurer que la clé est correctement incluse dans les requêtes.

Dans la configuration de la route ou du service, le plugin Key Auth doit être activé avec les règles appropriées pour valider la clé dans la requête. La passerelle vérifie si la requête contient la clé attendue et si la clé correspond à la configuration. Si la validation de la clé réussit, la requête est autorisée à accéder au service backend ; si elle échoue, la requête est refusée.

Authentification de base

L'authentification de base est une méthode basée sur un nom d'utilisateur et un mot de passe. Les consommateurs doivent inclure des informations d'authentification contenant le nom d'utilisateur et le mot de passe dans la requête, généralement encodées dans l'en-tête Authorization de la requête HTTP, mais elles peuvent également être transmises via les paramètres de la chaîne de requête, bien que cela ne soit pas recommandé en raison de l'exposition potentielle d'informations sensibles. Les consommateurs doivent s'assurer que les informations d'authentification encodées sont correctement incluses lors de la configuration des requêtes.

Dans la configuration de la route ou du service, le plugin Basic Auth doit être activé avec les règles appropriées pour valider les informations d'authentification. La passerelle vérifie si la requête inclut l'en-tête Authorization et suit le format d'authentification de base. Le format est Basic <valeur-encodée>, où <valeur-encodée> est le résultat encodé en Base64 du nom d'utilisateur et du mot de passe séparés par deux points. La passerelle décode cette valeur et compare le nom d'utilisateur et le mot de passe décodés avec les informations configurées. S'ils correspondent, la requête est autorisée à accéder au service backend ; sinon, la requête est refusée.

Notez que l'authentification de base transmet le nom d'utilisateur et le mot de passe en texte clair, uniquement encodés en Base64 (non chiffrés), ce qui la rend inadaptée aux scénarios à haute sécurité.

Authentification JWT

L'authentification JWT est une méthode basée sur les JSON Web Tokens (JWT). Les consommateurs doivent inclure un jeton JWT valide dans leurs requêtes, généralement dans l'en-tête Authorization en utilisant le format Bearer <jeton>, mais il peut également être placé dans les paramètres de la chaîne de requête ou les cookies selon les besoins. Les consommateurs doivent s'assurer de la correction et de la validité du jeton JWT lors de la configuration des requêtes.

Lors de l'ajout d'informations d'identification JWT, vous pouvez configurer les éléments clés de la génération du jeton JWT, y compris la clé (publique ou privée) pour la signature et la vérification, le secret (clé pour le chiffrement symétrique), l'algorithme utilisé (par exemple, HMAC-SHA256 ou RSA-SHA256), et le délai d'expiration pour définir la période de validité du jeton. Seuls les consommateurs détenant des jetons valides et non expirés peuvent accéder avec succès aux services backend protégés.

Authentification HMAC

L'authentification HMAC est une méthode basée sur le code d'authentification de message basé sur le hachage (HMAC). Les consommateurs doivent générer une valeur HMAC pour la requête, généralement calculée à l'aide d'une clé pré-partagée et de parties spécifiques de la requête (par exemple, la méthode de requête, l'URI, le corps de la requête). Cette valeur HMAC peut être incluse dans les paramètres de la chaîne de requête ou les en-têtes HTTP.

Lors de la configuration des requêtes, les consommateurs doivent générer et inclure correctement la valeur HMAC selon l'algorithme et le format spécifiés. Plus précisément, les consommateurs utilisent une clé connue et les informations de la requête pour générer le HMAC à l'aide d'un algorithme de hachage (par exemple, SHA-256) et l'ajoutent à la requête.

Dans la configuration de la route ou du service, le plugin HMAC Auth doit être activé avec les règles appropriées pour valider la valeur HMAC dans la requête. La passerelle vérifie si la valeur HMAC est présente dans la requête et recalcule le HMAC en utilisant la même clé pré-partagée et le même algorithme pour vérifier sa validité. Si le HMAC recalculé correspond à la valeur dans la requête, la requête est autorisée à accéder au service backend.

Politiques de permissions granulaires pour les consommateurs

En plus d'optimiser la gestion des informations d'identification, nous avons affiné la gestion des permissions des consommateurs. Vous pouvez maintenant définir des permissions au niveau de chaque consommateur individuel, permettant un contrôle d'accès plus granulaire. Les permissions de lecture et d'écriture pour les informations d'identification d'authentification sont maintenant contrôlées indépendamment, séparément des permissions des consommateurs, offrant une plus grande flexibilité.

Résumé

La dernière version d'API7 Enterprise introduit des améliorations majeures dans l'authentification des consommateurs et la gestion des permissions. Elle optimise les interactions des plugins, permet une gestion indépendante des informations d'identification, prend en charge plusieurs méthodes d'authentification et affine les stratégies de permissions des consommateurs. Ces améliorations augmentent la flexibilité de la gestion des informations d'identification, la sécurité du système et l'expérience utilisateur globale.

Les futures mises à jour pourraient introduire des méthodes d'authentification supplémentaires et affiner davantage la gestion des informations d'identification, offrant des fonctionnalités plus innovantes et une meilleure expérience utilisateur.