Citrix ADC Ingress Controller

Authentifizierungs- und Autorisierungsrichtlinien für Kubernetes mit Citrix ADC

Authentifizierungs- und Autorisierungsrichtlinien werden verwendet, um Zugriffsbeschränkungen auf Ressourcen durchzusetzen, die von einem Anwendungs- oder API-Server gehostet Während Sie die Identität mithilfe der Authentifizierungsrichtlinien überprüfen können, werden Autorisierungsrichtlinien verwendet, um zu überprüfen, ob eine angegebene Anforderung über die erforderlichen Berechtigungen für den Zugriff auf eine Ressource verfügt.

Citrix stellt eine Kubernetes CustomResourceDefinition (CRD) bereit, die als Auth CRD bezeichnet wird und die Sie mit dem Citrix Ingress Controller verwenden können, um Authentifizierungsrichtlinien für den Ingress Citrix ADC zu definieren.

Auth CRD-Definition

Die Auth CRD ist im GitHub-Repo des Citrix Ingress Controller verfügbar unter: auth-crd.yaml. Das Auth CRD bietet Attribute für die verschiedenen Optionen, die zum Definieren der Authentifizierungsrichtlinien auf dem Ingress Citrix ADC erforderlich sind.

Auth CRD-Attribute

Das Auth CRD bietet die folgenden Attribute, die Sie zum Definieren der Authentifizierungsrichtlinien verwenden:

  • servicenames
  • authentication_mechanism
  • authentication_providers
  • authentication_policies
  • authorization_policies

Namen der Dienste

Der Name der Dienste, für die die Authentifizierungs- und Autorisierungsrichtlinien angewendet werden müssen.

Mechanismus der Authentifizierung

Die folgenden Authentifizierungsmechanismen werden unterstützt:

  • Anforderungsheader verwenden:
    Ermöglicht die Benutzerauthentifizierung mithilfe des Anforderungsheaders Sie können diesen Mechanismus verwenden, wenn die Anmeldeinformationen oder API-Schlüssel in einem Header übergeben werden (normalerweise Authorization-Header). Sie können beispielsweise die Authentifizierung mithilfe von Anforderungsheadern für Basic-, Digest-, Bearer-Authentifizierung oder API-Schlüssel verwenden.

  • Verwendung von Formularen: Sie können diesen Mechanismus mit der Benutzer- oder Webauthentifizierung verwenden, einschließlich der Konfiguration der vertrauenden Partei für OpenID Connect und der Service Provider-Konfiguration für SAML.

Wenn der Authentifizierungsmechanismus nicht angegeben ist, ist die Standardauthentifizierung mithilfe des Anforderungsheaders.

Im Folgenden sind die Attribute für die formularbasierte Authentifizierung aufgeführt.

Attribut Beschreibung
authentication_host Gibt einen vollqualifizierten Domänennamen (FQDN) an, an den der Benutzer für den ADC-Authentifizierungsdienst umgeleitet werden muss. Dieser FQDN sollte eindeutig sein und sich auf die Front-End-IP-Adresse von Citrix ADC mit Ingress/Service-Typ LoadBalancer oder der VIP-Adresse der Listener-CRD auflösen.
authentication_host_cert Gibt den Namen des SSL-Zertifikats an, das mit verwendet werden soll authentication_host. Dieses Zertifikat ist für die Authentifizierung mit dem Formular obligatorisch.
ingress_name Gibt den Ingress-Namen an, für den die Authentifizierung mithilfe von Formularen gilt.
lb_service_name Gibt den Namen des Dienstes vom Typ LoadBalancer an, für den die Authentifizierung mithilfe von Formularen gilt.
listener_name Der Name der Listener-CRD, für die die Authentifizierung mithilfe von Formularen gilt.
vip Gibt die Front-End-IP-Adresse des Ingress an, für die die Authentifizierung mithilfe von Formularen gilt. Dieses Attribut bezieht sich auf die mit dem Ingress angegebene frontend-ip-Adresse. Wenn es mehr als eine Ingress-Ressource gibt, die dieselbe Frontend-IP verwendet, wird empfohlen, VIP zu verwenden.

