Sécuriser les applications Web à l'aide d'OCI API Gateway et d'OpenID Connect
L'intégration d'applications Web héritées à des fournisseurs d'identités modernes nécessite généralement la modification du code d'application existant et la modification de l'interface utilisateur. Au lieu de consacrer du temps et des ressources à un nouveau développement personnalisé, investissez dans une architecture qui vous permet de vous concentrer sur la logique métier plutôt que sur le flux d'authentification.
Certaines applications héritées ne prennent pas directement en charge OpenID Connect. Au fur et à mesure de leur migration vers le cloud, vous pouvez utiliser Oracle Cloud Infrastructure (OCI) API Gateway en tant que point d'accès réseau pour servir de médiateur à l'authentification auprès des utilisateurs, du fournisseur d'identités et de l'application. Au lieu d'exiger que toutes les applications ajoutent directement les flux OpenID Connect, OCI API Gateway peut appliquer l'accès de manière standardisée sur le réseau. Les développeurs peuvent utiliser OCI API Gateway pour moderniser les applications héritées, tout en améliorant les applications modernes.
Architecture
OCI API Gateway est un service sans serveur entièrement géré dans OCI qui peut être utilisé pour protéger les adresses d'API et les applications Web. OCI API Gateway fournit des fonctionnalités de sécurité telles que la limitation du débit, l'application de l'autorisation, le routage dynamique, l'application SSL, etc. OCI API Gateway peut être utilisé pour sécuriser les applications Web héritées qui nécessitent la prise en charge de l'authentification OpenID. OCI API Gateway peut agir en tant que module de sécurité centralisé pour les applications Web hébergées dans des sous-réseaux privés OCI. OCI API Gateway fonctionne avec tous les fournisseurs d'identités et peut être intégré à n'importe quel fournisseur OAuth 2.0 pris en charge, tel qu'Okta, Google, Amazon et Auth0 pour n'en citer que quelques-uns.
Le protocole OpenID Connect est une couche d'identité simple située au-dessus du protocole OAuth 2.0. OpenID Connect permet à différents types d'applications, tels que les navigateurs, les applications mobiles et les clients de bureau, de prendre en charge l'authentification et la gestion des identités de manière sécurisée, centralisée et normalisée. Les applications s'appuyant sur le protocole OpenID Connect s'appuient sur des fournisseurs d'identités pour gérer en toute sécurité les processus d'authentification et vérifier les identités des utilisateurs. OpenID Connect permet l'accès avec connexion unique pour des applications disparates en centralisant la gestion des utilisateurs avec un fournisseur d'identités tel qu'Oracle Cloud Infrastructure Identity and Access Management.
OCI API Gateway fait office de point d'accès réseau pour la médiation de l'authentification auprès des utilisateurs, du fournisseur d'identités et de l'application. Le fait de placer OCI API Gateway entre les applications et les clients permet à OCI API Gateway d'intercepter les demandes et de gérer le flux d'autorisation OpenID Connect.
Le diagramme suivant illustre cette architecture de référence.
secure-web-applications-oci-api-gateway-open-id-architecture.zip
Le schéma suivant illustre le flux d'authentification pour l'autorisation initiale.
secure-web-applications-oci-api-gateway-open-id-data-flow.zip
- L'application client demande l'accès aux services back-end via OCI API Gateway.
- OCI API Gateway dirige le client vers le fournisseur d'identités.
- Le client s'authentifie auprès du fournisseur d'identités. Si l'authentification réussit, le client reçoit un jeton qui fournit l'autorisation.
- Le fournisseur d'identités redirige le client vers OCI API Gateway avec le jeton d'accès.
- OCI API Gateway valide le jeton d'accès avec le fournisseur d'identités.
- Si la validation du jeton aboutit, OCI API Gateway achemine le jeton vers le service back-end approprié et renvoie la réponse exécutée au client.
Lorsqu'un client est déjà autorisé, le flux ressemble au diagramme suivant.
secure-web-applications-oci-api-gateway-open-id-data-flow-authorized.zip
- Après avoir obtenu un jeton, les navigateurs mettent en cache des jetons pour les demandes ultérieures à la même application.
- OCI API Gateway valide le jeton avec le fournisseur d'identités pour garantir que le client a accès aux services back-end.
- Si le client est autorisé, OCI API Gateway effectue un routage vers le service back-end approprié et renvoie la réponse exécutée au client.
L'architecture se compose des éléments suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Ainsi, il est peu probable qu'un problème survenant dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Domaine de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources sur plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, de maintenance du système et d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- API Gateway
Oracle API Gateway vous permet de publier des API avec des adresses privées accessibles à partir de votre réseau, que vous pouvez exposer au réseau Internet public si nécessaire. Les adresses prennent en charge la validation d'API, la transformation des demandes et des réponses, la CORS, l'authentification et l'autorisation, ainsi que la limitation des demandes.
- Identity and Access Management (IAM)
Oracle Cloud Infrastructure Identity and Access Management (IAM) est le plan de contrôle d'accès pour Oracle Cloud Infrastructure (OCI) et Oracle Cloud Applications. L'API IAM et l'interface utilisateur vous permettent de gérer les domaines d'identité et les ressources au sein du domaine d'identité. Chaque domaine d'identité OCI IAM représente une solution de gestion des identités et des accès autonome ou une population d'utilisateurs différente.
- FastConnect
Oracle Cloud Infrastructure FastConnect permet de créer facilement une connexion privée dédiée entre le centre de données et Oracle Cloud Infrastructure. FastConnect offre des options de bande passante plus élevée et une expérience réseau plus fiable par rapport aux connexions Internet.
- OCI et Azure Interconnect
Oracle Cloud et Microsoft Azure Interconnect sont la première offre multicloud d'Oracle. Il fournit une connexion réseau directe entre des centres de données Azure et Oracle Cloud Infrastructure (OCI) spécifiques à travers le monde. Il permet aux administrateurs et aux développeurs Azure de connecter leurs applications aux applications et services exécutés dans OCI sans créer de liens dédiés ni envoyer leur trafic d'application sur l'Internet public.
Recommandations
- Passerelle d'API OCI
Vous pouvez tirer parti d'OCI API Gateway pour exposer les API REST et activer la prise en charge de l'accès avec connexion unique pour vos applications Web. OCI API Gateway peut également être désigné comme un module de sécurité centralisé permettant aux applications de décharger l'implémentation de sécurité vers OCI API Gateway. Cela limite les coûts liés à l'implémentation, à la maintenance et à la complexité.
Remarques
Tenez compte des points suivants lors du déploiement de cette architecture de référence.
- Protection CSRF (Cross-Site Request Forgery)
Un attaquant peut monter une attaque CSRF en exploitant l'existence d'un cookie de navigateur pour amener les utilisateurs à soumettre des commandes non souhaitées à une application Web, telle qu'une passerelle d'API OCI. Si l'application détermine que l'utilisateur a déjà été authentifié en raison de l'existence du cookie de navigateur, l'application exécute la commande avec des conséquences potentiellement dommageables.
Lorsque vous définissez une stratégie de validation de type
OAuth 2.0 introspection endpointet une stratégie d'échec de validation de typeOAuth 2.0, vous indiquez comment OCI API Gateway peut stocker un nouveau jeton JWT obtenu à l'aide du flux d'autorisation OpenID Connect.Sélectionnez
Use cookies for sessionsi vous souhaitez stocker de nouveaux jetons JWT dans un cookie de session. Pour empêcher les attaques CSRF potentielles, lorsqu'OCI API Gateway stocke le jeton dans un cookie de session, il renvoie également un jeton CSRF dans un en-tête de réponseX-CSRF-TOKEN. Les demandes suivantes adressées à OCI API Gateway (à l'exception des demandes GET) doivent inclure le jeton CSRF dans un en-tête de demandeX-CSRF-TOKEN, en plus du jeton JWT dans le cookie de session. - CORS (Cross-Origin Resource Sharing)
Les applications Web et les autres API REST utilisées dans l'application peuvent avoir besoin de prendre en charge CORS, car les demandes sont redirigées via OCI API Gateway à partir des navigateurs Web.