Contrôleur d'entrée Citrix ADC

Stratégies d’authentification et d’autorisation pour Kubernetes avec Citrix ADC

Les stratégies d’authentification et d’autorisation sont utilisées pour appliquer des restrictions d’accès aux ressources hébergées par un serveur d’applications ou d’API. Bien que vous puissiez vérifier l’identité à l’aide des stratégies d’authentification, les stratégies d’autorisation sont utilisées pour vérifier si une demande spécifiée possède les autorisations nécessaires pour accéder à une ressource.

Citrix fournit une définition CustomResourceDefinition (CRD) Kubernetes appelée Auth CRD que vous pouvez utiliser avec le Citrix ingress controller pour définir des stratégies d’authentification sur le Citrix ADC d’entrée.

Définition du CRD d’authentification

Le CRD d’authentification est disponible dans le référentiel GitHub du Citrix ingress controller à l’adresse suivante : auth-crd.yaml. Le CRD d’authentification fournit des attributs pour les différentes options requises pour définir les stratégies d’authentification sur le Citrix ADC d’entrée.

Attributs Auth CRD

Le CRD d’authentification fournit les attributs suivants que vous utilisez pour définir les stratégies d’authentification :

  • servicenames
  • authentication_mechanism
  • authentication_providers
  • authentication_policies
  • authorization_policies

Noms des services

Nom des services pour lesquels les stratégies d’authentification et d’autorisation doivent être appliquées.

Mécanisme d’authentification

Les mécanismes d’authentification suivants sont pris en charge :

  • Utilisation des en-têtes de demande :
    permet l’authentification de l’utilisateur à l’aide de l’en-tête Vous pouvez utiliser ce mécanisme lorsque les informations d’identification ou les clés d’API sont transmises dans un en-tête (généralement un en-tête d’autorisation). Par exemple, vous pouvez utiliser l’authentification à l’aide d’en-têtes de demande pour l’authentification de base, de résumé, de support ou d’API.

  • Utilisation de formulaires : Vous pouvez utiliser ce mécanisme avec l’authentification utilisateur ou Web, y compris la configuration de la partie de confiance pour OpenID connect et la configuration du fournisseur de services pour SAML.

Lorsque le mécanisme d’authentification n’est pas spécifié, la valeur par défaut est l’authentification à l’aide de l’en-tête de demande.

Voici les attributs pour l’authentification basée sur les formulaires.

Attribut Description
authentication_host Spécifie un nom de domaine complet (FQDN) vers lequel l’utilisateur doit être redirigé pour le service d’authentification ADC. Ce nom de domaine complet doit être unique et doit être résolu sur l’adresse IP frontale de Citrix ADC avec l’équilibreur de charge de type entrée/service ou l’adresse VIP du CRD Listener.
authentication_host_cert Spécifie le nom du certificat SSL à utiliser avec le authentication_host. Ce certificat est obligatoire lors de l’authentification à l’aide du formulaire.
ingress_name Spécifie le nom d’entrée pour lequel l’authentification à l’aide de formulaires est applicable.
lb_service_name Spécifie le nom du service de type LoadBalancer pour lequel l’authentification à l’aide de formulaires est applicable.
listener_name Nom du CRD Listener pour lequel l’authentification à l’aide de formulaires est applicable.
vip Spécifie l’adresse IP frontale de l’entrée pour laquelle l’authentification à l’aide de formulaires est applicable. Cet attribut fait référence à l’adresse frontend-ip fournie avec l’entrée. S’il y a plus d’une ressource Ingress qui utilise le même frontend-ip, il est recommandé d’utiliser vip.

Remarque :

  • Lors de l’utilisation de formulaires, l’authentification peut être activée pour tous les types de trafic. L’authentification granulaire n’est actuellement pas prise en charge.

  • Selon la ressource à laquelle vous devez appliquer l’authentification basée sur un formulaire, vous pouvez utiliser l’un des attributs ingress_name, lb_service_name, listener_name ou vip pour spécifier la ressource.