Hinweis:

  • Bei der Verwendung von Formularen kann die Authentifizierung für alle Arten von Datenverkehr aktiviert werden. Derzeit wird die granulare Authentifizierung nicht unterstützt.

  • Abhängig von der Ressource, auf die Sie die formularbasierte Authentifizierung anwenden müssen, können Sie eines der Attribute ingress_name, lb_service_name,listener_name oder vip verwenden, um die Ressource anzugeben.

Anbieter für Authentifizierung

Die Anbieter definieren den Authentifizierungsmechanismus und die Parameter, die für den Authentifizierungsmechanismus erforderlich sind.

Grundlegende Authentifizierung

Gibt an, dass die lokale Authentifizierung mit dem grundlegenden HTTP-Authentifizierungsschema verwendet wird. Um die Standardauthentifizierung zu verwenden, müssen Sie Benutzerkonten für den Ingress Citrix ADC erstellen.

OAuth Authentifizierung

Der OAuth-Authentifizierungsmechanismus erfordert einen externen Identitätsanbieter, um den Client mithilfe von OAuth2 zu authentifizieren und ein Zugriffstoken auszustellen. Wenn der Client das Zugriffstoken einem Citrix ADC als Zugriffsberechtigung präsentiert, validiert der Citrix ADC das Token mit den konfigurierten Werten. Wenn die Token-Validierung erfolgreich ist, gewährt Citrix ADC Zugriff auf den Client.

OAuth Authentifizierungsattribute

Im Folgenden sind die Attribute für die OAuth-Authentifizierung aufgeführt:

Attribut Beschreibung
Issuer Die Identität (normalerweise eine URL) des Servers, dessen Token für die Authentifizierung akzeptiert werden müssen.
jwks_uri Die URL des Endpunkts, der JWKs (JSON-Webschlüssel) für die JWT-Überprüfung (JSON-Web-Token) enthält.
audience Die Identität des Dienstes oder der Anwendung, für die das Token gilt.
token_in_hdr Der benutzerdefinierte Header-Name, in dem das Token vorhanden ist. Der Standardwert ist der Authorization-Header.
  Hinweis: Sie können mehr als einen Header angeben.
token_in_param Der Abfrageparameter, bei dem das Token vorhanden ist.
signature_algorithms Gibt die Liste der zulässigen Signaturalgorithmen an. Standardmäßig sind HS256-, RS256- und RS512-Algorithmen zulässig.
introspect_url Die URL des Introspektionsendpunkts des Authentifizierungsservers (IdP). Wenn das dargestellte Zugriffstoken ein undurchsichtiges Token ist, wird die Introspektion für die Tokenüberprüfung verwendet.
client_credentials Der Name des geheimen Kubernetes-Objekts, das die Client-ID und das Clientgeheimnis enthält, die für die Authentifizierung beim Authentifizierungsserver erforderlich sind.
claims_to_save Die Liste der zu speichernden Ansprüche. Ansprüche werden verwendet, um Autorisierungsrichtlinien zu erstellen.

OpenID Connect (OIDC) ist eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll. OIDC ermöglicht es Clients, die Identität des Endbenutzers basierend auf der von einem Autorisierungsserver durchgeführten Authentifizierung zu überprüfen und grundlegende Profilinformationen über den Endbenutzer zu erhalten. Zusätzlich zu den OAuth-Attributen können Sie die folgenden Attribute verwenden, um OIDC zu konfigurieren.

Attribut Beschreibung
metadata_url Gibt die URL an, die zum Abrufen von OAUTH- oder OIDC-Provider-Metadaten verwendet wird.
user_field Gibt das Attribut im Token an, aus dem der Benutzername extrahiert werden soll. Standardmäßig untersucht Citrix ADC das E-Mail-Attribut auf Benutzer-ID.
default_group Gibt die Gruppe an, die der Anforderung zugewiesen wurde, falls die Authentifizierung erfolgreich ist. Diese Gruppe ist zusätzlich zu allen extrahierten Gruppen aus dem Token.
grant_type Gibt die Art des Flusses zum Token-Endpunkt an. Der Standardwert ist CODE.
pkce Gibt an, ob der Proofschlüssel für Code Exchange (PKCE) aktiviert werden soll. Der Standardwert ist ENABLED.
token_ep_auth_method Gibt die Authentifizierungsmethode an, die mit dem Token-Endpunkt verwendet werden soll. Der Standardwert ist client_secret_post.

