Pourquoi ajouter une authentification à un plan de test ?
Les articles précédents ont couvert des guides pour construire un plan de test Apache JMeter afin d'appliquer une charge à un service de carte ArcGIS Enterprise tel que SampleWorldCities. Ceux-ci étaient excellents pour servir d'introduction à la construction d'un plan de test pour tester dynamiquement un service, cependant ils supposaient tous que le point de terminaison distant était accessible anonymement/publiquement. Ce n'est souvent pas le cas car de nombreux déploiements auront une forme d'authentification en place. Bien qu'un seul article ne suffise pas à couvrir tous les scénarios d'authentification ArcGIS Enterprise, il discutera d'un scénario courant :
- La composition d'un plan de test pour un service sécurisé qui nécessite un token d'un membre intégré du portail ou d'un membre de domaine
Note : Bien que ce plan de test soit destiné à être utilisé contre un service nécessitant une authentification utilisateur depuis le portail, il ne couvre pas un scénario similaire mais techniquement différent d'utilisation du Single Sign On (Integrated Windows Authentication) pour se connecter automatiquement en tant que membre exécutant le logiciel de test.
Commencer
Pour simplifier, cet article s'appuiera directement sur le plan de test utilisé dans Exécution d'un test de charge Apache JMeter en mode ligne de commande (Débutant/Intermédiaire) appelé sampleworldcities3.zip.
Ce plan de test appliquait dynamiquement une charge à un service ArcGIS Enterprise accessible publiquement appelé SampleWorldCities à travers quatre échelles de carte différentes, chacune étant une requête HTTP placée dans son propre contrôleur de transaction. De nombreux composants du test (par exemple Dossier Projet, Nom du Serveur Web, Nom du Service) ont été commodément placés dans des variables pour faciliter le partage et la portabilité.
Création du plan de test sampleworldcities4
En termes simples, sampleworldcities4 est basé directement sur le plan de test de sampleworldcities3
- Téléchargez le plan de test sampleworldcities3.zip
- Décompressez sampleworldcities3.zip
- Depuis le système de fichiers, faites une copie du dossier sampleworldcities3 et nommez-le sampleworldcities4
- Ouvrez le dossier sampleworldcities4 et renommez le fichier sampleworldcities3.jmx en sampleworldcities4.jmx
- Cette procédure suppose que le plan de test sera stocké dans C:\JMeter Tests\
- Depuis JMeter, ouvrez le nouveau test sampleworldcities4.jmx
Extension du plan de test pour ajouter la prise en charge de l'authentification
L'authentification sera réalisée en ajoutant trois parties au plan de test : plus de variables définies par l'utilisateur, des requêtes d'authentification pour acquérir un token, et la prise en charge du token dans les en-têtes des requêtes cartographiques.
Variables définies par l'utilisateur
Ajoutez des variables définies par l'utilisateur supplémentaires :
- Cliquez sur le plan de test (par exemple sampleworldcities4)
- Par défaut, cela devrait être sélectionné lors de l'ouverture d'un nouveau plan de test
- En bas de la section Variables définies par l'utilisateur, cliquez sur Ajouter
- Pour Nom entrez : Username
- Pour Valeur entrez : username
- Entrez un nom d'utilisateur d'un membre du portail autorisé à consommer le service cartographique SampleWorldCities
- Si l'utilisateur est un membre du domaine, entrez domain\username
- Pour Nom entrez : Password
- Pour Valeur entrez : password
- Entrez le mot de passe associé au nom d'utilisateur ci-dessus
- Pour Nom entrez : TokenExpirationMinutes
- Pour Valeur entrez : 240
- Cela générera des tokens avec une expiration de 4 heures
- Cela peut être ajusté selon les besoins, mais un test typique ne dépasse pas cette durée
Note : Une fois le plan de test enregistré, Apache JMeter stocke le nom d'utilisateur et le mot de passe en texte clair dans le fichier JMX
Renommez la valeur pour la variable définie par l'utilisateur ProjectFolder
- Renommez le contenu Valeur de : C:\JMeter Tests\sampleworldcities3
- En : C:\JMeter Tests\sampleworldcities4
- Si le plan de test réside ailleurs, veuillez ajuster selon les besoins
Renommez les valeurs pour les variables définies par l'utilisateur WebServerName, PortalInstanceName et ServerInstanceName
- Renommez les contenus Valeur selon les besoins
Requêtes d'authentification pour acquérir un token
Lorsque vous vous authentifiez sur un site ArcGIS Enterprise depuis un navigateur web avec une application JavaScript typique utilisant des identifiants intégrés ou membres du domaine, plusieurs éléments sont échangés entre le client et le serveur durant ce processus. Ces éléments apparaissent dans plusieurs requêtes et réponses HTTP. Bien que ce trafic soit composé de nombreuses requêtes, la majorité sont des appels pour du contenu statique nécessaire uniquement à la présentation (dans le navigateur). Les éléments principaux d'authentification, capturés en se connectant au point REST d'un déploiement, proviennent de trois requêtes :
- OAuthState
- AccessToken
- Token
Dans le plan de test, ces trois requêtes HTTP seront placées dans un contrôleur de transaction qui constitue la logique d'authentification. De plus, des extracteurs d'expressions régulières seront utilisés pour chaque requête afin d'extraire des informations spécifiques des réponses du serveur. Enfin, tout cela sera placé dans un autre conteneur logique appelé Once Only Controller. Cela devient le premier élément du test. Comme son nom l'indique, tout ce qui est regroupé dans ce contrôleur est exécuté une seule fois pendant toute la durée du thread du test.
Note : Le Once Only Controller est utilisé car dans ce cas de test, il n'est pas souhaitable d'authentifier et créer un nouveau token à chaque itération de chaque thread (cela engendrerait trop de surcharge). Mais puisque l'authentification n'est pas renouvelée pendant l'exécution, la durée du test doit être inférieure à l'expiration du token (4 heures comme défini ci-dessus).
Cet approche est juste un type de conception de test ; il peut y avoir différentes variations qui simulent intentionnellement une charge plus lourde due à la génération des tokens. Par exemple, les noms d'utilisateur et mots de passe définis pourraient éventuellement provenir d'un fichier CSV pour simuler l'utilisation de différents identifiants utilisateurs.
Même avec la conception légère pour la génération des tokens dans ce plan de test, un test qui augmente trop rapidement les étapes ou augmente la pression par grands incréments pourrait toujours exercer une charge importante car chaque nouveau thread demandera un token. Dans ce cas, il est recommandé de commencer petit et augmenter la charge par petits incréments jusqu'à trouver une valeur adaptée à votre système et votre flux.
En regardant la logique d'authentification dans cet exemple de plan de test, il y a des variables mais peu en termes de personnalisations. Par conséquent, des captures d'écran sont montrées au lieu d'énumérer textuellement chaque étape pour construire chaque requête HTTP et extracteur d'expression régulière. Le plan complet peut être téléchargé à la fin de cet article.
Requête HTTP OAuthState
Responsable de générer une réponse OAuthState (implicit grant) depuis le serveur.
Extracteur d'expression régulière OAuthState
Utilisé pour capturer l'état dans une variable appelée : oauthState
src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/15861i91333328DCBFE08E\/oauthstate_regularexpressionextractor.png" role="button" title="oauthstate_regularexpressionextractor.png" alt="oauthstate_regularexpressionextractor.png" \/><\/span><\/SPAN><\/P>
Requête HTTP AccessToken<\/SPAN><\/H3>Responsable de la transmission des variables credentials et oauth_state. Si elles sont valides, elles généreront une réponse AccessToken du serveur<\/SPAN><\/P>
<\/span><\/SPAN><\/P>AccessToken <\/SPAN>Extracteur d'expressions régulières<\/SPAN><\/H3>Utilisé pour capturer l'élément dans une variable appelée : accessToken<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Requête HTTP Token<\/SPAN><\/H3>Responsable de la génération d'un token depuis le serveur.<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Token <\/SPAN>Extracteur d'expressions régulières<\/SPAN><\/H3>Utilisé pour capturer l'élément dans une variable appelée : token<\/SPAN><\/P>Cette variable est transmise en tant qu'en-tête HTTP pour authentifier chaque requête auprès du service sécurisé.<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Assertion de réponse Token<\/SPAN><\/H3>Ajoutée à la requête de génération de token pour vérifier une chaîne spécifique dans la réponse. Si la chaîne "expires" n'est pas trouvée, alors un token a été généré et toute la transaction est marquée comme échouée (avec une requête échouée).<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Support du Token dans les en-têtes de requête Map<\/SPAN><\/H2>Avec la variable token remplie par la logique d'Authentication, les en-têtes HTTP pour chaque requête map sécurisée peuvent être étendus pour l'inclure sous le nom Cookie avec la valeur : agstoken=${token}<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Note : Le HTTP Cookie Manager n'est pas utilisé dans cet exemple de Test Plan<\/STRONG>
D'un point de vue technique, le token aurait pu être transmis dans la requête en tant que paire clé-valeur, mais pour une meilleure sécurité, il est transmis en tant qu'en-tête HTTP.
Validation du Test Plan<\H1 >Assurez-vous que View Results Tree est activé et lancez le test (par exemple, la flèche verte) pour valider les réponses.Les coches vertes pour toutes les parties de l'Authentication indiquent qu'un token valide a été obtenu à partir des credentials fournis.<\LI >L'image des appels export map indique qu'une requête a été émise avec succès pour le service sécurisé <\LI ><\UL ><\LI ><\UL > 
<\span ><\P >Pour télécharger le Test Plan Apache JMeter utilisé dans cet Article, voir : <\SPAN >sampleworldcities4.zip <\A > <\P > <\P >
Apache JMeter <\A > publié sous la <\SPAN >Apache <\A > <\SPAN >Licence 2.0.<\A > Apache, Apache JMeter, JMeter, la plume Apache et le logo Apache JMeter sont des marques déposées de la Apache Software Foundation.<\SPAN ><\P > <\P >