Fournisseurs d’authentification

Les fournisseurs définissent le mécanisme d’authentification et les paramètres requis pour le mécanisme d’authentification.

Authentification basique

Spécifie que l’authentification locale est utilisée avec le schéma d’authentification de base HTTP. Pour utiliser l’authentification de base, vous devez créer des comptes d’utilisateurs sur l’entrée Citrix ADC.

Authentification OAuth

Le mécanisme d’authentification OAuth nécessite un fournisseur d’identité externe pour authentifier le client à l’aide d’OAuth2 et émettre un jeton d’accès. Lorsque le client présente le jeton d’accès à un Citrix ADC en tant qu’informations d’identification d’accès, Citrix ADC valide le jeton à l’aide des valeurs configurées. Si la validation du jeton réussit, Citrix ADC accorde l’accès au client.

Attributs d’authentification OAuth

Les attributs pour l’authentification OAuth sont les suivants :

Attribut Description
Issuer L’identité (généralement une URL) du serveur dont les jetons doivent être acceptés pour l’authentification.
jwks_uri L’URL du point de terminaison qui contient les JWK (clé Web JSON) pour la vérification JWT (jeton Web JSON).
audience L’identité du service ou de l’application pour lequel le jeton est applicable.
token_in_hdr Le nom d’en-tête personnalisé dans lequel le jeton est présent. La valeur par défaut est l’en-tête Authorization.
  Remarque : Vous pouvez spécifier plusieurs en-têtes.
token_in_param Le paramètre de requête dans lequel le jeton est présent.
signature_algorithms Spécifie la liste des algorithmes de signature autorisés. Par défaut, les algorithmes HS256, RS256 et RS512 sont autorisés.
introspect_url L’URL du point de terminaison d’introspection du serveur d’authentification (IdP). Si le jeton d’accès présenté est un jeton opaque, l’introspection est utilisée pour la vérification du jeton.
client_credentials Nom de l’objet Secrets Kubernetes qui contient l’ID client et le secret client requis pour s’authentifier auprès du serveur d’authentification.
claims_to_save La liste des réclamations à enregistrer. Les revendications sont utilisées pour créer des stratégies d’autorisation.

OpenID Connect (OIDC) est une simple couche d’identité au-dessus du protocole OAuth 2.0. L’OIDC permet aux clients de vérifier l’identité de l’utilisateur final sur la base de l’authentification effectuée par un serveur d’autorisation, ainsi que d’obtenir des informations de profil de base concernant l’utilisateur final. Outre les attributs OAuth, vous pouvez utiliser les attributs suivants pour configurer OIDC.

Attribut Description
metadata_url Spécifie l’URL utilisée pour obtenir les métadonnées du fournisseur OAUTH ou OIDC.
user_field Spécifie l’attribut du jeton à partir duquel le nom d’utilisateur doit être extrait. Par défaut, Citrix ADC examine l’attribut e-mail pour l’ID utilisateur.
default_group Spécifie le groupe affecté à la demande si l’authentification réussit. Ce groupe s’ajoute à tous les groupes extraits du jeton.
grant_type Spécifie le type de flux vers le point d’extrémité du jeton. La valeur par défaut est CODE.
pkce Spécifie s’il faut activer la clé de preuve pour l’échange de code (PKCE). La valeur par défaut est ENABLED.
token_ep_auth_method Spécifie la méthode d’authentification à utiliser avec le point de terminaison du jeton. La valeur par défaut est client_secret_post.

Authentification SAML

Le langage SAML (Security Assertion Markup Language) est un standard ouvert basé sur XML qui permet l’authentification des utilisateurs dans tous les produits ou organisations. Le mécanisme d’authentification SAML nécessite un fournisseur d’identité externe pour authentifier le client. SAML fonctionne en transférant l’identité du client du fournisseur d’identité vers Citrix ADC. En cas de validation réussie de l’identité du client, Citrix ADC accorde l’accès au client.