SAML-Authentifizierung

Die Security Assertion Markup Language (SAML) ist ein XML-basierter offener Standard, der die Authentifizierung von Benutzern über Produkte oder Organisationen hinweg ermöglicht. Der SAML-Authentifizierungsmechanismus erfordert einen externen Identitätsanbieter, um den Client zu authentifizieren. SAML überträgt die Clientidentität vom Identitätsanbieter zum Citrix ADC. Bei erfolgreicher Validierung der Clientidentität gewährt Citrix ADC Zugriff auf den Client.

Im Folgenden sind die Attribute für die SAML-Authentifizierung aufgeführt.

Attribut Beschreibung
metadata_url Gibt die zum Abrufen von SAML-Metadaten verwendete URL an.
metadata_refresh_interval Gibt das Intervall in Minuten für das Abrufen von Metadaten von der angegebenen Metadaten-URL an.
signing_cert Gibt das SSL-Zertifikat an, um Anforderungen vom Dienstanbieter (SP) an den Identitätsanbieter (IdP) zu signieren.
audience Gibt die Identität des Dienstes oder der Anwendung an, für die das Token gilt.
issuer_name Gibt den Namen an, der in Anforderungen verwendet wird, die von SP an IdP gesendet werden, um den Citrix ADC zu identifizieren
binding Gibt den Transportmechanismus der SAML-Nachricht an. Der Standardwert ist POST.
artifact_resolution_service_url Gibt die URL des Artefakt-Auflösungsdienstes auf IdP an.
logout_binding Gibt den Transportmechanismus der SAML-Abmeldung an. Der Standardwert ist POST.
reject_unsigned_assertion Lehnt nicht signierte SAML-Zusicherungen ab. Wenn dieser Wert ist ON, lehnt er die Assertion ohne Signatur ab.
user_field Gibt die in der SAML-Assertion angegebene SAML-Benutzer-ID an
default_authentication_group Gibt die Standardgruppe an, die ausgewählt wird, wenn die Authentifizierung erfolgreich ist, zusätzlich zu den extrahierten Gruppen.
skewtime Gibt die zulässige Taktversatzzeit in Minuten für eine eingehende SAML-Assertion an.
attributes_to_save Gibt die Liste der durch Kommas getrennten Attributnamen an, die extrahiert und als Schlüssel-Wert-Paare für die Sitzung auf Citrix ADC gespeichert werden müssen.

LDAP-Authentifizierung

LDAP (Lightweight Directory Access Protocol) ist ein offenes, herstellerneutrales Anwendungsprotokoll nach Industriestandard für den Zugriff auf und die Verwaltung verteilter Verzeichnisinformationsdienste über ein Internet Protocol (IP) -Netzwerk. LDAP wird häufig verwendet, um einen zentralen Ort zum Speichern von Benutzernamen und Passwörtern bereitzustellen. Mit LDAP können viele verschiedene Anwendungen und Dienste eine Verbindung zum LDAP-Server herstellen, um Benutzer zu validieren.

Hinweis:

Die LDAP-Authentifizierung wird sowohl über die Authentifizierungsmechanismen mit dem Anforderungsheader als auch über Formulare unterstützt.

Im Folgenden sind die Attribute für die LDAP-Authentifizierung aufgeführt.

