Cloud-native API Gateway s'intègre au système d'authentification de votre entreprise via le protocole OpenID Connect (OIDC), offrant une authentification et une autorisation centralisées pour les services internes. Cette approche élimine la nécessité d'intégrations répétitives service par service, permet la mise en place d'une connexion unique (SSO) et prend en charge une configuration flexible des politiques de sécurité.
Prérequis
Vous disposez d'un serveur d'autorisation unifié compatible avec le protocole standard OIDC.
Informations générales
En tant que point d'entrée pour l'accès externe aux services internes, la passerelle API authentifie et autorise les requêtes entrantes afin de protéger les services backend. Cloud-native API Gateway s'intègre à votre système d'authentification autonome via le protocole OIDC, permettant une authentification unifiée pour tous les services connectés sans nécessiter d'intégration individuelle.
Authentification OIDC
OIDC est un protocole d'authentification qui permet aux applications tierces de vérifier l'identité des utilisateurs finaux par l'intermédiaire d'un fournisseur d'identité. S'appuyant sur OAuth 2.0, OIDC ajoute un ID Token : un JSON Web Token (JWT) autonome et infalsifiable contenant les informations d'identité de base de l'utilisateur, qui peut être transmis de manière sécurisée et vérifié par les applications tierces.
Un flux OIDC typique implique les quatre rôles suivants :
client : Une application qui fournit des services directement à l'utilisateur final.
authorization server : Un fournisseur OpenID qui émet des ID Tokens à destination des applications tierces pour l'authentification.
business server : Un serveur qui fournit des services métier.
end user : Le propriétaire de la ressource qui accorde l'accès à ses informations.
Le processus se déroule comme suit :
Le client envoie une demande d'authentification au serveur d'autorisation.
L'utilisateur final accorde l'autorisation sur la page d'authentification, généralement en se connectant avec un nom d'utilisateur et un mot de passe.
Le serveur d'autorisation valide la demande d'authentification et renvoie un code d'autorisation au client.
Le client envoie une requête à un endpoint de rappel sur le business server, en incluant le code d'autorisation.
Le business server demande un token au serveur d'autorisation. La requête inclut le code d'autorisation, le client ID et le client secret.
Le serveur d'autorisation valide la requête et renvoie un ID Token.
Une fois l'authentification réussie, le business server renvoie l'ID Token au client.
Le client effectue une requête métier incluant l'ID Token.
Le business server valide l'ID Token et renvoie une réponse métier.
Flux d'authentification OIDC de la passerelle
Dans le flux OIDC décrit précédemment, chaque business server (tel qu'un service utilisateur ou un service de commande) doit implémenter sa propre logique d'authentification et s'intégrer au serveur d'autorisation. Cloud-native API Gateway centralise cette fonctionnalité au niveau de la passerelle, éliminant ainsi le besoin de code d'authentification spécifique à chaque service.
Le processus se déroule comme suit :
Le client envoie une demande d'authentification à la passerelle.
La passerelle envoie une demande d'authentification au serveur d'autorisation.
Le serveur d'autorisation renvoie un code à la passerelle.
La passerelle renvoie le code au client.
Le client envoie une requête de rappel avec le code à la passerelle.
La passerelle échange le code contre un token auprès du serveur d'autorisation.
Le serveur d'autorisation renvoie un ID Token à la passerelle.
La passerelle renvoie une réponse de réussite d'authentification au client et définit un cookie.
Le client initie une requête métier portant le cookie, et la passerelle vérifie le token.
La passerelle transfère la requête métier portant l'ID Token vers le service métier.
La réponse du business server est renvoyée au client via la passerelle.
Au cours de ce processus, Cloud-native API Gateway valide chaque requête. Les requêtes invalides déclenchent une redirection vers la page de connexion, où la passerelle agit en tant que proxy du serveur d'autorisation pour gérer l'authentification. Cela rend le serveur d'autorisation transparent pour les business servers backend.
Créer une règle d'authentification et d'autorisation
Connectez-vous à la console API Gateway.
Dans le volet de navigation de gauche, cliquez sur . Dans la barre de navigation supérieure, sélectionnez une région.
Sur la page Instance, cliquez sur le nom de l'instance de passerelle cible.
Dans le volet de navigation de gauche, choisissez .
-
Dans le coin supérieur gauche de la page, cliquez sur Create Authentication. Configurez les paramètres d'authentification de la passerelle et cliquez sur OK.
Le tableau suivant décrit les paramètres de l'authentification OIDC.
Paramètre
Description
Enable
Indique si l'authentification doit être activée pour l'instance Cloud-native API Gateway.
Authentication Name
Le nom personnalisé de la règle d'authentification.
Authentication Type
Sélectionnez OIDC.
Domain Name
Le nom de domaine auquel s'applique la règle d'authentification.
Issuer
L'URL de l'émetteur du serveur d'autorisation.
Redirect URL
L'URL vers laquelle l'utilisateur final est redirigé après une autorisation réussie. Cette URL doit correspondre à celle configurée dans votre fournisseur d'identité OIDC.
ImportantL'URL doit être au format
http(s)://yourdomain/pathet le chemin doit être/oauth2/callback.Client ID
Le client ID de votre application enregistré auprès du fournisseur d'identité.
Client secret
Le client secret de votre application enregistré auprès du fournisseur d'identité.
Cookie domain
Le domaine du cookie de session. Une fois l'utilisateur final authentifié, le cookie est envoyé à ce domaine pour maintenir la session de connexion. Par exemple, si vous définissez le domaine du cookie sur
a.example.com, le cookie est envoyé au domainea.example.com. Si vous définissez le domaine du cookie sur.example.com, le cookie est envoyé à tous les sous-domaines deexample.com.Cookie secret
Un secret utilisé pour signer numériquement le cookie de session afin d'empêcher toute falsification.
Scope
Spécifiez les étendues d'autorisation. Vous pouvez ajouter plusieurs étendues, séparées par des points-virgules (;).
Authorization
Sélectionnez le mode d'autorisation. Vous pouvez choisir soit Whitelist Mode, soit Blacklist Mode.
whitelist : Les requêtes adressées aux hôtes et chemins figurant dans la liste d'autorisation peuvent contourner l'authentification. Toutes les autres requêtes la requièrent.
blacklist : Seules les requêtes adressées aux hôtes et chemins figurant dans la liste de blocage requièrent une authentification. Toutes les autres requêtes peuvent passer sans authentification.
Cliquez sur Rule Condition pour définir les noms de domaine et les chemins de requête.
Domain Name : L'hôte de la requête.
Path : Le chemin de l'API de la requête.
Détails de l'authentification et de l'autorisation
Connectez-vous à la console API Gateway.
Dans le volet de navigation de gauche, cliquez sur . Dans la barre de navigation supérieure, sélectionnez une région.
Sur la page Instance, cliquez sur le nom de l'instance de passerelle cible.
Dans le volet de navigation de gauche, choisissez .
-
Sur la page Global Authentication, cliquez sur le nom d'une règle d'authentification, ou cliquez sur Description dans la colonne Actions. Vous pouvez consulter la Authentication Configuration actuelle et les Authorization Information.
La page de détails contient trois sections. Basic Information affiche le nom et la source. Authentication Configuration affiche des champs tels que issuer, client ID, Cookie domain, redirect URL, client secret et scope. Authorization Information affiche le mode d'autorisation actuel (liste d'autorisation ou liste de blocage). Plusieurs conditions de règle ont une relation OU, tandis que plusieurs éléments de correspondance au sein d'une seule condition de règle ont une relation ET.
Dans la section Authorization Information, vous pouvez cliquer sur Create Authorization. Dans la boîte de dialogue qui s'affiche, saisissez un Request Domain Name et un Request Path, sélectionnez un Match Mode, puis cliquez sur OK pour ajouter une nouvelle règle d'autorisation.
Vérifier le résultat
Revenez à la page Global Authentication. Si la règle que vous avez créée apparaît dans la liste, cela signifie qu'elle a été créée avec succès.
Opérations connexes
Vous pouvez également gérer les règles d'authentification de la passerelle comme suit :
Activer une règle d'authentification : Sur la page Global Authentication, recherchez la règle d'authentification cible et cliquez sur Enable dans la colonne Actions.
Désactiver une règle d'authentification : Sur la page Global Authentication, recherchez la règle d'authentification cible et cliquez sur Close dans la colonne Actions.
Modifier une règle d'authentification : Sur la page Global Authentication, recherchez la règle d'authentification cible et cliquez sur Edit dans la colonne Actions.
Supprimer une règle d'authentification : Sur la page Global Authentication, recherchez la règle d'authentification cible et cliquez sur Delete dans la colonne Actions.
Vous devez désactiver une règle d'authentification avant de pouvoir la supprimer.
Documentation connexe
Pour en savoir plus sur d'autres mécanismes d'authentification, consultez Authentification globale.