Wenden Sie mit dem API Connectivity Manager eine feinkörnige Zugriffskontrolle und Weiterleitung an

Ein wichtiger Teil der Verwaltung von APIs über ihren gesamten Lebenszyklus hinweg ist eine detaillierte Kontrolle des API-Zugriffs und der Verkehrsweiterleitung. Zugriffstoken haben sich zum De-facto-Standard für die Verwaltung des Zugriffs auf APIs entwickelt. Einer der Vorteile von Authentifizierungsschemata auf Basis von JSON Web Tokens (JWTs) besteht darin, dass die Ansprüche im JWT genutzt werden können, um dieses feine Maß an Zugriffskontrolle zu implementieren. Berechtigungen können als benutzerdefinierte Ansprüche codiert werden, mit denen API-Besitzer den Zugriff auf ihre APIs steuern können. Sobald der API-Proxy das JWT validiert hat, hat er Zugriff auf alle Felder im Token als Variablen und kann seine Zugriffsentscheidungen darauf basieren.

In einem früheren Beitrag haben wir besprochen, wie API Connectivity Manager Betreibern und Entwicklern helfen kann, besser zusammenzuarbeiten. Die Teams aus verschiedenen Geschäftsbereichen, die APIs besitzen und betreiben, benötigen die volle Kontrolle bei der Entwicklung und Verbesserung der Benutzerfreundlichkeit ihrer APIs und Dienste.

API Connectivity Manager bietet Richtlinien, mit denen API-Besitzer Einstellungen auf Serviceebene wie API-Authentifizierung, Autorisierung und zusätzliche Sicherheitsanforderungen konfigurieren können. In diesem Beitrag zeigen wir, wie API-Besitzer die Access Control Routing- Richtlinie verwenden können, um eine fein abgestufte Kontrolle für bestimmte Routen zu erzwingen und sie weiter zu optimieren, sodass sie basierend auf bestimmten Ansprüchen im Token pro HTTP-Methode und pro Route angewendet wird.

Voraussetzungen

Sie müssen über eine Testversion oder ein kostenpflichtiges Abonnement der F5 NGINX Management Suite verfügen, die Instance Manager und API Connectivity Manager sowie NGINX Plus als API-Gateway und NGINX App Protect zum Sichern Ihrer APIs umfasst. Fordern Sie zum Einstieg eine kostenlose 30-Tage-Testversion der NGINX Management Suite an.

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

Gewähren des Zugriffs und Weiterleiten des Datenverkehrs an einen bestimmten Dienst

Nehmen wir an, wir haben einen Lager-API-Proxy mit mehreren Endpunkten wie Inventar , Bestellungen usw. veröffentlicht. Jetzt möchten wir einen neuen Service namens „Preisgestaltung“ einführen, ihn aber nur einigen Kunden zugänglich machen, die sich für einen Betatest angemeldet haben. Solche Clients werden durch einen Anspruch namens „Betatester“ identifiziert. In diesem Beispiel-Zugriffstoken gilt dieser Anspruch für den im Unteranspruch identifizierten Benutzer user1@abc.com .

Überschrift
{
"Kind": „123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx“,
„alg“: "RS256"
}
Nutzlast

