Authentification par API avec l’appliance NetScaler
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 installent des cookies de session pour suivre le contexte de l’utilisateur. Les applications modernes et distribuées compliquent la gestion des sessions utilisateur entre les microservices. De ce fait, la plupart des accès aux applications sont désormais basés sur des API. Les clients qui communiquent avec ces services distribués ont également évolué. La plupart des clients obtiennent des jetons auprès d’une entité de confiance appelée Serveur d’autorisation pour prouver l’identité et l’accès des utilisateurs. Ces clients présentent ensuite le jeton à l’application à chaque demande d’accès. Par conséquent, les appareils proxy traditionnels tels que NetScaler doivent évoluer pour prendre en charge ces clients. Une appliance NetScaler permet aux administrateurs de gérer ce trafic. NetScaler peut être déployé en tant que passerelle d’API pour gérer tout le trafic destiné aux services publiés. Une passerelle d’API peut être déployée pour des environnements traditionnels (multicloud hybride ou HMC) ou natifs du cloud. La passerelle API met fin à tout le trafic entrant pour proposer plusieurs services tels que l’authentification, l’autorisation, la limitation du débit, le routage, la mise en cache, le déchargement SSL, le pare-feu des applications, etc. Il devient donc un élément essentiel de l’infrastructure.
Types de jetons
Les jetons échangés lors de 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 un « accès délégué » sont conformes au protocole OAuth, tandis que les jetons d’identification conformes à l’OIDC contiennent également des informations sur les utilisateurs. Les jetons d’accès sont généralement des blobs de données opaques ou aléatoires. Cependant, il peut parfois s’agir de jetons signés conformes aux normes JWT (JSON Web Token). Les jetons d’identification sont toujours des JWT signés.
Accès à l’API avec OAuth
Le type d’authentification OAuth sur une appliance NetScaler peut être utilisé pour gérer à la fois les protocoles OAuth et OIDC. OIDC est une extension du protocole OAuth.
OAuthAction sur une appliance NetScaler peut être utilisé pour gérer des clients interactifs tels que des navigateurs et des clients natifs tels que des applications clientes. Les clients interactifs sont redirigés vers le fournisseur d’identité pour se connecter à l’aide du protocole OIDC. Les clients natifs peuvent obtenir des jetons hors bande et peuvent les présenter à une appliance NetScaler pour y accéder.
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>
<!--NeedCopy-->
Les sections suivantes décrivent la méthode d’accès à l’API exécutée par les clients natifs.
Serveur virtuel pour l’accès aux API
Pour déployer une appliance NetScaler pour un accès à une 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 héberger les stratégies d’authentification et de session. L’extrait de configuration suivant crée l’un de ces serveurs virtuels.
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
<!--NeedCopy-->
Remarque :
vous devez lier un service au serveur virtuel de gestion du trafic et une stratégie d’authentification (avec OAuthAction décrit 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 au sein d’une action OAuth en fonction du type de jeton et d’autres mécanismes de sécurité.
Configuration OAuth pour les jetons d’identification
Les jetons d’identification sont toujours des JWT signés. C’est-à-dire qu’ils portent un en-tête, une charge utile et une signature. Comme il s’agit de jetons autonomes, une appliance NetScaler 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 d’OAuthAction avec certains arguments obligatoires ainsi que « 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 <URL at which public keys of IdP are published>
<!--NeedCopy-->
Où,
-
Client ID : chaîne unique qui identifie le fournisseur de services. Le serveur d’autorisation déduit la configuration du client en utilisant 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 connectent normalement (lorsqu’ils utilisent des clients interactifs).
-
TokenEndpoint : URL sur le serveur d’autorisation sur laquelle les jetons/le 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 les jetons.
Remarque :
Client ID/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 à différentes fins.
Dans la configuration précédente, « CertEndpointPoint » est essentiel pour la validation du jeton d’identification. 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 JWKs (JSON Web Keys).
Une fois que le CertEndpoint est configuré sur l’appliance NetScaler, il interroge régulièrement le point de terminaison (avec un intervalle par défaut d’un jour qui peut être personnalisé dans la configuration) pour maintenir les clés publiques à jour. Une fois les clés publiques disponibles, ADC peut effectuer une validation locale des jetons d’identification entrants.
Configuration OAuth pour les jetons d’accès opaques
Les jetons opaques ne peuvent pas être vérifiés localement sur l’appliance NetScaler. Ils doivent être validés sur le serveur d’autorisation. Une appliance NetScaler utilise le « protocole d’introspection » mentionné dans les spécifications OAuth pour 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 <URL of the Authorization Server for introspection>
<!--NeedCopy-->
Le format de l’API d’introspection est conforme à la spécification https://tools.ietf.org/html/rfc7662#section-2.1 suivante :
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
<!--NeedCopy-->
Stratégie de liaison au serveur virtuel d’authentification
Une fois OAuthAction créé, une stratégie correspondante doit être créée pour l’invoquer.
add authentication policy oauth-api-access -rule <> -action <oauth-api-access>
bind authentication vserver auth-api-access -policy oauth-api-access -pri 100
<!--NeedCopy-->
Paramètres de sécurité supplémentaires sur une appliance NetScaler
La validation des jetons inclut la vérification de la durée de vie des jetons. Les jetons en dehors du délai acceptable sont rejetés. Vous trouverez ci-dessous les paramètres supplémentaires pour une sécurité accrue. Il est recommandé de toujours configurer certains d’entre eux.
Public : l’action OAuth peut être configurée avec le destinataire prévu du jeton. Tous les jetons sont comparés à cette URL configurée. Une appliance NetScaler possède une fonctionnalité supplémentaire selon laquelle le champ d’audience pointe réellement vers un modèle défini sur l’appliance. À l’aide de cet ensemble 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 oAuthAction oauth-api-access -audience oauth_audiences
<!--NeedCopy-->
Dans l’exemple précédent, plusieurs audiences sont spécifiées dans un ensemble de modèles. Par conséquent, un jeton entrant n’est autorisé que s’il contient l’une des URL configurées dans le jeu de modèles.
É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 le mauvais serveur d’autorisation ne sont pas autorisés.
SkewTime : Spécifie le décalage d’horloge autorisé en nombre de minutes qu’une appliance NetScaler autorise sur un jeton entrant. Par exemple, si SkewTime est 10, le jeton sera valide de (heure actuelle - 10) min à (heure actuelle + 10) min, soit 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, vous pouvez les contrôler à l’aide de 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
<!--NeedCopy-->
Une fois la configuration ci-dessus effectuée, seuls les jetons utilisant RS256 et RS512 sont autorisés.
Contourner l’authentification à certains trafics
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 fonctionnalités du service lui-même. Un administrateur peut configurer l’appliance NetScaler pour contourner l’authentification à partir de ces URL de métadonnées en utilisant 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
<!--NeedCopy-->
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 qui dépassent le cadre 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’identification
- Configuration OAuth pour les jetons d’accès opaques
- Stratégie de liaison au serveur virtuel d’authentification
- Paramètres de sécurité supplémentaires sur une appliance NetScaler
- Contourner l’authentification à certains trafics