Attribut Beschreibung
server_ip Gibt die dem LDAP-Server zugewiesene IP-Adresse an.
server_name Gibt den LDAP-Servernamen als FQDN an.
server_port Gibt den Port an, an dem der LDAP-Server Verbindungen akzeptiert. Der Standardwert ist 389.
base Gibt den Basisknoten an, auf dem LDAP-Suchen gestartet werden sollen. Wenn der LDAP-Server lokal ausgeführt wird, ist der Standardwert von base dc=netscaler, dc=com.
server_login_credentials Gibt das geheime Kubernetes-Objekt an, das Anmeldeinformationen für die Anmeldung beim LDAP-Server bereitstellt. Die geheimen Daten sollten einen Benutzernamen und ein Kennwort haben.
login_name Gibt das LDAP-Anmeldenamenattribut an. Der Citrix ADC verwendet den LDAP-Anmeldenamen, um externe LDAP-Server oder Active Directories abzufragen.
security_type Gibt die Art der Sicherheit an, die für die Kommunikation zwischen dem Citrix ADC und dem LDAP-Server verwendet wird. Die Standardeinstellung ist TLS.
validate_server_cert Validiert LDAP-Serverzertifikate. Der Standardwert ist NO.
hostname Gibt den Hostnamen für den LDAP-Server an. Wenn validate_server_cert auf ON ist, muss dieser Wert der Hostname auf dem Zertifikat aus dem LDAP sein. Eine Nichtübereinstimmung des Hostnamens führt zu einem Verbindungsfehler.
sub_attribute_name Gibt den Namen des LDAP-Gruppenunterattributs an. Dieses Attribut wird für die Gruppen-Extraktion vom LDAP-Server verwendet.
group_attribute_name Gibt den Namen des LDAP-Gruppenattributs an. Dieses Attribut wird für die Gruppenextraktion auf dem LDAP-Server verwendet.
search_filter Gibt die Zeichenfolge an, die mit der standardmäßigen LDAP-Benutzersuchzeichenfolge kombiniert werden soll, um den Suchwert zu bilden. Wenn beispielsweise der Suchfilter “vpnallowed=true” mit dem LDAP-Anmeldenamen “samaccount” kombiniert wird und der vom Benutzer angegebene Benutzername “bob” lautet, ist das Ergebnis die LDAP-Suchzeichenfolge “” (& (vpnallowed=true) (samaccount=bob) “”. Schließen Sie die Suchzeichenfolge in zwei Sätze doppelter Anführungszeichen ein.
auth_timeout Gibt an, wie viele Sekunden der Citrix ADC auf eine Antwort vom Server wartet. Der Standardwert ist 3.
password_change Erlaubt Anfragen zur Kennwortänderung. Der Standardwert ist DISABLED.
attributes_to_save Liste der durch Komma getrennten Attributnamen, die vom LDAP-Server abgerufen und als Schlüssel-Wert-Paare für die Sitzung auf Citrix ADC gespeichert werden müssen.

Authentifizierungsrichtlinien

Mit den authentication_policies können Sie die Auswahlkriterien für den Datenverkehr definieren, um den Authentifizierungsmechanismus anzuwenden und den Anbieter anzugeben, den Sie für den ausgewählten Datenverkehr verwenden möchten.

Die Authentifizierungsrichtlinie unterstützt zwei Formate, in denen Sie Authentifizierungsregeln angeben können:

  • Ressourcenformat
  • Ausdrucksformat

Im Folgenden sind die Attribute für Richtlinien mit Ressourcenformat aufgeführt:

Attribut Beschreibung
path Ein Array von URL-Pfadpräfixen, die sich auf einen bestimmten API-Endpunkt beziehen. Beispiel: /api/v1/products/.
method Ein Array von HTTP-Methoden. Zulässige Werte sind GET, PUT, POST oder DELETE. Der Datenverkehr wird ausgewählt, wenn die URI der eingehenden Anforderung mit einem der Pfade und einer der aufgelisteten Methoden übereinstimmt. Wenn die Methode nicht angegeben ist, wird nur der Pfad für die Auswahlkriterien des Datenverkehrs verwendet.
provider Gibt den Authentifizierungsmechanismus an, der verwendet werden muss. Wenn der Authentifizierungsmechanismus nicht bereitgestellt wird, wird keine Authentifizierung durchgeführt.

Die folgenden Attribute gelten für Authentifizierungsrichtlinien im Ausdrucksformat:

Attribut Beschreibung
expression Gibt den Citrix ADC-Ausdruck an, der basierend auf der Authentifizierung ausgewertet werden soll
provider Gibt den Authentifizierungsmechanismus an, der verwendet werden muss. Wenn der Authentifizierungsmechanismus nicht bereitgestellt wird, wird keine Authentifizierung durchgeführt.

Hinweis:

Wenn Sie die Authentifizierung für einen bestimmten Endpunkt überspringen möchten, erstellen Sie eine Richtlinie mit dem Attribut provider, das als leere Liste festgelegt ist. Andernfalls wird die Anfrage abgelehnt.

Richtlinien zur Autorisierung

Mit Autorisierungsrichtlinien können Sie die Auswahlkriterien für den Datenverkehr definieren, um die Berechtigungsanforderungen für den ausgewählten Datenverkehr anzuwenden.

Die Autorisierungsrichtlinie unterstützt zwei Formate, in denen Sie die Autorisierungsregeln angeben können:

  • Ressourcenformat
  • Ausdrucksformat

Im Folgenden sind die Attribute für Autorisierungsrichtlinien mit Ressourcenformat aufgeführt:

Attribut Beschreibung
path Ein Array von URL-Pfadpräfixen, die sich auf einen bestimmten API-Endpunkt beziehen. Beispiel: /api/v1/products/.
method Ein Array von HTTP-Methoden. Zulässige Werte sind GET, PUT, POST oder DELETE.
claims Gibt die für den Zugriff auf einen bestimmten API-Endpunkt erforderlichen Ansprüche an. name gibt den Anspruchsnamen an und values gibt die erforderlichen Berechtigungen an. Sie können mehr als einen Anspruch geltend machen. Wenn eine leere Liste angegeben wird, bedeutet dies, dass keine Autorisierung erforderlich ist.
  Hinweis: Jeder Anspruch, der für die Autorisierung verwendet werden muss, sollte im Rahmen der Authentifizierung gespeichert werden.

Im Folgenden sind die Attribute für Autorisierungsrichtlinien mit Ausdrucksformat aufgeführt:

Attribut Beschreibung
expression Gibt einen Ausdruck an, der für die Autorisierung ausgewertet wird.

Hinweis:

Citrix ADC erfordert sowohl Authentifizierungs- als auch Autorisierungsrichtlinien für den API-Verkehr Daher müssen Sie eine Autorisierungsrichtlinie mit einer Authentifizierungsrichtlinie konfigurieren. Selbst wenn Sie keine Berechtigungsprüfungen haben, müssen Sie eine Autorisierungsrichtlinie mit leeren Ansprüchen erstellen. Andernfalls wird die Anfrage mit einem 403-Fehler abgelehnt.

Hinweis:

Die Autorisierung wäre erfolgreich, wenn die eingehende Anforderung mit einer Richtlinie übereinstimmt (Pfad, Methode und Ansprüche). Alle Richtlinien werden solange ausprobiert, bis eine Übereinstimmung vorliegt. Wenn es erforderlich ist, die Autorisierung für einen bestimmten Endpunkt selektiv zu Bypass, muss eine explizite Richtlinie erstellt werden.

Bereitstellen der Auth CRD

Führen Sie Folgendes aus, um die Auth CRD bereitzustellen:

  1. Laden Sie die CRD herunter (auth-crd.yaml).

  2. Stellen Sie das Auth CRD mit dem folgenden Befehl bereit:

    kubectl create -f auth-crd.yaml
    

    Beispiel:

    root@master:~# kubectl create -f auth-crd.yaml
    
    customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created
    

Wie schreibt man Richtlinien für Authentifizierung und Autorisierung

Nachdem Sie die von Citrix bereitgestellte CRD im Kubernetes-Cluster bereitgestellt haben, können Sie die Konfiguration der Authentifizierungsrichtlinie in einer Datei .yaml definieren. Verwenden Sie in der Datei .yaml die Option authpolicy im Feld kind und fügen Sie im Abschnitt spec die Auth CRD-Attribute basierend auf Ihren Anforderungen für die Richtlinienkonfiguration hinzu.

Nachdem Sie die Datei .yaml bereitgestellt haben, wendet der Citrix Ingress Controller die Konfiguration der Authentifizierungsrichtlinie auf dem Ingress Citrix ADC-Gerät an.

Lokaler Authentifizierungsanbieter

Im Folgenden finden Sie ein Beispiel für eine Authentifizierungs- und Autorisierungsrichtliniendefinition für den Typ local-auth-provider (local_auth.yaml).

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "local-auth-provider"
            basic_local_db:
                use_local_auth: 'YES'

      authentication_policies:
          - resource:
              path:
                - '/orders/'
                - '/shipping/'
              method: [GET, POST]
            provider: ["local-auth-provider"]
          
          # skip authentication for this
          - resource:
              path:
                - '/products/'
              method: [GET]
            provider: []

      authorization_policies:
          # skip authorization
          - resource:
              path: []
              method: []
              claims: []

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die lokale Authentifizierung für die Anforderungen an Folgendes durch:
    • GET - oder POST-Vorgang für Bestellungen und Versandendpunkte.
  • Citrix ADC führt die Authentifizierung für den GET-Vorgang nicht auf dem Produktendpunkt durch.
  • Citrix ADC wendet keine Autorisierungsberechtigungen an.

OAuth JWT-Überprüfung

Im Folgenden finden Sie ein Beispiel für eine Authentifizierungs- und Autorisierungsrichtliniendefinition für die OAuth JWT-Überprüfung (oauth_jwt_auth.yaml).

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authexample
spec:
    servicenames:
    - frontend

    authentication_providers:
      - name: "jwt-auth-provider"
        oauth:
          issuer: "https://sts.windows.net/tenant1/"
          jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
          audience : ["https://api.service.net"]
          claims_to_save : ["scope"]

    authentication_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [GET, POST]
          provider: ["jwt-auth-provider"]
        
        # skip authentication for this
        - resource:
            path:
              - '/products/'
            method: [GET]
          provider: []

    authorization_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [POST]
            claims: 
              - name: "scope"
                values: ["read", "write"]
        - resource:
            path:
              - '/orders/'
            method: [GET]
            claims: 
              - name: "scope"
                values: ["read"]
        # skip authorization, no claims required
        - resource:
            path:
              - '/shipping/'
            method: [GET]
            claims: []

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die JWT-Überprüfung für die Anforderungen an Folgendes durch:

    • Der GET - oder POST-Vorgang für Bestellungen und Versandendpunkte .
  • Citrix ADC überspringt die Authentifizierung für den GET-Vorgang auf dem Produktendpunkt .

  • Citrix ADC benötigt den Bereichsanspruch mit den Berechtigungen read und write für den POST-Vorgang auf Bestellungen und Versandendpunkten.

  • Citrix ADC erfordert den Bereichsanspruch mit der Leseberechtigung für den GET-Vorgang auf dem Auftragsendpunkt .

  • Citrix ADC benötigt keine Berechtigungen für den GET-Betrieb auf dem Versandendpunkt .

Wenn das Token für OAuth in einem benutzerdefinierten Header vorhanden ist, kann es mit dem Attribut token_in_hdr wie folgt angegeben werden:

      oauth:
        issuer: "https://sts.windows.net/tenant1/"
        jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
        audience : ["https://vault.azure.net"]
        token_in_hdr : [“custom-hdr1”]

Wenn das Token in einem Abfrageparameter vorhanden ist, kann es mit dem Attribut token_in_param wie folgt angegeben werden:

      oauth:
        issuer: "https://sts.windows.net/tenant1/"
        jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0keys"
        audience : ["https://vault.azure.net"]
        token_in_param : [“query-param1”]

OAuth Selbstbeobachtung

Im Folgenden finden Sie ein Beispiel für eine Authentifizierungs- und Autorisierungsrichtlinie für die OAuth JWT-Überprüfung (oauth_intro_auth.yaml)

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "introspect-provider"
            oauth:
              issuer: "ns-idp"
              jwks_uri: "https://idp.aaa/oauth/idp/certs"
              audience : ["https://api.service.net"]
              client_credentials: "oauthsecret"
              introspect_url: https://idp.aaa/oauth/idp/introspect
              claims_to_save : ["scope"]

      authentication_policies:
          - resource:
              path: []
              method: []
            provider: ["introspect-provider"]
          
      authorization_policies:
          - resource:
              path: []
              method: [POST]
              claims: 
              - name: "scope"
                values: ["read", "write"]
          - resource:
              path: []
              method: [GET]
              claims: 
              - name: "scope"
                values: ["read"]

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die OAuth Introspektion durch, wie im Anbieter introspect-provider für alle Anforderungen angegeben.

  • Citrix ADC benötigt den Bereichsanspruch mit den Berechtigungen read und write für alle POST-Anforderungen .

  • Citrix ADC benötigt den Bereichsanspruch mit der Leseberechtigung für alle GET-Anforderungen .

Erstellen eines geheimen Objekts mit Clientanmeldeinformationen für die Introspektion

Für die Konfiguration der OAuth Introspektion wird ein Kubernetes-Secrets-Objekt benötigt. Sie können ein geheimes Objekt auf ähnliche Weise erstellen, wie im folgenden Beispiel gezeigt:

apiVersion: v1        
kind: Secret          
metadata:             
  name: oauthsecret
type: Opaque        
stringData:           
 client_id: "nsintro"
 client_secret: "nssintro"

Hinweis:

Die Schlüssel des undurchsichtigen geheimen Objekts müssen client_id und client_secret sein. Ein Benutzer kann die Werte für sie wie gewünscht festlegen.

SAML-Authentifizierung mithilfe von Formularen

Im Folgenden finden Sie ein Beispiel für die SAML-Authentifizierung mithilfe von Formularen. Im Beispiel sind authhost-tls-cert-secret und saml-tls-cert-secret Kubernetes TLS-Geheimnisse, die sich auf Zertifikat und Schlüssel beziehen.

Hinweis:

Wenn certkey.cert und certkey.key Zertifikat bzw. Schlüssel für den Authentifizierungshost sind, dann kann authhost-tls-cert-secret mit dem folgenden Befehl gebildet werden:

     kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert

In ähnlicher Weise können Sie diesen Befehl verwenden, um saml-tls-cert-secret mit dem erforderlichen Zertifikat und Schlüssel zu bilden.


apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: samlexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        listener_name: “example-listener”

    authentication_providers:
        - name: "saml-auth-provider"
          saml:
              metadata_url: "https://idp.aaa/metadata/samlidp/aaa"
              signing_cert:
                  tls_secret: saml-tls-cert-secret

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["saml-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []

<!--NeedCopy-->

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die SAML-Authentifizierung durch, wie im Anbieter saml-auth-provider für alle Anforderungen angegeben. Hinweis: Die granulare Authentifizierung wird für den Forms-Mechanismus nicht unterstützt.

  • Citrix ADC erfordert den Gruppenanspruch mit der Berechtigung admin für alle POST-Anforderungen .

  • Citrix ADC benötigt keine spezielle Berechtigung für GET-Anfragen .

OpenID Connect-Authentifizierung mithilfe von Formularen

Im Folgenden finden Sie ein Beispiel für das Erstellen der OpenID Connect-Authentifizierung zum Konfigurieren von Citrix ADC in einer Relaying-Party-Rolle (RP), um Benutzer für einen externen Identitätsanbieter zu authentifizieren. authentication_mechanism muss auf using_forms eingestellt sein, um die OpenID Connect-Prozeduren auszulösen.

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authoidc
spec:
    servicenames:
    - frontend
    authentication_mechanism:
        using_forms:
            authentication_host: "10.221.35.213"
            authentication_host_cert:
                 tls_secret: "oidc-tls-secret"
            ingress_name:  “example-ingress”

    authentication_providers:

        - name: "oidc-provider"
          oauth:
            audience : ["https://app1.citrix.com"]
            client_credentials: "oidcsecret"
            metadata_url: "https://10.221.35.214/oauth/idp/.well-known/openid-configuration"
            default_group: "groupA"
            user_field: "sub"
            pkce: "ENABLED"
            token_ep_auth_method: "client_secret_post"

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["oidc-provider"]

    authorization_policies:

        #default - no authorization requirements
        - resource:
            path: []
            method: []
            claims: []
<!--NeedCopy-->

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die OIDC-Authentifizierung (vertrauende Partei) durch, wie im Anbieter oidc-provider für alle Anforderungen angegeben.

    Hinweis: Die granulare Authentifizierung wird für den Forms-Mechanismus nicht unterstützt.

  • Citrix ADC benötigt keine Autorisierungsberechtigungen.

LDAP-Authentifizierung mit dem Request-Header

Im Folgenden finden Sie ein Beispiel für die LDAP-Authentifizierung mithilfe des Request-Headers.

In diesem Beispiel ist ldapcredential das Kubernetes-Geheimnis, das sich auf die Anmeldeinformationen des LDAP-Servers bezieht. Informationen zum Erstellen von LDAP-Serveranmeldeinformationen finden Sie in der Datei ldap_secret.yaml.


apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

        - name: "local-auth-provider"
          basic_local_db:
              use_local_auth: 'YES'

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]


    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []
<!--NeedCopy-->

Hinweis: Mit dem Request-Header-basierten Authentifizierungsmechanismus wird eine granulare Authentifizierung basierend auf dem Datenverkehr unterstützt.

LDAP-Authentifizierung mithilfe von Formularen

Im Beispiel ist authhost-tls-cert-secret das TLS-Geheimnis von Kubernetes, das sich auf Zertifikat und Schlüssel bezieht.

Wenn certkey.cert und certkey.key Zertifikat bzw. Schlüssel für den Authentifizierungshost sind, dann kann authhost-tls-cert-secret mit dem folgenden Befehl gebildet werden:

    kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert

In diesem Beispiel ist ldapcredential das Kubernetes-Geheimnis, das sich auf die Anmeldeinformationen des LDAP-Servers bezieht. Informationen zum Erstellen von LDAP-Serveranmeldeinformationen finden Sie in der Datei ldap_secret.yaml.

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        vip: "192.2.156.156"

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []

<!--NeedCopy-->

Das Beispiel für eine Richtliniendefinition führt Folgendes aus:

  • Citrix ADC führt die LDAP-Authentifizierung für den gesamten Datenverkehr (alle Anforderungen) durch.
  • Citrix ADC wendet keine Autorisierungsberechtigung an.

Das Folgende ist ein Beispiel für LDAP_secret.yaml.

apiVersion: v1
kind: Secret
metadata:
  name: ldapcredential
type: Opaque
stringData:
  username: 'ldap_server_username'
  password: 'ldap_server_password'

<!--NeedCopy-->

Beispiel für die Unterstützung von Citrix ADC-Ausdrücken mit Auth CRD

Dieses Beispiel zeigt, wie Sie Citrix ADC-Ausdrücke zusammen mit Authentifizierungs- und Autorisierungsrichtlinien angeben können:

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_mechanism:
        using_request_header: 'ON'

      authentication_providers:
          - name: "ldap-auth-provider"
            ldap:              
                server_ip: "192.2.156.160"
                base: 'dc=aaa,dc=local'
                login_name: accountname
                sub_attribute_name: CN
                server_login_credentials: ldapcredential
                # "memberof" attribute details are extracted from LDAP server.
                attributes_to_save: memberof

      authentication_policies:
          # Perform LDAP authentication for the host hotdrink.beverages.com
          - expression: 'HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("hotdrink.beverages.com")'
            provider: ["ldap-auth-provider"]


      authorization_policies:
          # ALLOW the session only if the authenticated user is associated with attribute "memberof" having value "grp4"
          - expression: 'aaa.user.attribute("memberof").contains("grp4")'
Authentifizierungs- und Autorisierungsrichtlinien für Kubernetes mit Citrix ADC