API-Authentifizierung mit der NetScaler Appliance
Es gibt einen Paradigmenwechsel in der Art und Weise, wie moderne Anwendungen mit ihren Kunden interagieren. Traditionell wurden Browserclients für den Zugriff auf Dienste verwendet. Anwendungen setzen Sitzungscookies, um den Benutzerkontext zu verfolgen. Moderne und verteilte Anwendungen machen es schwierig, Benutzersitzungen über Microservices hinweg aufrechtzuerhalten. Aus diesem Grund sind die meisten Anwendungszugriffe API-basiert geworden. Die Clients, die mit diesen verteilten Diensten kommunizieren, haben sich ebenfalls weiterentwickelt. Die meisten Clients erhalten Token von einer vertrauenswürdigen Entität namens Authorization Server, um Benutzeridentität und Zugriff nachzuweisen. Diese Clients präsentieren der Anwendung dann das Token bei jeder Zugriffsanforderung. Daher müssen herkömmliche Proxygeräte wie NetScaler weiterentwickelt werden, um diese Clients zu unterstützen. Eine NetScaler Appliance bietet Administratoren die Möglichkeit, solchen Datenverkehr zu handhaben. NetScaler kann als API-Gateway bereitgestellt werden, um den gesamten Datenverkehr, der für die veröffentlichten Dienste bestimmt ist, als Frontend bereitzustellen. Ein API-Gateway kann für traditionelle (Hybrid Multi Cloud oder HMC) oder Cloud-native Umgebungen eingesetzt werden. Das API-Gateway beendet den gesamten eingehenden Datenverkehr, um verschiedene Dienste wie Authentifizierung, Autorisierung, Ratenbegrenzung, Routing, Caching, SSL-Offload, Anwendungsfirewall usw. anzubieten. Daher wird es zu einer kritischen Komponente in der Infrastruktur.
Token-Typen
Tokens, die während des API-Zugriffs ausgetauscht werden, entsprechen größtenteils dem OAuth/OpenID Connect (OIDC) -Protokoll. Zugriffstoken, die nur für “delegierten Zugriff” verwendet werden, entsprechen dem OAuth-Protokoll, während ID-Token, die OIDC entsprechen, ebenfalls Benutzerinformationen enthalten. Zugriffstoken sind normalerweise ein undurchsichtiger oder zufälliger Datenblock. Manchmal können sie jedoch signierte Token sein, die den JWT-Standards (JSON Web Token) entsprechen. ID-Token sind immer signierte JWTs.
API-Zugriff mit OAuth
Der OAuth-Authentifizierungstyp auf einer NetScaler Appliance kann verwendet werden, um sowohl OAuth- als auch OIDC-Protokolle zu verarbeiten. OIDC ist eine Erweiterung des OAuth-Protokolls.
OAuthAction auf einer NetScaler Appliance kann verwendet werden, um interaktive Clients wie Browser und native Clients wie Client-Apps zu verwalten. Interaktive Clients werden zur Anmeldung über das OIDC-Protokoll an den Identity Provider umgeleitet. Systemeigene Clients können Tokens aus dem Band beziehen und diese Token auf einer NetScaler Appliance für den Zugriff präsentieren.
Hinweis:
Das von Endpunkten erhaltene Zugriffstoken kann für nachfolgende Anfragen zwischengespeichert werden, wodurch die API-Leistung verbessert wird.
Um die Unterstützung von Token-Caching mithilfe der Befehlszeilenschnittstelle zu konfigurieren, geben Sie an der Befehlszeile den folgenden Befehl ein:
set aaaparameter -APITokenCache <ENABLED>
<!--NeedCopy-->
In den folgenden Abschnitten wird die API-Zugriffsmethode beschrieben, die von nativen Clients ausgeführt wird.
Virtueller Server für API-Zugriff
Um eine NetScaler-Appliance für einen API-Zugriff bereitzustellen, wird ein virtueller Traffic Management (TM) -Server mit 401-Authentifizierung bereitgestellt. Es ist einem virtuellen Authentifizierungsserver (Authentifizierung, Autorisierung und Prüfung) zugeordnet, auf dem die Authentifizierungs- und Sitzungsrichtlinien gespeichert werden. Der folgende Konfigurationsausschnitt erstellt einen solchen virtuellen Server.
Add lb vserver lb-api-access SSL <IP> 443 -authn401 On -AuthnVsName auth-api-access
Bind ssl vserver lb-api-access -certkeyName <ssl-cert-entity>
Add authentication vserver auth-api-access SSL
<!--NeedCopy-->
Hinweis:
Sie müssten einen Dienst an den virtuellen Server für die Verkehrsverwaltung und eine Authentifizierungsrichtlinie (mit OAuthAction wie folgt beschrieben) an den virtuellen Authentifizierungsserver binden, um die Konfiguration abzuschließen.
Nach dem Erstellen des virtuellen Servers muss eine OAuthAction zusammen mit der entsprechenden Richtlinie hinzugefügt werden. Je nach Tokentyp und anderen Sicherheitsmechanismen gibt es innerhalb einer OAuth-Aktion mehrere andere Optionen.
OAuth-Konfiguration für ID-Token
ID-Token sind immer signierte JWTs. Das heißt, sie tragen Header, Payload und Signatur. Da es sich um eigenständige Token handelt, kann eine NetScaler-Appliance diese Token lokal validieren. Um diese Token zu validieren, müsste die Appliance den öffentlichen Schlüssel des entsprechenden privaten Schlüssels kennen, der zum Signieren dieser Token verwendet wird.
Es folgt ein Beispiel für OAuthAction mit bestimmten obligatorischen Argumenten zusammen mit “certEndpoint”.
Add authentication OAuthAction oauth-api-access -clientid <your-client-id> -clientsecret <your-client-secret> -authorizationEndpoint <URL to which users would be redirected for login> -tokenEndpoint <endpoint at which tokens could be obtained> -certEndpoint <URL at which public keys of IdP are published>
<!--NeedCopy-->
Hierbei gilt:
-
Client-ID — Eindeutige Zeichenfolge, die SP identifiziert. Der Autorisierungsserver leitet die Clientkonfiguration von dieser ID ab. Maximale Länge: 127.
-
Client Secret: Geheime Zeichenfolge, die vom Benutzer und Autorisierungsserver erstellt wird. Maximale Länge: 239.
-
AuthorizationEndpoint — URL, unter der sich Benutzer normalerweise anmelden würden (bei Verwendung interaktiver Clients).
-
TokenEndpoint - URL auf dem Autorisierungsserver, an dem Token/Code abgerufen/ausgetauscht werden
-
CertEndPoint — URL, unter der der Autorisierungsserver öffentliche Schlüssel veröffentlicht, die zum Signieren der Token verwendet werden. Der Autorisierungsserver kann mehr als einen Schlüssel veröffentlichen und einen davon zum Signieren von Tokens auswählen.
Hinweis:
Client-ID/Client Secret/AuthorizationEndpoint/TokenEndpoint sind optionale Parameter für den API-Zugriff. Es empfiehlt sich jedoch, Werte für diese Parameter anzugeben, da die Aktionsentität für verschiedene Zwecke wiederverwendet werden kann.
In der vorherigen Konfiguration ist ‘certEndpoint’ für die ID-Token-Validierung unerlässlich. Dieser Endpunkt enthält öffentliche Schlüssel des Zertifikats, das zum Signieren der Token verwendet wurde. Diese öffentlichen Schlüssel müssen der JWK-Spezifikation (JSON Web Keys) entsprechen.
Sobald der CertEndpoint auf der NetScaler Appliance konfiguriert ist, fragt er den Endpoint regelmäßig ab (mit dem Standardintervall von 1 Tag, das in der Konfiguration angepasst werden kann), um die öffentlichen Schlüssel auf dem neuesten Stand zu halten. Nachdem die öffentlichen Schlüssel verfügbar sind, kann ADC eine lokale Validierung der eingehenden ID-Token durchführen.
OAuth-Konfiguration für undurchsichtige Zugriffstoken
Undurchsichtige Token können nicht lokal auf der NetScaler Appliance verifiziert werden. Diese müssen auf dem Autorisierungsserver validiert werden. Eine NetScaler Appliance verwendet das in den OAuth-Spezifikationen erwähnte „Introspection Protocol“, um diese Token zu verifizieren. In der OAuth-Konfiguration steht eine neue Option, introspecturL, zur Überprüfung undurchsichtiger Token zur Verfügung.
set oauthAction oauth-api-acccess -introspectURL <URL of the Authorization Server for introspection>
<!--NeedCopy-->
Das Format der Introspection-API entspricht der Spezifikation unter https://tools.ietf.org/html/rfc7662#section-2.1 wie folgt:
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=mF_9.B5f-4.1JqM&token_type_hint=access_token
<!--NeedCopy-->
Bindungsrichtlinie an den virtuellen Authentifizierungsserver
Sobald OAuthAction erstellt wurde, muss eine entsprechende Richtlinie für den Aufruf erstellt werden.
add authentication policy oauth-api-access -rule <> -action <oauth-api-access>
bind authentication vserver auth-api-access -policy oauth-api-access -pri 100
<!--NeedCopy-->
Zusätzliche Sicherheitseinstellungen auf einer NetScaler Appliance
Die Token-Validierung umfasst Überprüfungen der Token-Lebensdauer. Tokens außerhalb der akzeptablen Zeit werden abgelehnt. Im Folgenden finden Sie die zusätzlichen Einstellungen für zusätzliche Sicherheit. Es wird empfohlen, einige davon immer zu konfigurieren.
Zielgruppe: OAuth Action kann mit einem vorgesehenen Empfänger des Tokens konfiguriert werden. Alle Token werden mit dieser konfigurierten URL abgeglichen. Eine NetScaler-Appliance verfügt über eine zusätzliche Funktion, bei der das Zielgruppenfeld tatsächlich auf ein auf der Appliance festgelegtes Muster verweist. Mithilfe dieses Mustersatzes kann ein Administrator mehr als eine URL für die Zielgruppe konfigurieren.
add policy patset oauth_audiences
bind patset oauth_audiences https://app1.company.com
bind patset oauth_audiences https://app2.company.com
bind patset oauth_audiences httpsL//app1.company.com/path1
set oAuthAction oauth-api-access -audience oauth_audiences
<!--NeedCopy-->
Im vorherigen Beispiel wurde mehr als eine Zielgruppe in einem Mustersatz angegeben. Daher ist ein eingehendes Token nur zulässig, wenn es eine der konfigurierten URLs im Mustersatz enthält.
Aussteller: Identität des Servers, dessen Tokens akzeptiert werden sollen. Maximale Länge: 127. Es empfiehlt sich, den Aussteller der Token in der OAuth-Aktion zu konfigurieren. Dadurch wird sichergestellt, dass vom falschen Autorisierungsserver ausgegebene Token nicht zulässig sind.
SkewTime: Gibt den zulässigen Taktversatz in der Anzahl der Minuten an, den eine NetScaler Appliance für ein eingehendes Token zulässt. Wenn SkewTime beispielsweise 10 ist, dann wäre das Token von (aktuelle Zeit — 10) Minuten bis (aktuelle Zeit + 10) Minuten gültig, also insgesamt 20 Minuten. Standardwert: 5
allowedAlgorithms: Diese Option ermöglicht es dem Administrator, bestimmte Algorithmen in den eingehenden Token einzuschränken. Standardmäßig sind alle unterstützten Methoden zulässig. Diese können jedoch mit dieser Option gesteuert werden.
Die folgende Konfiguration stellt sicher, dass nur Token zulässig sind, die RS256 und RS512 verwenden:
set oAuthAction oauth-api-access -allowedAlgorithms RS256 RS512
<!--NeedCopy-->
Nachdem die obige Konfiguration durchgeführt wurde, sind nur Token zulässig, die RS256 und RS512 verwenden.
Umgehen von bestimmtem Datenverkehr bei der Authentifizierung
In vielen Fällen gibt es einige Discovery-APIs, auf die die Clients öffentlich zugreifen können. Diese APIs enthüllen in der Regel die Konfiguration und die Funktionen des Dienstes selbst. Ein Administrator kann die NetScaler Appliance so konfigurieren, dass die Authentifizierung über diese Metadaten-URLs mithilfe der Richtlinie „Keine Authentifizierung“ Bypass wird, die wie folgt beschrieben wird:
add authentication policy auth-bypass-policy -rule <> -action NO_AUTHN
bind authentication vserver auth-api-access -policy auth-bypass-policy -pri 110
<!--NeedCopy-->
NO_AUTHN ist eine implizite Aktion, die dazu führt, dass die Authentifizierung abgeschlossen wird, wenn die Regel zutrifft. Es gibt andere Verwendungsmöglichkeiten der NO_AUTHN-Aktion, die über den API-Zugriff hinausgehen.
In diesem Artikel
- Token-Typen
- API-Zugriff mit OAuth
- Virtueller Server für API-Zugriff
- OAuth-Konfiguration für ID-Token
- OAuth-Konfiguration für undurchsichtige Zugriffstoken
- Bindungsrichtlinie an den virtuellen Authentifizierungsserver
- Zusätzliche Sicherheitseinstellungen auf einer NetScaler Appliance
- Umgehen von bestimmtem Datenverkehr bei der Authentifizierung