Voici les attributs pour l’authentification SAML.

Attribut Description
metadata_url Spécifie l’URL utilisée pour obtenir les métadonnées SAML.
metadata_refresh_interval Spécifie l’intervalle en minutes pour récupérer les métadonnées à partir de l’URL de métadonnées spécifiée.
signing_cert Spécifie le certificat SSL pour signer les demandes du fournisseur de services (SP) au fournisseur d’identité (IdP).
audience Spécifie l’identité du service ou de l’application pour lequel le jeton est applicable.
issuer_name Spécifie le nom utilisé dans les demandes envoyées du SP au fournisseur d’identité pour identifier Citrix ADC.
binding Spécifie le mécanisme de transport du message SAML. La valeur par défaut est POST.
artifact_resolution_service_url Spécifie l’URL du service de résolution d’artefacts sur l’IdP.
logout_binding Spécifie le mécanisme de transport de la déconnexion SAML. La valeur par défaut est POST.
reject_unsigned_assertion Rejette les assertions SAML non signées. Si cette valeur est ON, elle rejette l’assertion sans signature.
user_field Spécifie l’ID utilisateur SAML spécifié dans l’assertion SAML
default_authentication_group Spécifie le groupe par défaut qui est choisi lorsque l’authentification réussit, en plus des groupes extraits.
skewtime Spécifie le temps d’inclinaison d’horloge autorisé en minutes sur une assertion SAML entrante.
attributes_to_save Spécifie la liste des noms d’attributs séparés par des virgules qui doivent être extraits et stockés sous forme de paires clé-valeur pour la session sur Citrix ADC.

Authentification LDAP

Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole d’application ouvert, indépendant du fournisseur et standard de l’industrie qui permet d’accéder et de gérer des services d’informations d’annuaire distribués sur un réseau IP (Internet Protocol). L’une des utilisations courantes du protocole LDAP est de fournir un emplacement central pour stocker les noms d’utilisateur et les mots de passe. LDAP permet à de nombreuses applications et services différents de se connecter au serveur LDAP pour valider les utilisateurs.

Remarque :

L’authentification LDAP est prise en charge à la fois par les mécanismes d’authentification utilisant l’en-tête de demande ou les formulaires.

Voici les attributs pour l’authentification LDAP.

