In Authentifizierung, Autorisierung und Auditing des Anwendungsdatenverkehrs
In Citrix ADC 13.0
In Citrix ADC
In All products
Produktdokumentation
In Authentifizierung, Autorisierung und Auditing des Anwendungsdatenverkehrs
In Citrix ADC 13.0
In Citrix ADC
In All products
Citrix ADC
Current Release 12.1 11.1
PDF anzeigen

API-Authentifizierung mit der Citrix ADC Appliance

January 19, 2021
Beigesteuert von: 
C

Es gibt einen Paradigmenwechsel in der Art und Weise, wie moderne Anwendungen mit ihren Kunden interagieren. Traditionell wurden Browser-Clients verwendet, um auf Dienste zuzugreifen. Anwendungen setzen in der Regel Session-Cookies, um den Benutzerkontext zu verfolgen. Moderne und verteilte Anwendungen machen es schwierig, Benutzersitzungen über Microservices hinweg zu verwalten. Aus diesem Grund sind die meisten Anwendungszugriffe API-basiert. Kunden, die mit diesen verteilten Diensten kommunizieren, haben sich ebenfalls weiterentwickelt. Die meisten Clients erhalten Token von einer vertrauenswürdigen Entität namens Autorisierungsserver, um die Benutzeridentität und den Zugriff zu beweisen. Diese Clients präsentieren dann das Token der Anwendung mit jeder Zugriffsanforderung. Daher müssen herkömmliche Proxy-Geräte wie Citrix ADC weiterentwickelt werden, um diese Clients zu unterstützen. Eine Citrix ADC Appliance bietet Administratoren die Möglichkeit, solchen Datenverkehr zu verarbeiten. Citrix ADC kann als API-Gateway bereitgestellt werden, um den gesamten Datenverkehr, der für die veröffentlichten Dienste bestimmt ist, zu Front-End zu ermöglichen. Ein API Gateway kann für herkömmliche (Hybrid Multi Cloud oder HMC) oder Cloud-native Umgebungen bereitgestellt werden. Das API Gateway beendet den gesamten eingehenden Datenverkehr, um mehrere Dienste wie Authentifizierung, Autorisierung, Ratenbegrenzung, Routing, Caching, SSL-Offload, Anwendungsfirewall usw. anzubieten. Daher wird es zu einer kritischen Komponente in der Infrastruktur.

Token-Typen

Token, 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 Datenblöcke. Sie können jedoch manchmal Sing-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 Citrix ADC Appliance kann verwendet werden, um sowohl OAuth- als auch OIDC-Protokolle zu verarbeiten. OIDC ist eine Erweiterung des OAuth-Protokolls.

OAuthAction auf einer Citrix ADC Appliance kann verwendet werden, um interaktive Clients wie Browser und native Clients wie Clientanwendungen zu verarbeiten. Interaktive Clients werden zum Identity Provider für die Anmeldung mithilfe des OIDC-Protokolls umgeleitet. Native Clients können Token Out-of-Band-Abrufen und diese Token auf einer Citrix ADC Appliance für den Zugriff bereitstellen.

Hinweis:

Das von Endpunkten erhaltene Zugriffstoken kann für nachfolgende Anforderungen zwischengespeichert werden, wodurch die API-Performance verbessert wird.

Um die Token-Caching-Unterstützung über die Befehlszeile zu konfigurieren, geben Sie den folgenden Befehl an der Eingabeaufforderung ein:


set aaaparameter –apITokenCache <ENABLED>

In den folgenden Abschnitten wird die API-Zugriffsmethode beschrieben, die von nativen Clients ausgeführt wird.

Virtueller Server für API-Zugriff

Um eine Citrix ADC 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, um die Authentifizierungs- und Sitzungsrichtlinien zu speichern. Nach Konfiguration Snippet 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

Hinweis:

Sie müssten einen Dienst an den TM-vserver 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. Es gibt mehrere andere Optionen innerhalb einer OAuth-Aktion, abhängig vom Tokentyp und anderen Sicherheitsmechanismen.

OAuth-Konfiguration für ID-Tokens

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 Citrix ADC 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 <uri at which public keys of IdP are published>

