Authentification API avec l’appliance Citrix ADC
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.
Dans cet article
- Types de jetons
- Accès à l’API avec OAuth
- Serveur virtuel pour l’accès aux API
- Configuration OAuth pour les jetons d’ID
- Configuration OAuth pour les jetons d’accès opaques
- Stratégie de liaison à Authentication vserver
- Paramètres de sécurité supplémentaires sur une appliance Citrix ADC
- Contournement de certains trafic de l’authentification