Attribut Description
server_ip Spécifie l’adresse IP attribuée au serveur LDAP.
server_name Spécifie le nom du serveur LDAP en tant que nom de domaine complet.
server_port Spécifie le port sur lequel le serveur LDAP accepte les connexions. La valeur par défaut est 389.
base Spécifie le nœud de base sur lequel démarrer les recherches LDAP. Si le serveur LDAP s’exécute localement, la valeur par défaut de base est dc=netscaler, dc=com.
server_login_credentials Spécifie l’objet secret Kubernetes fournissant des informations d’identification pour se connecter au serveur LDAP. Les données secrètes doivent comporter un nom d’utilisateur et un mot de passe.
login_name Spécifie l’attribut de nom de connexion LDAP . Citrix ADC utilise le nom de connexion LDAP pour interroger des serveurs LDAP externes ou Active Directory.
security_type Spécifie le type de sécurité utilisé pour les communications entre Citrix ADC et le serveur LDAP. La valeur par défaut est TLS.
validate_server_cert Valide les certificats du serveur LDAP. La valeur par défaut est NO.
hostname Spécifie le nom d’hôte du serveur LDAP. Si validate_server_cert c’est le cas ON, cette valeur doit être le nom d’hôte figurant sur le certificat du LDAP. Une incompatibilité de nom d’hôte entraîne un échec de connexion.
sub_attribute_name Spécifie le nom du sous-attribut du groupe LDAP. Cet attribut est utilisé pour l’extraction de groupe à partir du serveur LDAP.
group_attribute_name Spécifie le nom d’attribut de groupe LDAP. Cet attribut est utilisé pour l’extraction de groupes sur le serveur LDAP.
search_filter Spécifie la chaîne à combiner avec la chaîne de recherche d’utilisateur LDAP par défaut pour former la valeur de recherche. Par exemple, si le filtre de recherche « vpnallowed=true » est combiné avec le nom de connexion LDAP « samaccount » et que le nom d’utilisateur fourni par l’utilisateur est « bob », le résultat est la chaîne de recherche LDAP «” (& (vpnallowed=true) (samaccount=bob) “». Placez la chaîne de recherche entre deux jeux de guillemets doubles.
auth_timeout Spécifie le nombre de secondes pendant lesquelles Citrix ADC attend une réponse du serveur. La valeur par défaut est 3.
password_change Autorise les demandes de changement de mot La valeur par défaut est DISABLED.
attributes_to_save Liste des noms d’attributs séparés par des virgules qui doivent être récupérés à partir du serveur LDAP et stockés sous forme de paires clé-valeur pour la session sur Citrix ADC.

Stratégies d’authentification

Les authentication_policies vous permettent de définir les critères de sélection du trafic pour appliquer le mécanisme d’authentification et également de spécifier le fournisseur que vous souhaitez utiliser pour le trafic sélectionné.

La stratégie d’authentification prend en charge deux formats grâce auxquels vous pouvez spécifier des règles d’authentification :

  • format de ressource
  • format d’expression

Les attributs des stratégies avec format de ressource sont les suivants :

Attribut Description
path Tableau de préfixes de chemin d’accès URL qui font référence à un point de terminaison d’API spécifique. Par exemple, /api/v1/products/.
method Tableau de méthodes HTTP. Les valeurs autorisées sont GET, PUT, POST ou DELETE. Le trafic est sélectionné si l’URI de la demande entrante correspond à l’un des chemins et à l’une des méthodes répertoriées. Si la méthode n’est pas spécifiée, le chemin seul est utilisé pour les critères de sélection du trafic.
provider Spécifie le mécanisme d’authentification qui doit être utilisé. Si le mécanisme d’authentification n’est pas fourni, l’authentification n’est pas effectuée.

Les attributs suivants concernent les stratégies d’authentification avec format d’expression :

Attribut Description
expression Spécifie l’expression Citrix ADC à évaluer en fonction de l’authentification
provider Spécifie le mécanisme d’authentification qui doit être utilisé. Si le mécanisme d’authentification n’est pas fourni, l’authentification n’est pas effectuée.

Remarque :

Si vous souhaitez ignorer l’authentification pour un point de terminaison spécifique, créez une stratégie avec l’attribut provider défini comme liste vide. Dans le cas contraire, la demande est refusée.

Stratégies d’autorisation

Les stratégies d’autorisation vous permettent de définir les critères de sélection du trafic pour appliquer les exigences d’autorisation pour le trafic sélectionné.

La stratégie d’autorisation prend en charge deux formats grâce auxquels vous pouvez spécifier les règles d’autorisation :

  • format de ressource
  • format d’expression

Voici les attributs des stratégies d’autorisation avec format de ressource :

Attribut Description
path Tableau de préfixes de chemin d’accès URL qui font référence à un point de terminaison d’API spécifique. Par exemple, /api/v1/products/.
method Tableau de méthodes HTTP. Les valeurs autorisées sont GET, PUT, POST ou DELETE.
claims Spécifie les revendications requises pour accéder à un point de terminaison d’API spécifique. name indique le nom de la revendication et values indique les autorisations requises. Vous pouvez présenter plus d’une réclamation. Si une liste vide est spécifiée, cela implique que l’autorisation n’est pas requise.
  Remarque : Toute revendication qui doit être utilisée pour l’autorisation doit être enregistrée dans le cadre de l’authentification.

Voici les attributs des stratégies d’autorisation au format d’expression :

Attribut Description
expression Spécifie une expression à évaluer pour l’autorisation.

Remarque :

Citrix ADC nécessite à la fois des stratégies d’authentification et d’autorisation pour le trafic d’API. Par conséquent, vous devez configurer une stratégie d’autorisation avec une stratégie d’authentification. Même si vous n’avez aucune vérification d’autorisation, vous devez créer une stratégie d’autorisation avec des revendications vides. Sinon, la demande est refusée avec une erreur 403.

Remarque :

L’autorisation aboutirait si la demande entrante correspond à une stratégie (chemin, méthode et revendications). Toutes les stratégies sont essayées jusqu’à ce qu’il y ait une correspondance. S’il est nécessaire de contourner sélectivement l’autorisation pour un point de terminaison spécifique, une stratégie explicite doit être créée.

Déployer le CRD d’authentification

Effectuez les opérations suivantes pour déployer le CRD d’authentification :

  1. Téléchargez le CRD (auth-crd.yaml).

  2. Déployez le CRD d’authentification à l’aide de la commande suivante :

    kubectl create -f auth-crd.yaml
    

    Par exemple :

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

Comment écrire des stratégies d’authentification et d’autorisation

Après avoir déployé le CRD fourni par Citrix dans le cluster Kubernetes, vous pouvez définir la configuration de la stratégie d’authentification dans un .yaml fichier. Dans le fichier .yaml, utilisez authpolicy dans le champ kind et dans la section spec, ajoutez les attributs de CRD d’authentification en fonction de vos besoins pour la configuration de la stratégie.

Après avoir déployé le fichier .yaml, le Citrix ingress controller applique la configuration de stratégie d’authentification sur l’appareil Citrix ADC d’entrée.

Fournisseur d’authentification local

Voici un exemple de définition de stratégie d’authentification et d’autorisation pour le type 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: []

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue l’authentification locale sur les demandes adressées aux éléments suivants :
    • OpérationGET ou POST sur les commandes et les points de terminaison d’expédition.
  • Citrix ADC n’effectue pas l’authentification pour l’opération GET sur le point de terminaison du produit .
  • Citrix ADC n’applique aucune autorisation d’autorisation.

Vérification OAuth JWT

Voici un exemple de définition de stratégie d’authentification et d’autorisation pour la vérification JWT OAuth (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: []

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue une vérification JWT sur les demandes adressées aux éléments suivants :

    • L’opération GET ou POST sur les commandes et les points de terminaison d’expédition .
  • Citrix ADC ignore l’authentification pour l’opération GET sur le point de terminaison du produit .

  • Citrix ADC nécessite la revendication de portée avec les autorisations read et write pour l’opération POST sur les commandes et les points de terminaison d’expédition .

  • Citrix ADC nécessite la revendication d’étendue avec l’autorisation de lecture pour l’opération GET sur le point de terminaison des commandes .

  • Citrix ADC n’a pas besoin d’autorisations pour l’opération GET sur le point de terminaison d’expédition .

Pour OAuth, si le jeton est présent dans un en-tête personnalisé, il peut être spécifié à l’aide de l’attribut token_in_hdr comme suit :

      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”]

De même, si le jeton est présent dans un paramètre de requête, il peut être spécifié à l’aide de l’attribut token_in_param comme suit :

      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”]