{
"ver": 1,
"jti": „AT.xxxxxxxxxxxx“,
„iss“: „https://oauthserver/oauth2/“,
„aud“: „inventoryAPI“,
„iat“: 1670290877,
"Ausdruck": 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, wird der Betatesteranspruch auf
FALSCH:

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

Jetzt konfigurieren wir die Access Control Routing-Richtlinie ( access-control-routing ), um Benutzern Zugriff auf den Preisdienst zu gewähren, deren JWT den Anspruch „betatester“ mit dem Wert „true“ enthält.

Der Kürze halber zeigen wir nur die Richtliniennutzlast. Diese Richtlinie funktioniert nur mit tokenbasierten Richtlinien im API Connectivity Manager, wie etwa JWT Assertion und OAuth2 Introspection.

"Richtlinien": { "Zugriffskontrollrouting": [
{
"Aktion": {
"Bedingungen": [
{
"Zugriff zulassen": {
"URI": "/Preise"
},
"Wann": [
{
"Schlüssel": "Token.Betatester",
"MatchOneOf": {
"Werte": [
"Wahr"
]
}
}
]
}
],
"Rückgabecode": 403
}
}
]
}

Sobald wir die Richtlinie anwenden, validiert der API-Proxy die Ansprüche im JWT für authentifizierte Benutzer und führt eine feinkörnige Zugriffskontrolle durch, um Anfragen von user1@abc.com weiterzuleiten und Anfragen von user2@abc.com abzulehnen.

Kontrollierter Einsatz bestimmter Methoden

Wir können die Zugriffskontroll-Routing- Richtlinie weiter optimieren, um zu steuern, welche Benutzer bestimmte HTTP-Methoden verwenden können. In diesem Beispiel erlaubt der API-Proxy nur Administratoren (Benutzern, deren Token den Wert Admin enthält), die DELETE -Methode zu verwenden.

"Richtlinien":{ "Zugriffskontrollrouting":[
"Aktion":{
"Bedingungen":[
{
"Wann":[
{
"Schlüssel":"Token.{Ansprüche}",
"MatchOneOf":{
"Werte":[
"Admin"
]
}
}
],
"Zugriff zulassen":{
"URI":"/v1/Kunde",
"httpMethods":[
"LÖSCHEN"
]
},
"Route zu" : {
"Ziel-Backend-Label" : ""
}
}
]
}
]
}

Header-basiertes Routing

Eine weitere Verwendung der Access-Control-Routing- Richtlinie besteht darin, Routing-Entscheidungen auf Grundlage von Header-Werten in eingehenden Anfragen zu treffen. API-Besitzer können Regeln oder Bedingungen konfigurieren, die die Werte im Header angeben, die übereinstimmen müssen, damit die Anforderung weitergeleitet wird. Anfragen werden weitergeleitet, wenn sie den Header enthalten, und gelöscht, wenn dies nicht der Fall ist.

In diesem Beispiel wird eine Anforderung nur dann an den Endpunkt /seasons weitergeleitet, wenn der Versionsanforderungsheader den Wert v1 hat. Der Wert returnCode gibt den Fehlercode an, der zurückgegeben werden soll, wenn die Version nicht v1 ist – in diesem Fall ist es403 (Verboten) .

"access-control-routing": [ {
"Aktion": {
"Bedingungen": [
{
"Zugriff zulassen": {
"uri": "/seasons"
},
"wann": [
{
"Schlüssel": "header.version",
"matchOneOf": {
"Werte": [
"v1"
]
}
}
]
}
],
"Rückgabecode": 403
}
}
]

In dieser Beispiel- Curl -Anfrage senden wir eine Anfrage an den Seasons -Dienst mit dem Versionsheader v2 :

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

Da der Wert des Versionsheaders nicht v1 ist, wie von der Richtlinie gefordert, gibt der Dienst den Statuscode403 .

Einschließen mehrerer Regeln in die Richtlinie

Sie können in eine Access-Control-Routing- Richtlinie mehrere Regeln aufnehmen, um das Routing basierend auf einem, zwei oder allen drei der in diesem Beitrag besprochenen Kriterien zu steuern: JWT-Ansprüche, gültige Methoden und Anforderungsheaderwerte. Damit eine Anfrage weitergeleitet werden kann, muss sie die Bedingungen aller Regeln erfüllen. Andernfalls wird sie blockiert.

Zusammenfassung

Mit dem API Connectivity Manager können API-Besitzer die Erfahrung ihrer APIs und Dienste mit Richtlinien auf API-Ebene steuern und verbessern, die eine fein abgestufte Zugriffskontrolle anwenden und dynamische Routing-Entscheidungen treffen.

Um mit API Connectivity Manager zu beginnen, fordern Sie eine kostenlose 30-Tage-Testversion der NGINX Management Suite an.