Using Apache JMeter to Load Test an ArcGIS Enterprise Authenticated Service (Intermediate/Advanced)
Why Add Authentication to a Test Plan?
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:
- The composition of a Test Plan for a secured service that requires a token from a built-in portal member or domain member
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.
Getting Started
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.
Creating the sampleworldcities4 Test Plan
Simply put, sampleworldcities4 is based directly on the Test Plan of sampleworldcities3
- Download the sampleworldcities3.zip Test Plan
- Unzip sampleworldcities3.zip
- From the file system, make a copy of the sampleworldcities3 folder and name it sampleworldcities4
- Open the sampleworldcities4 folder and rename the sampleworldcities3.jmx file to sampleworldcities4.jmx
- This procedure assumes the Test Plan will be stored in C:\JMeter Tests\
- From within JMeter, open the "new" sampleworldcities4.jmx test
Extending the Test Plan to Add Authentication Support
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.
User Defined Variables
Add additional User Defined Variables:
- Click on the Test Plan (e.g. sampleworldcities4)
- By default, this should be selected when a new Test Plan is opened
- At the bottom of the User Defined Variables Section, click Add
- For Name enter: Username
- For Value enter: username
- Enter a username of a member within the portal that has been authorized to consume the SampleWorldCities map service
- If the user is a domain member, enter domain\username
- For Value enter: username
- For Name enter: Password
- For Value enter: password
- Enter the password associated with the username above
- For Value enter: password
- For Name enter: TokenExpirationMinutes
- For Value enter: 240
- This will generate tokens with a 4 hour expiration
- This can be adjusted as needed, but a typical test does not exceed this duration
- For Value enter: 240
- For Name enter: Username
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 Value contents from: C:\JMeter Tests\sampleworldcities3
- To: C:\JMeter Tests\sampleworldcities4
- If Test Plan resides in another location, please adjust as needed
- To: C:\JMeter Tests\sampleworldcities4
Rename the values for the WebServerName, PortalInstanceName, and ServerInstanceName User Defined Variables
- Rename the Value contents as needed
Authentication Requests to Acquire a Token
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:
- OAuthState
- AccessToken
- Token
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.
OAuthState HTTP Request
Responsible for generating an OAuthState response (implicit grant) from the server.
OAuthState Regular Expression Extractor
Used to capture the state into a variable called: oauthState
AccessToken HTTP Request
Responsible for passing in the credentials and oauth_state variables. If valid, these will generate the an AccessToken response from the server
AccessToken Regular Expression Extractor
Used to capture the item into a variable called: accessToken
Token HTTP Request
Responsible for generating a token from the server.
Token Regular Expression Extractor
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.
Token Response Assertion
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).
Token Support in the Map Request Headers
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.
Validating the Test Plan
- Ensure the View Results Tree is enabled and Start the test (e.g. the green arrow) to validate the responses.
- The green check marks for all parts of the Authentication indicate that a valid token was obtained from the provided credentials
- The image from the export map calls indicate that a request was successfully issued for the secured service
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.