Introspection OAuth

Voici un exemple de définition de stratégie d’authentification et d’autorisation pour la vérification OAuth JWT. (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"]

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue l’introspection OAuth comme spécifié dans le fournisseur introspect-provider pour toutes les demandes.

  • Citrix ADC nécessite la revendication d’étendue avec read des write autorisations pour toutes les demandes POST .

  • Citrix ADC nécessite la revendication d’étendue avec l’autorisation de lecture pour toutes les demandes GET .

Création d’un objet secret avec des informations d’identification du client pour l’introspection

Un objet Secrets Kubernetes est nécessaire pour configurer l’introspection OAuth. Vous pouvez créer un objet secret de la même manière que dans l’exemple suivant :

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

Remarque :

Les clés de l’objet secret opaque doivent être client_id et client_secret. Un utilisateur peut définir les valeurs pour eux comme il le souhaite.

Authentification SAML via des formulaires

Voici un exemple d’authentification SAML à l’aide de formulaires. Dans l’exemple, authhost-tls-cert-secret et saml-tls-cert-secret les secrets TLS Kubernetes font référence au certificat et à la clé.

Remarque :

Lorsque certkey.cert et certkey.key sont respectivement certificat et clé pour l’hôte d’authentification, authhost-tls-cert-secret peut être formé à l’aide de la commande suivante :

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

De même, vous pouvez utiliser cette commande pour former saml-tls-cert-secret avec le certificat et la clé requis.


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-->

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue l’authentification SAML comme spécifié dans le fournisseur saml-auth-provider pour toutes les demandes. Remarque : L’authentification granulaire n’est pas prise en charge pour le mécanisme de formulaires.

  • Citrix ADC nécessite la revendication de groupe avec admin l’autorisation pour toutes les demandes POST .

  • Citrix ADC ne nécessite aucune autorisation spécifique pour les demandes GET .

Authentification OpenID Connect en utilisant des formulaires

Voici un exemple de création d’une authentification OpenID Connect pour configurer Citrix ADC dans un rôle Relaying Party (RP) afin d’authentifier les utilisateurs pour un fournisseur d’identité externe. La valeur authentication_mechanism doit être définie using_forms sur pour déclencher les procédures OpenID Connect.

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-->

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue l’authentification OIDC (partie de confiance) comme spécifié dans le fournisseur oidc-provider pour toutes les demandes.

    Remarque : L’authentification granulaire n’est pas prise en charge pour le mécanisme de formulaires.

  • Citrix ADC ne nécessite aucune autorisation d’autorisation.

Authentification LDAP via l’en-tête de demande

Voici un exemple d’authentification LDAP à l’aide de l’en-tête de demande.

Dans cet exemple, ldapcredential est le secret Kubernetes qui fait référence aux informations d’identification du serveur LDAP. Consultez le fichier ldap_secret.yaml pour plus d’informations sur la façon de créer des informations d’identification du serveur LDAP.


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-->

Remarque : Avec le mécanisme d’authentification basé sur l’en-tête de demande, l’authentification granulaire basée sur le trafic est prise en charge.

Authentification LDAP par formulaires

Dans l’exemple, authhost-tls-cert-secret est le secret TLS Kubernetes qui fait référence au certificat et à la clé.

Lorsque certkey.cert et certkey.key sont respectivement certificat et clé pour l’hôte d’authentification, authhost-tls-cert-secret peut être formé à l’aide de la commande suivante :

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

Dans cet exemple, ldapcredential est le secret Kubernetes qui fait référence aux informations d’identification du serveur LDAP. Consultez le fichier ldap_secret.yaml pour plus d’informations sur la façon de créer des informations d’identification du serveur LDAP.

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-->

L’exemple de définition de stratégie effectue les opérations suivantes :

  • Citrix ADC effectue l’authentification LDAP pour l’ensemble du trafic (toutes les demandes).
  • Citrix ADC n’applique aucune autorisation d’autorisation.

Voici un exemple pour LDAP_secret.yaml.

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

<!--NeedCopy-->

Exemple de prise en charge des expressions Citrix ADC avec Auth CRD

Cet exemple montre comment vous pouvez spécifier des expressions Citrix ADC ainsi que des stratégies d’authentification et d’autorisation :

  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")'
Stratégies d’authentification et d’autorisation pour Kubernetes avec Citrix ADC