Modèles de conception pour OPA

Utilisation d'un PDP centralisé avec activé PEPs APIs

Le point de décision stratégique (PDP) centralisé avec points d'application des politiques (PEPs) sur le APIs modèle suit les meilleures pratiques du secteur afin de créer un système efficace et facile à entretenir pour le contrôle d'accès et l'autorisation des API. Cette approche repose sur plusieurs principes clés :

• 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.

Ce modèle utilise un PDP centralisé pour prendre les décisions d'autorisation. PEPs sont mis en œuvre APIs pour faire des demandes d'autorisation au PDP. Le schéma suivant montre comment implémenter ce modèle dans une application SaaS à locataires multiples hypothétique.

Flux de candidature (illustré par des légendes numérotées en bleu dans le schéma) :

1. Un utilisateur authentifié avec un JWT génère une requête HTTP à Amazon. CloudFront

2. CloudFront transmet la demande à Amazon API Gateway, qui est configuré comme CloudFront origine.

3. Un autorisateur personnalisé API Gateway est appelé pour vérifier le JWT.

4. Les microservices répondent à la demande.

Flux d'autorisation et de contrôle d'accès aux API (illustré par des légendes numérotées en rouge dans le schéma) :

1. Le PEP appelle le service d'autorisation et transmet les données de demande, y compris les JWTs données.

2. Le service d'autorisation (PDP) prend les données de la demande et interroge une API REST de l'agent OPA, qui fonctionne comme un sidecar. Les données de la demande servent d'entrée à la requête.

3. 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.

4. L'OPA renvoie une décision au service d'autorisation.

5. La décision d'autorisation est renvoyée au PEP et évaluée.

Dans cette architecture, PEPs demandez des décisions d'autorisation aux points de terminaison des services pour Amazon CloudFront et Amazon API Gateway, ainsi que pour chaque microservice. La décision d'autorisation est prise par un service d'autorisation (le PDP) avec un sidecar OPA. Vous pouvez utiliser ce service d'autorisation en tant que conteneur ou en tant qu'instance de serveur traditionnelle. Le sidecar OPA expose son RESTful API localement afin que l'API ne soit accessible qu'au service d'autorisation. Le service d'autorisation expose une API distincte qui est disponible pour PEPs. Le fait que le service d'autorisation joue le rôle d'intermédiaire entre PEPs un OPA permet d'insérer toute logique de transformation entre PEPs un OPA qui peut ê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 centralisé PEPs activé APIs permet de créer facilement un système d'autorisation robuste pour APIs. Il est simple à mettre en œuvre et fournit également une easy-to-use interface reproductible pour prendre des décisions d'autorisation pour les microservices APIs, les couches Backend for Frontend (BFF) ou d'autres composants de l'application. Cependant, cette approche peut créer trop de latence dans votre application, car les décisions d'autorisation nécessitent l'appel d'une API distincte. Si la latence du réseau pose problème, vous pouvez envisager un PDP distribué.

Utilisation d'un PDP distribué avec PEPs on APIs

Le APIs modèle de point de décision stratégique distribué (PDP) avec points d'application des politiques (PEPs) suit les meilleures pratiques du secteur afin de créer un système efficace de contrôle d'accès et d'autorisation des API. Comme dans le cas du PDP centralisé avec un APIs modèle, cette approche repose PEPs sur 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 de contrôle d'accès. Tous PDPs fournissent les mêmes décisions de contrôle d'accès avec les mêmes entrées. PEPs sont mis en œuvre APIs pour faire des demandes d'autorisation au PDP. La figure suivante montre comment ce modèle distribué peut être implémenté dans une application SaaS hypothétique à locataires multiples.

Dans cette approche, PDPs 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 ( EC2Amazon), les décisions PDP peuvent être intégrées directement dans le composant d'application sans qu'il soit nécessaire de passer 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 le service 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 de candidature (illustré par des légendes numérotées en bleu dans le schéma) :

1. Un utilisateur authentifié avec un JWT génère une requête HTTP à Amazon. CloudFront

2. CloudFront transmet la demande à Amazon API Gateway, qui est configuré comme CloudFront origine.

3. Un autorisateur personnalisé API Gateway est appelé pour vérifier le JWT.

4. Les microservices répondent à la demande.

Flux d'autorisation et de contrôle d'accès aux API (illustré par des légendes numérotées en rouge dans le schéma) :

1. Le PEP appelle le service d'autorisation et transmet les données de demande, y compris les JWTs données.

2. Le service d'autorisation (PDP) prend les données de la demande et interroge une API REST de l'agent OPA, qui fonctionne comme un sidecar. Les données de la demande servent d'entrée à la requête.

3. 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.

4. L'OPA renvoie une décision au service d'autorisation.

5. La décision d'autorisation est renvoyée au PEP et évaluée.

Dans cette architecture, PEPs demandez des décisions d'autorisation aux points de terminaison du service 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 Amazon Elastic Compute Cloud (Amazon 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 accessible à PEPs. Le fait que le service d'autorisation joue le rôle d'intermédiaire entre PEPs un OPA permet d'insérer toute logique de transformation entre PEPs un 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é PEPs activé APIs permet de créer un système d'autorisation robuste pour APIs. Il est simple à mettre en œuvre et fournit une easy-to-use interface reproductible pour prendre des décisions d'autorisation pour les microservices APIs, 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é.

Utilisation d'un PDP distribué en tant que bibliothèque

Vous pouvez également demander des décisions d'autorisation à un PDP mis à disposition sous forme de bibliothèque ou de package à utiliser dans une application. L'OPA peut être utilisée comme bibliothèque tierce Go. Pour les autres langages de programmation, l'adoption de ce modèle signifie généralement que vous devez créer un moteur de politique personnalisé.