Feingranulare Zugriffskontrolle und Routing mit API Connectivity Manager anwenden

Veena Raja Rathna

Ein wichtiger Aspekt bei der Verwaltung von APIs über ihren gesamten Lebenszyklus hinweg ist die präzise Steuerung des API-Zugriffs und der Weiterleitung des Datenverkehrs. Zugriffstoken haben sich als De-facto-Standard für die Verwaltung des Zugriffs auf APIs etabliert. Einer der Vorteile von Authentifizierungsschemata auf Basis von JSON Web Tokens (JWTs) besteht darin, die Claims im JWT nutzen zu können, um eine derart präzise Zugriffskontrolle zu implementieren. Berechtigungen können als benutzerdefinierte Claims codiert werden, anhand derer API-Eigentümer den Zugriff auf ihre APIs steuern können. Sobald der API-Proxy das JWT validiert hat, kann er auf alle Felder im Token als Variablen zugreifen und Zugriffsentscheidungen auf deren Grundlage treffen.

In einem früheren Beitrag haben wir erläutert, wie API Connectivity Manager Betreiber und Entwickler dabei unterstützen kann, besser zusammenzuarbeiten. Die Teams aus verschiedenen Geschäftsbereichen, die APIs besitzen und betreiben, benötigen umfassende Kontrolle, während sie ihre APIs und Dienste weiterentwickeln und deren Nutzungserlebnis verbessern.

API Connectivity Manager bietet Richtlinien, mit denen API-Verantwortliche Einstellungen auf Serviceebene wie API-Authentifizierung, Autorisierung und zusätzliche Sicherheitsanforderungen konfigurieren können. In diesem Beitrag zeigen wir, wie API-Verantwortliche die Richtlinie Access Control Routing verwenden können, um eine granulare Kontrolle für bestimmte Routen durchzusetzen und sie weiter so zu verfeinern, dass sie je nach HTTP-Methode und Route auf Grundlage bestimmter Claims im Token angewendet wird.

Voraussetzungen

Sie benötigen ein Test- oder kostenpflichtiges Abonnement für die F5 NGINX Management Suite, das Instance Manager und API Connectivity Manager sowie NGINX Plus als API-Gateway und NGINX App Protect zum Schutz Ihrer APIs umfasst. Fordern Sie zunächst eine kostenlose 30-Tage-Testversion der NGINX Management Suite an.

Anweisungen zur Installation der NGINX Management Suite und des API Connectivity Managers finden Sie im Installationshandbuch.

Zugriff gewähren und Datenverkehr an einen bestimmten Dienst weiterleiten

Nehmen wir an, wir haben einen Warehouse-API-Proxy mit mehreren Endpunkten wie inventory, orders usw. veröffentlicht. Nun möchten wir einen neuen Dienst namens pricing einführen, ihn aber nur einigen wenigen Clients zugänglich machen, die sich für einen Betatest angemeldet haben. Solche Clients werden durch einen Claim namens betatester identifiziert. In diesem Beispiel-Zugriffstoken ist dieser Claim für den im Claim sub identifizierten Benutzer user1@abc.com auf true gesetzt.

Header
{
  "kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
  "alg": "RS256"
}
Payload

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

Für user2@abc.com, der nicht für das Betaprogramm ausgewählt wurde, ist der Wert des Claims betatester auf
false gesetzt:

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

Nun konfigurieren wir die Access-Control-Routing-Richtlinie (access-control-routing), um Benutzern Zugriff auf den Dienst pricing zu gewähren, deren JWT den Claim betatester mit dem Wert true enthält.

Der Kürze halber zeigen wir nur die Policy-Nutzlast. Diese Policy funktioniert nur mit tokenbasierten Policies im API Connectivity Manager, wie etwa JWT Assertion und OAuth2 Introspection.

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

Sobald wir die Richtlinie anwenden, überprüft der API-Proxy die Claims im JWT für authentifizierte Benutzer und führt eine differenzierte Zugriffskontrolle durch, um Anfragen von user1@abc.com weiterzuleiten und Anfragen von user2@abc.com abzulehnen.

Steuern der Verwendung bestimmter Methoden

Wir können die Richtlinie für das Zugriffssteuerungs-Routing weiter optimieren, um festzulegen, welche Benutzer bestimmte HTTP-Methoden verwenden dürfen. In diesem Beispiel erlaubt der API-Proxy nur Administratoren (Benutzern, deren Token den Wert „Admin“ enthält), die Methode „DELETE“ zu verwenden.

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

Headerbasierte Weiterleitung

Eine weitere Anwendung der Richtlinie „access-control-routing“ besteht darin, Routing-Entscheidungen anhand der Header-Werte eingehender Anfragen zu treffen. API-Verantwortliche können Regeln oder Bedingungen konfigurieren, die festlegen, welche Werte im Header übereinstimmen müssen, damit die Anfrage weitergeleitet wird. Anfragen werden weitergeleitet, wenn sie den Header enthalten, und andernfalls verworfen.

In diesem Beispiel wird eine Anfrage nur dann an den Endpunkt /seasons weitergeleitet, wenn der Anfrage-Header version den Wert v1 hat. Der Wert returnCode gibt den Fehlercode an, der zurückgegeben wird, wenn version nicht v1 ist – in diesem Fall 403 (Verboten).

"access-control-routing": [  {
    "action": {
      "conditions": [
        {
          "allowAccess": {
            "uri": "/seasons"
          },
          "when": [
            {
              "key": "header.version",
              "matchOneOf": {
                "values": [
                  "v1"
                ]
              }
            }
          ]
        }
      ],
      "returnCode": 403
    }
  }
]

In dieser Beispiel-curl-Anfrage senden wir eine Anfrage an den Dienst seasons und setzen dabei den Header version auf v2:

curl -H "version: v2" http://example.com/seasons

Da der Wert des version-Headers nicht wie von der Richtlinie vorgeschrieben v1 lautet, gibt der Dienst den Statuscode 403 zurück.

Mehrere Regeln in die Richtlinie aufnehmen

Sie können mehrere Regeln in eine Zugriffssteuerungs-Routing-Richtlinie aufnehmen, um das Routing anhand eines, zweier oder aller drei in diesem Beitrag erläuterten Kriterien zu steuern: JWT-Claims, zulässige Methoden und Werte von Anfrage-Headern. Eine Anfrage wird nur weitergeleitet, wenn sie die Bedingungen aller Regeln erfüllt. Andernfalls wird sie blockiert.

Zusammenfassung

Mit API Connectivity Manager können API-Verantwortliche die Nutzung ihrer APIs und Dienste mithilfe von Richtlinien auf API-Ebene steuern und optimieren. Diese ermöglichen eine differenzierte Zugriffskontrolle und dynamische Routing-Entscheidungen.

Fordern Sie für den Einstieg in API Connectivity Manager eine kostenlose 30-Tage-Testversion der NGINX Management Suite an.

Über den Autor

Veena Raja Rathna

Weitere Blogbeiträge von Veena Raja Rathna