Previous Articles covered walk-throughs for building an Apache JMeter Test Plan to apply load to an ArcGIS Enterprise map service such as SampleWorldCities. These were great to use as a primer for constructing a Test Plan to dynamically test a service, however they all assumed the remote endpoint was anonymously/publicly accessible. This is often not the case as many deployments will have some form of authentication in place. While one Article will not be enough cover every ArcGIS Enterprise authentication scenario, it will discuss a common one:
Note: While this Test Plan will be for use against a service that requires user authentication from the portal, it does not cover a similar but technically different scenario of utilizing Single Sign On (Integrated Windows Authentication) to automatically log in as the member running the testing software.
For simplicity, this Article will be building directly off the Test Plan used from Running an Apache JMeter Load Test from Command-line mode (Beginner/Intermediate) called sampleworldcities3.zip.
This Test Plan dynamically applied load to a publicly accessible ArcGIS Enterprise service called SampleWorldCities across four different map scales, each of which were an HTTP Request put into its own Transaction Controller. Many of the components of the test (e.g. Project Folder, Web Server Name, Service Name) were conveniently put into variables to make sharing and portability easy.
Simply put, sampleworldcities4 is based directly on the Test Plan of sampleworldcities3
Authentication will be done adding three parts to the Test Plan: more User Defined Variables, Authentication Requests to Acquire a Token, and the Token Support in the Map Request Headers.
Add additional User Defined Variables:
Note: Once the Test Plan is saved, Apache JMeter stores the username and password in plain text within the JMX file
Rename the value for the ProjectFolder User Defined Variable
Rename the values for the WebServerName, PortalInstanceName, and ServerInstanceName User Defined Variables
When you authenticate to an ArcGIS Enterprise Site from a web browser with a typical JavaScript application using built-in or domain member credentials there are several items sent back and forth from the client to the server in the process. These items appear in several HTTP requests and responses. While this traffic is made of many requests, the majority of them are calls for static content that are only needed for presentation (within the browser). The core authentication pieces, captured by logging into the REST endpoint of a deployment , are from three requests:
In the Test Plan, these three HTTP requests will be put into one Transaction Controller that make up the authentication logic. Additionally, Regular Expression Extractors will be used for each request to pull out specific information from the server's responses. Lastly, this will all be put into another logical container called the Once Only Controller. This becomes the first item in the test. As the name implies, anything grouped into this controller is executed only once per the lifetime of the test thread.
Note: The Once Only Controller is used because in this test case, it is not desired to authenticate and create a new token with every iteration of each test thread (this would carry to much overhead). But, since the authentication is not reissued during the run, the test duration needs to be less that the token expiration (4 hours as defined above).
This approach is just one type of test design, there can be different variations which purposely simulate a heavier load from token generation. For example, the defined username and password could optionally come from a CSV file to simulate different user credentials being used.
Despite the light-weight design of this Test Plan's token generation, a test that increases steps too quickly or increases pressure in large increments could still exert a decent amount of load as every new thread will request a token. In this case, a recommendation is to start small and increase the step load in small increments until a value is found that works for your system and your workflow.
Looking at the authentication logic in this Test Plan example there are variables but not much in terms of customizations. Therefore, screenshots are shown instead of textually listing out each step to build each HTTP Request and Regular Expression Extractor. The complete Test Plan can be downloaded at the end of this Article.
Responsible for generating an OAuthState response (implicit grant) from the server.
Used to capture the state into a variable called: oauthState
Responsible for passing in the credentials and oauth_state variables. If valid, these will generate the an AccessToken response from the server
Used to capture the item into a variable called: accessToken
Responsible for generating a token from the server.
Used to capture the item in a variable called: token
This variable is passed as an HTTP header to authenticate each request against the secured service.
Added to the token generation request to check for a specific string in the response. If the string "expires" is not found, then a token was generated and the entire transaction is marked as failed (having a failed request).
With the token variable populated from the Authentication logic, the HTTP headers for each secured map request can be expanded to include it under the name Cookie with the value: agstoken=${token}
Note: The HTTP Cookie Manager is not used in this Test Plan example
From a technical point of view, the token could have been passed in the request as a key/value pair, but for improved security, it is passed as an HTTP header.
To download the Apache JMeter Test Plan used in this Article see: sampleworldcities4.zip
Apache JMeter released under the Apache License 2.0. Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.