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 normalerweise Sitzungscookies, um den Benutzerkontext zu verfolgen. Moderne und verteilte Anwendungen erschweren die Aufrechterhaltung von Benutzersitzungen über Microservices hinweg. 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 Tokens von einer vertrauenswürdigen Entität namens Authorization Server, um die Benutzeridentität und den Zugriff nachzuweisen. Diese Clients präsentieren das Token dann der Anwendung 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, diesen Datenverkehr zu handhaben. NetScaler kann als API-Gateway für das Frontend des gesamten Datenverkehrs bereitgestellt werden, der für die veröffentlichten Dienste bestimmt ist. 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 Verkehr, um verschiedene Dienste wie Authentifizierung, Autorisierung, Ratenbegrenzung, Routing, Caching, SSL-Offload, Anwendungsfirewall usw. anzubieten. Daher wird es zu einer kritischen Komponente 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 den “delegierten Zugriff” verwendet werden, entsprechen dem OAuth-Protokoll, wohingegen ID-Token, die dem 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 sowohl für die OAuth- als auch für die OIDC-Protokolle verwendet werden. 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 mit dem OIDC-Protokoll an Identity Provider weitergeleitet. Native Clients können Tokens außerhalb des Bandes abrufen und diese Token an einer NetScaler-Appliance für den Zugriff vorlegen.
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. Er ist mit einem virtuellen Authentifizierungsserver (Authentifizierung, Autorisierung und Überwachung) verknüpft, der die Authentifizierungs- und Sitzungsrichtlinien enthält. 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. Innerhalb einer OAuth-Aktion gibt es je nach Tokentyp und anderen Sicherheitsmechanismen 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 wurde.
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 führt die Clientkonfiguration mit dieser ID ab. Maximale Länge: 127.
-
Client Secret — Geheime Zeichenfolge, die vom Benutzer und Autorisierungsserver festgelegt wurde. 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 auswählen, um Token zu signieren.
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 ‘certEndPointPoint’ für die Validierung des ID-Tokens 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 JWKs-Spezifikation (Json Web Keys) entsprechen.
Sobald der CertEndPoint auf der NetScaler Appliance konfiguriert ist, fragt er den Endpunkt 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 die eingehenden ID-Token lokal validieren.
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 überprüfen. 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 erstellt werden, um es aufzurufen.
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 beinhaltet Überprüfungen der Token-Lebensdauer. Token, die außerhalb der akzeptablen Zeit liegen, 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 Muster verweist, das auf der Appliance festgelegt ist. Mit diesem Mustersatz 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 oAuthAccess 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 hat sich bewährt, den Emittenten der Tokens 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, wäre das Token von (aktuelle Zeit - 10) min bis (aktuelle Zeit + 10) min gültig, das sind insgesamt 20 Minuten. Standardwert: 5
AllowedAlgorithms: Mit dieser Option kann der Administrator bestimmte Algorithmen in den eingehenden Tokens einschrä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.
Umgehung bestimmter Daten bei der Authentifizierung
In vielen Fällen gibt es einige Discovery-APIs, die für die Clients öffentlich zugänglich sind. Diese APIs enthüllen in der Regel die Konfiguration und Funktionen des Dienstes selbst. Ein Administrator kann die NetScaler Appliance so konfigurieren, dass die Authentifizierung über diese Metadaten-URLs mithilfe der folgenden Richtlinie “Keine Authentifizierung” Bypass 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 übereinstimmt. Es gibt andere Verwendungen der NO_AUTHN Aktion über den Bereich des API-Zugriffs hinaus.
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
- Umgehung bestimmter Daten bei der Authentifizierung