Appliquez un contrôle d'accès et un routage précis avec API Connectivity Manager

Une partie importante de la gestion des API tout au long de leur cycle de vie consiste à contrôler précisément l’accès aux API et le routage du trafic. Les jetons d’accès sont devenus la norme de facto pour la gestion de l’accès aux API. L’un des avantages des schémas d’authentification basés sur les jetons Web JSON (JWT) est de pouvoir exploiter les revendications du JWT pour mettre en œuvre ce niveau précis de contrôle d’accès. Les autorisations peuvent être codées sous forme de revendications personnalisées, que les propriétaires d'API peuvent utiliser pour contrôler l'accès à leurs API. Une fois que le proxy API a validé le JWT, il a accès à tous les champs du jeton en tant que variables et peut baser ses décisions d'accès sur eux.

Dans un article précédent , nous avons expliqué comment API Connectivity Manager peut aider les opérateurs et les développeurs à mieux travailler ensemble. Les équipes de différents secteurs d’activité qui possèdent et exploitent des API ont besoin d’un contrôle total lorsqu’elles développent et améliorent l’expérience de leurs API et services.

API Connectivity Manager fournit des stratégies qui permettent aux propriétaires d’API de configurer des paramètres de niveau de service tels que l’authentification API, l’autorisation et les exigences de sécurité supplémentaires. Dans cet article, nous montrons comment les propriétaires d'API peuvent utiliser la politique de routage de contrôle d'accès pour appliquer un contrôle précis pour des itinéraires spécifiques et l'affiner davantage pour l'appliquer par méthode HTTP et par itinéraire en fonction de revendications spécifiques dans le jeton.

Prérequis

Vous devez disposer d'un abonnement d'essai ou payant à F5 NGINX Management Suite , qui comprend Instance Manager et API Connectivity Manager ainsi que NGINX Plus comme passerelle API et NGINX App Protect pour sécuriser vos API. Pour commencer, demandez un essai gratuit de 30 jours de NGINX Management Suite .

Pour obtenir des instructions sur l'installation de NGINX Management Suite et API Connectivity Manager, consultez le Guide d'installation .

Accorder l'accès et acheminer le trafic vers un service spécifique

Disons que nous avons publié un proxy API d'entrepôt avec plusieurs points de terminaison tels que l'inventaire , les commandes , etc. Nous souhaitons désormais introduire un nouveau service appelé tarification , mais le rendre accessible uniquement à quelques clients qui se sont inscrits à un essai bêta. Ces clients sont identifiés par une revendication appelée betatester . Dans cet exemple de jeton d'accès, cette affirmation est vraie pour l'utilisateur identifié dans la sous -affirmation, user1@abc.com .

En-tête
{
"kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
Charge utile

{
"ver": 1,
"jti": "AT.xxxxxxxxxxxx",
"iss": "https://oauthserver/oauth2/",
"aud": "inventoryAPI",
"iat": 1670290877,
"exp": 1670294477,
"cid": "AcvfDzzzzzzzzzz",
"uid": "yyyyyyyWPXulqE4x6",
"scp": [
"apigw"
],
"auth_time": 1670286138,
"sub": "user1@abc.com",
"betatester": true,
"domain": "abc"
}

Pour l'utilisateur user2@abc.com , qui n'a pas été choisi pour le programme bêta, la réclamation du testeur bêta est définie sur
FAUX:

"sub": "user2@abc.com","betatester": false,

Nous configurons maintenant la stratégie de routage de contrôle d’accès ( access-control-routing ) pour accorder l’accès au service de tarification aux utilisateurs dont le JWT contient la revendication betatester avec la valeur true .

Par souci de concision, nous affichons uniquement la charge utile de la politique. Cette politique fonctionne uniquement avec les politiques basées sur des jetons dans API Connectivity Manager, telles que JWT Assertion et OAuth2 Introspection.

"policies": { "access-control-routing": [
{
"action": {
"conditions": [
{
"allowAccess": {
"uri": "/pricing"
},
"when": [
{
"key": "token.betatester",
"matchOneOf": {
"values": [
"true"
]
}
}
]
}
],
"returnCode": 403
}
}
]
}

Une fois la politique appliquée, le proxy API valide les revendications dans le JWT pour les utilisateurs authentifiés, en effectuant un contrôle d'accès précis pour acheminer les demandes de user1@abc.com et rejeter les demandes de user2@abc.com .

Contrôle de l'utilisation de méthodes spécifiques

Nous pouvons affiner davantage la politique de routage du contrôle d’accès pour contrôler quels utilisateurs peuvent utiliser des méthodes HTTP spécifiques. Dans cet exemple, le proxy API autorise uniquement les administrateurs (utilisateurs dont le jeton inclut la valeur Admin ) à utiliser la méthode DELETE .

"policies":{ "access-control-routing":[
"action":{
"conditions":[
{
"when":[
{
"key": "token.{claims}",
"matchOneOf":{
"values":[
"Admin"
]
}
}
],
"allowAccess":{
"uri": "/v1/customer",
"httpMethods":[
"DELETE"
]
},
"routeTo" : {
"targetBackendLabel" : ""
}
}
]
}
]
}

Routage basé sur l'en-tête

Une autre utilisation de la politique de routage de contrôle d’accès consiste à prendre des décisions de routage en fonction des valeurs d’en-tête dans les requêtes entrantes. Les propriétaires d’API peuvent configurer des règles ou des conditions qui spécifient les valeurs de l’en-tête qui doivent correspondre pour que la demande soit acheminée. Les requêtes sont transmises si elles contiennent l'en-tête et abandonnées si elles ne le contiennent pas.

Dans cet exemple, une demande est acheminée vers le point de terminaison /seasons uniquement lorsque l'en-tête de demande de version a la valeur v1 . La valeur returnCode spécifie le code d'erreur à renvoyer lorsque la version n'est pas v1 - dans ce cas, c'est403 (Interdit) .

"accès-contrôle-routage": [ {
"action": {
"conditions": [
{
"allowAccess": {
"uri": "/seasons"
},
"quand": [
{
"clé": "header.version",
"matchOneOf": {
"valeurs": [
"v1"
]
}
}
]
}
],
"code de retour": 403
}
}
]

Dans cet exemple de requête curl , nous envoyons une requête au service seasons avec l'en-tête de version défini sur v2 :

curl -H "version: v2" http://exemple.com/saisons

Étant donné que la valeur de l'en-tête de version n'est pas v1 comme l'exige la politique, le service renvoie le code d'état403 .

Inclure plusieurs règles dans la politique

Vous pouvez inclure plusieurs règles dans une politique de routage de contrôle d'accès pour contrôler le routage en fonction d'un, de deux ou des trois critères décrits dans cet article : Réclamations JWT, méthodes valides et valeurs d’en-tête de demande. Une demande doit correspondre aux conditions de toutes les règles pour être acheminée ; sinon, elle est bloquée.

Résumé

API Connectivity Manager permet aux propriétaires d’API de contrôler et d’améliorer l’expérience de leurs API et services avec des politiques au niveau de l’API qui appliquent un contrôle d’accès précis et prennent des décisions de routage dynamiques.

Pour démarrer avec API Connectivity Manager, demandez un essai gratuit de 30 jours de NGINX Management Suite .