Hierbei gilt:

  • Client-ID — Eindeutige Zeichenfolge, die SP identifiziert. Der Autorisierungsserver leitet die Clientkonfiguration mit dieser ID ab. Maximale Länge: 127.

  • Client Secret — Geheime Zeichenfolge, die vom Benutzer und Autorisierungsserver eingerichtet wurde. Maximale Länge: 239.

  • authorizationEndpoint - URL, unter der sich Benutzer normalerweise anmelden würden (bei Verwendung interaktiver Clients).

  • tokenEndpoint - URL auf dem Autorisierungsserver, auf dem Token/Code erhalten/ausgetauscht werden

  • certEndpoint - URL, unter der der Autorisierungsserver öffentliche Schlüssel veröffentlicht, die zum Signieren der Token verwendet werden. Autorisierungsserver kann mehr als einen Schlüssel veröffentlichen und einen von ihnen auswählen, um Token zu signieren.

Hinweis: Client ID/Client Secret/authorizationEndpoint/TokenEndpoint sind optionale Parameter für API-Zugriff. Es ist jedoch empfehlenswert, Werte für diese Parameter bereitzustellen, da die Aktions-Entität für verschiedene Zwecke wiederverwendet werden kann.

In der vorhergehenden Konfiguration ist ‘CertEndPointPoint’ für die ID-Token-Validierung unerlässlich. Dieser Endpunkt enthält öffentliche Schlüssel des Zertifikats, das zum Signieren der Token verwendet wird. Diese öffentlichen Schlüssel müssen der JWKs (Json Web Keys) Spezifikation entsprechen.

Sobald der CertEndPoint auf der Citrix ADC Appliance konfiguriert ist, wird der Endpunkt regelmäßig abgefragt (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 Citrix ADC Appliance überprüft werden. Diese müssen auf dem Autorisierungsserver validiert werden. Eine Citrix ADC Appliance verwendet das in den OAuth-Spezifikationen genannte Introspektionsprotokoll, um diese Token zu überprüfen. Eine neue Option, IntroSpectURL, wird in der OAuth-Konfiguration zur Überprüfung undurchsichtiger Token bereitgestellt.


set oauthAction oauth-api-acccess -introspectURL <uri of the Authorization Server for introspection>

Das Format der Introspektion-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

Bindungsrichtlinie an Authentifizierungs-vserver

Sobald OAuthAction erstellt wurde, muss die entsprechende Richtlinie erstellt werden, um sie aufzurufen.


add authentication policy oauth-api-access -rule <> -action <oauth-api-access>```

bind authentication vserver auth-api-access -policy oauth-api-access -pri 100

Zusätzliche Sicherheitseinstellungen auf einer Citrix ADC Appliance

Die Token-Validierung umfasst Token Lebensdauerprüfungen. Tokens außerhalb der akzeptablen Zeit werden abgelehnt. Im Folgenden finden Sie die zusätzlichen Einstellungen für zusätzliche Sicherheit. Einige von diesen wird empfohlen, immer konfiguriert zu werden.

Zielgruppe: OAuth-Aktion kann mit einem beabsichtigten Empfänger des Token konfiguriert werden. Alle Token werden mit dieser konfigurierten URL abgeglichen. Eine Citrix ADC 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

Im vorangegangenen Beispiel wird 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 Token akzeptiert werden sollen. Maximale Länge: 127. Es ist eine gute Praxis, den Aussteller der Token in OAuth Aktion zu konfigurieren. Dadurch wird sichergestellt, dass Token, die von einem falschen Autorisierungsserver ausgegeben werden, nicht zulässig sind.

SkeWTime: Gibt die zulässige Taktverzerrung in Minuten an, die eine Citrix ADC Appliance für ein eingehendes Token zulässt. Wenn beispielsweise SkewTime 10 ist, wäre das Token gültig von (aktuelle Zeit - 10) min bis (aktuelle Zeit + 10) min, also 20 min. Standardwert: 5

AllowedAlgorithms: Diese Option ermöglicht es dem Administrator, bestimmte Algorithmen in den eingehenden Token zu beschrä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

Nach der obigen Konfiguration sind nur Token zulässig, die RS256 und RS512 verwenden.

Umgehen bestimmter Datenverkehr von der Authentifizierung

In vielen Fällen gibt es einige Ermittlungs-APIs, die für die Clients öffentlich zugänglich sind. Diese APIs zeigen in der Regel die Konfiguration und die Funktionen des Dienstes selbst an. Ein Administrator kann die Citrix ADC Appliance so konfigurieren, dass die Authentifizierung von diesen Metadaten-URLs umgangen wird, indem die Richtlinie “Keine Authentifizierung” 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

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.

API-Authentifizierung mit der Citrix ADC Appliance
January 19, 2021
Beigesteuert von: 
C
January 19, 2021
Beigesteuert von: 
C

In diesem Artikel

Feedback zur Site | Datenschutz und rechtliche Hinweise | Cookie-Einstellungen | Consent settings
© 1999- Citrix Systems, Inc. All rights reserved.