In Authentification, autorisation et audit du trafic des applications
In Citrix ADC 13.0
In Citrix ADC
In All products
Documentation produit
In Authentification, autorisation et audit du trafic des applications
In Citrix ADC 13.0
In Citrix ADC
In All products
Citrix ADC
Current Release 12.1 11.1
Voir PDF

Authentification API avec l’appliance Citrix ADC

January 21, 2021
Contribution de: 
C

Il y a un changement de paradigme dans la façon dont les applications modernes interagissent avec leurs clients. Traditionnellement, les clients du navigateur étaient utilisés pour accéder aux services. Les applications définissent généralement des cookies de session pour suivre le contexte de l’utilisateur. Les applications modernes et distribuées rendent difficile la maintenance des sessions utilisateur sur les microservices. Pour cette raison, la plupart des accès à l’application sont devenus basés sur l’API. Les clients qui communiquent avec ces services distribués ont également évolué. La plupart des clients obtiennent des jetons d’une entité approuvée appelée Serveur d’autorisation pour prouver l’identité et l’accès de l’utilisateur. Ces clients présentent ensuite le jeton à l’application avec chaque demande d’accès. Par conséquent, les périphériques proxy traditionnels comme Citrix ADC doivent évoluer pour prendre en charge ces clients. Une appliance Citrix ADC permet aux administrateurs de gérer ce trafic. Citrix ADC peut être déployé en tant que passerelle API pour front-end tout le trafic destiné aux services publiés. Une passerelle API peut être déployée pour les environnements natifs traditionnels (hybride Multi Cloud ou HMC) ou Cloud. L’API Gateway met fin à tout le trafic entrant pour offrir plusieurs services tels que l’authentification, l’autorisation, la limitation de débit, le routage, la mise en cache, le déchargement SSL, le pare-feu d’application, etc. Par conséquent, il devient un élément essentiel de l’infrastructure.

Types de jetons

Les jetons échangés pendant l’accès à l’API sont généralement conformes au protocole OAuth/OpenID Connect (OIDC). Les jetons d’accès utilisés uniquement pour « accès délégué » sont conformes au protocole OAuth, tandis que les jetons d’ID qui sont conformes à OIDC contiennent également des informations utilisateur. Les jetons d’accès sont normalement un blob de données opaque ou aléatoire. Cependant, ils peuvent parfois être chantés jetons conformes aux normes JWT (Json Web Token). Les jetons d’ID sont toujours signés JWT.

Accès à l’API avec OAuth

Le type d’authentification OAuth sur une appliance Citrix ADC peut être utilisé pour gérer les protocoles OAuth et OIDC. OIDC est une extension du protocole OAuth.

OAuthAction sur une appliance Citrix ADC peut être utilisée pour gérer des clients interactifs tels que les navigateurs et les clients natifs tels que les applications clientes. Les clients interactifs sont redirigés vers Identity Provider pour se connecter à l’aide du protocole OIDC. Les clients natifs peuvent obtenir des jetons hors bande et peuvent présenter ces jetons sur une appliance Citrix ADC pour l’accès.

Remarque :

Le jeton d’accès obtenu à partir des points de terminaison peut être mis en cache pour les demandes suivantes, améliorant ainsi les performances de l’API.

Pour configurer la prise en charge de la mise en cache des jetons à l’aide de l’interface de ligne de commande, tapez la commande suivante à l’invite de commandes :


set aaaparameter –apITokenCache <ENABLED>

Les sections suivantes décrivent la méthode d’accès à l’API effectuée par les clients natifs.

Serveur virtuel pour l’accès aux API

Pour déployer une appliance Citrix ADC pour un accès API, un serveur virtuel de gestion du trafic (TM) est déployé avec l’authentification 401. Il est associé à un serveur virtuel d’authentification (authentification, autorisation et audit) pour contenir les stratégies d’authentification et de session. L’extrait de configuration suivant crée un tel serveur virtuel.

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

Remarque :

Vous devez lier un service au serveur TM vserver et une stratégie d’authentification (avec OAuthAction décrite comme suit) au serveur virtuel d’authentification pour terminer la configuration.

Après avoir créé le serveur virtuel, il faut ajouter une OAuthAction avec la stratégie correspondante. Il existe plusieurs autres options dans une action OAuth en fonction du type de jeton, et d’autres mécanismes de sécurité.

Configuration OAuth pour les jetons d’ID

Les jetons d’ID sont toujours signés JWT. C’est-à-dire qu’ils portent l’en-tête, la charge utile et la signature. Comme il s’agit de jetons autonomes, une appliance Citrix ADC peut valider ces jetons localement. Pour valider ces jetons, l’appliance doit connaître la clé publique de la clé privée correspondante utilisée pour signer ces jetons.

Voici un exemple de OAuthAction avec certains arguments obligatoires avec “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>

