PDP distribué avec des PEP sur des API

Le modèle de point de décision stratégique (PDP) distribué avec points d'application des politiques (PEP) sur les API suit les meilleures pratiques du secteur pour créer un système efficace de contrôle d'accès et d'autorisation des API. Comme pour le modèle PDP centralisé avec des PEP sur des API, cette approche prend en charge les principes clés suivants :

• L'autorisation et le contrôle d'accès aux API sont appliqués à plusieurs points de l'application.

• La logique d'autorisation est indépendante de l'application.

• Les décisions relatives au contrôle d'accès sont centralisées.

Vous vous demandez peut-être pourquoi les décisions relatives au contrôle d'accès sont centralisées lorsque le PDP est distribué. Bien que le PDP puisse exister à plusieurs endroits dans une application, il doit utiliser la même logique d'autorisation pour prendre des décisions en matière de contrôle d'accès. Tous les PDP fournissent les mêmes décisions de contrôle d'accès avec les mêmes entrées. Les PEP sont implémentés dans toutes les API pour envoyer des demandes d'autorisation à un PDP.

Dans cette approche, les PDP sont implémentés à plusieurs endroits de l'application. Pour les composants d'application dotés de capacités de calcul intégrées capables d'exécuter l'OPA et de prendre en charge un PDP, tels qu'un service conteneurisé avec un sidecar ou une instance Amazon Elastic Compute Cloud (Amazon EC2), les décisions relatives au PDP peuvent être intégrées directement dans le composant d'application sans avoir à effectuer un appel d'API RESTful à un service PDP centralisé. Cela présente l'avantage de réduire la latence que vous pourriez rencontrer dans le modèle PDP centralisé, car tous les composants de l'application n'ont pas besoin d'effectuer des appels d'API supplémentaires pour obtenir des décisions d'autorisation. Toutefois, un PDP centralisé est toujours nécessaire dans ce modèle pour les composants d'application qui ne disposent pas de capacités de calcul intégrées permettant l'intégration directe d'un PDP, tels que les services Amazon ou Amazon API CloudFront Gateway. Le schéma suivant montre comment cette combinaison d'un PDP centralisé et d'un PDP distribué peut être mise en œuvre dans une application SaaS à locataires multiples hypothétique.

Flux d'applications :

	Un utilisateur authentifié avec un jeton JWT génère une requête HTTP à Amazon. CloudFront
	CloudFront transmet la demande à Amazon API Gateway configuré comme CloudFront origine.
	Un autorisateur Lambda API Gateway est appelé pour vérifier le jeton JWT.
	Les microservices répondent aux demandes.

Flux d'autorisation et de contrôle d'accès aux API :

	Le PEP appelle le service d'autorisation et transmet les données de demande, y compris les jetons JWT.
	Le service d'autorisation (PDP) prend les données de la demande et interroge une API REST de l'agent OPA exécutée sous forme de sidecar, les données de demande servant d'entrée à la requête.
	L'OPA évalue l'entrée en fonction des politiques pertinentes spécifiées par la requête. Les données sont importées pour prendre une décision d'autorisation si nécessaire.
	L'OPA renvoie une décision au service d'autorisation.
	La décision d'autorisation doit être renvoyée au PEP et évaluée.

Dans cette architecture, les PEP demandent des décisions d'autorisation aux points de terminaison des services pour CloudFront API Gateway et pour chaque microservice. La décision d'autorisation pour les microservices est prise par un service d'autorisation (le PDP) qui fonctionne comme un sidecar avec le composant d'application. Ce modèle est possible pour les microservices (ou services) qui s'exécutent sur des conteneurs ou des instances EC2. Les décisions d'autorisation pour des services tels que API Gateway CloudFront nécessiteraient toujours de contacter un service d'autorisation externe. Quoi qu'il en soit, le service d'autorisation expose une API disponible pour les PEP. Le fait que le service d'autorisation fasse office d'intermédiaire entre les PEP et l'OPA permet d'insérer toute logique de transformation entre les PEP et l'OPA qui pourrait être nécessaire, par exemple lorsque la demande d'autorisation d'un PEP n'est pas conforme à la requête saisie par l'OPA.

Vous pouvez également utiliser cette architecture avec des moteurs de politiques personnalisés. Cependant, tous les avantages obtenus grâce à l'OPA doivent être remplacés par une logique fournie par le moteur de politique personnalisé.

Un PDP distribué avec des PEP sur des API offre la possibilité de créer un système d'autorisation robuste pour les API. Il est simple à mettre en œuvre et fournit une interface easy-to-use idempotente pour prendre des décisions d'autorisation pour les API, les microservices, les couches Backend for Frontend (BFF) ou d'autres composants d'application. Cette approche présente également l'avantage de réduire la latence que vous pourriez rencontrer dans le modèle PDP centralisé.