Où,

  • ID client — Chaîne unique qui identifie le SP. Le serveur d’autorisation infère la configuration du client à l’aide de cet ID. Longueur maximale : 127.

  • Client Secret — Chaîne secrète établie par l’utilisateur et le serveur d’autorisation. Longueur maximale : 239.

  • AuthorizationEndPoint - URL à laquelle les utilisateurs se connecteraient normalement (lors de l’utilisation de clients interactifs).

  • TokenEndPoint - URL sur le serveur d’autorisation à partir duquel les jetons/code sont obtenus/échangés

  • CertEndPoint - URL à laquelle le serveur d’autorisation publie les clés publiques utilisées pour signer les jetons. Le serveur d’autorisation peut publier plusieurs clés et choisir l’une d’entre elles pour signer des jetons.

Remarque : L’ID client/Client Secret/AuthorizationEndPoint/TokenEndpoint sont des paramètres facultatifs pour l’accès à l’API. Toutefois, il est recommandé de fournir des valeurs pour ces paramètres, car l’entité d’action peut être réutilisée à des fins différentes.

Dans la configuration précédente, ‘CertendPointPoint’ est essentiel pour la validation du jeton d’ID. Ce point de terminaison contient les clés publiques du certificat utilisé pour signer les jetons. Ces clés publiques doivent correspondre à la spécification JWK (Json Web Keys).

Une fois que CertendPoint est configuré au niveau de l’appliance Citrix ADC, il interroge périodiquement le point de terminaison (avec l’intervalle par défaut d’un jour pouvant être personnalisable dans la configuration) pour maintenir les clés publiques à jour. Une fois les clés publiques disponibles, ADC peut effectuer la validation locale des jetons d’ID entrants.

Configuration OAuth pour les jetons d’accès opaques

Les jetons opaques ne peuvent pas être vérifiés localement sur l’appliance Citrix ADC. Ceux-ci doivent être validés sur le serveur d’autorisation. Une appliance Citrix ADC utilise le « protocole d’introspection » mentionné dans les spécifications OAuth afin de vérifier ces jetons. Une nouvelle option, IntroSpectURL, est fournie dans la configuration OAuth pour vérifier les jetons opaques.


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

Le format de l’API introspection est conforme à la spécification https://tools.ietf.org/html/rfc7662#section-2.1 comme suit :


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

Stratégie de liaison à Authentication vserver

Une fois OAuthAction créé, la stratégie correspondante doit être créée pour l’appeler.


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

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

Paramètres de sécurité supplémentaires sur une appliance Citrix ADC

La validation des jetons inclut des vérifications de durée de vie des jetons. Les jetons en dehors de la durée acceptable sont rejetés. Voici les paramètres supplémentaires pour une sécurité supplémentaire. Certains d’entre eux sont recommandés pour être configurés toujours.

Audience : OAuth Action peut être configurée avec un destinataire prévu du jeton. Tous les jetons sont mis en correspondance avec cette URL configurée. Une appliance Citrix ADC dispose d’une fonctionnalité supplémentaire dans laquelle le champ d’audience pointe réellement vers un modèle défini sur l’appliance. À l’aide de ce jeu de modèles, un administrateur peut configurer plusieurs URL pour l’audience.


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

Dans l’exemple précédent, plusieurs audiences sont spécifiées dans un jeu de motifs. Par conséquent, un jeton entrant n’est autorisé que s’il contient l’une des URL configurées dans le jeu de motifs.

Émetteur : Identité du serveur dont les jetons doivent être acceptés. Longueur maximale : 127. Il est recommandé de configurer l’émetteur des jetons dans l’action OAuth. Cela garantit que les jetons émis par un serveur d’autorisation incorrect ne sont pas autorisés.

SkewTime : spécifie l’inclinaison d’horloge autorisée en nombre de minutes qu’une appliance Citrix ADC autorise sur un jeton entrant. Par exemple, si SkewTime est 10, alors le jeton sera valide de (heure actuelle - 10) min à (heure actuelle + 10) min, c’est-à-dire 20 min en tout. Valeur par défaut : 5

AllowedAlgorithms : Cette option permet à l’administrateur de restreindre certains algorithmes dans les jetons entrants. Par défaut, toutes les méthodes prises en charge sont autorisées. Cependant, ces derniers peuvent être contrôlés en utilisant cette option.

La configuration suivante garantit que seuls les jetons utilisant RS256 et RS512 sont autorisés :


set oAuthAction oauth-api-access -allowedAlgorithms RS256 RS512

Après la configuration ci-dessus, seuls les jetons qui utilisent RS256 et RS512 sont autorisés.

Contournement de certains trafic de l’authentification

Dans de nombreux cas, certaines API de découverte sont accessibles publiquement aux clients. Ces API révèlent généralement la configuration et les capacités du service lui-même. Un administrateur peut configurer l’appliance Citrix ADC pour contourner l’authentification à partir de ces URL de métadonnées à l’aide de la stratégie « Aucune authentification » décrite comme suit :


add authentication policy auth-bypass-policy -rule <> -action NO_AUTHN

bind authentication vserver auth-api-access -policy auth-bypass-policy -pri 110

NO_AUTHN est une action implicite qui entraîne la fin de l’authentification lorsque la règle correspond. Il existe d’autres utilisations de l’action NO_AUTHN au-delà de la portée de l’accès à l’API.

Authentification API avec l’appliance Citrix ADC
January 21, 2021
Contribution de: 
C
January 21, 2021
Contribution de: 
C

Dans cet article