Web Services, SOAP, Authentication, Tokens, and Session Workflows: Core Concepts and Mental Model

1. The practical problem: authentication can become the workload

A business scenario may call the identity service once, then make 50 authenticated API calls. If the JMeter tree puts Login inside the same inner loop as every business request, the test now sends 50 logins per user. Identity latency, password verification, token minting, rate limits, and account lock policies can dominate the result.

The opposite error is also common: one token is placed in a global property and 100 threads reuse it. That may violate the application's session model and create artificial serialization or token invalidation.

2. Mental model: identity lifecycle per virtual user

flowchart TD
C[Fake credential row] --> L[POST /auth/login]
L --> J[JSON token/session response]
L --> K[Set-Cookie LABSESSION]
J --> X[Extract ACCESS_TOKEN / REFRESH_TOKEN / SESSION_ID]
K --> CM[HTTP Cookie Manager thread-local jar]
X --> H[Authorization header from ACCESS_TOKEN]
CM --> P[Protected JSON / SOAP samplers]
H --> P
P --> E[Access-token use budget expires]
E --> F[401 token_expired evidence]
F --> R[POST /auth/refresh]
R --> X2[Replace access + refresh variables]
X2 --> P2[Protected work succeeds again]
P2 --> O[Logout / session invalidation]
P --> A[JTL + jmeter.log]
P --> S[Redacted target event log]

The fake credential row is input data. Login creates target-side session state and returns token values; JMeter extracts those values into the current thread while HTTP Cookie Manager stores that thread's session cookie. Protected samplers combine the current bearer token with the current thread's cookie. The fixture deliberately expires access tokens after a small use budget. Refresh rotates token values without changing user/session ownership. Logout invalidates target-side session state. JTL records sample results, while the target event log stores only token fingerprints and a redacted Authorization marker.

3. Identity state belongs to a thread

JMeter variables such as ACCESS_TOKEN, REFRESH_TOKEN, and SESSION_ID are thread-local. HTTP Cookie Manager also keeps server cookies per JMeter thread. This is the natural model for independent virtual users.

A JMeter property used as one shared mutable token is process-global and is the wrong store for per-user access tokens unless the real system genuinely uses one shared service identity.

4. HTTP Authorization Manager is a different authentication layer

HTTP Authorization Manager is for server/proxy authentication where the HTTP client performs Basic, Digest, or Kerberos-style authentication. It can use variables for per-thread usernames/passwords. Direct passwords in its table are stored unencrypted in the JMX.

This chapter's application login is different: POST JSON credentials → receive bearer/refresh tokens → use those application tokens. Therefore the mandatory plan uses ordinary HTTP Request + Header Manager + extractors rather than Authorization Manager.

5. Cookie session and bearer token are independent pieces of state

The local service requires both a LABSESSION cookie managed by HTTP Cookie Manager and an Authorization: Bearer ${ACCESS_TOKEN} header on protected samplers. If either belongs to another user/session, the target returns 401. This makes cross-thread leakage observable.

6. Access token, refresh token, and expiry

An access token authorizes business calls and is short-lived in the fixture. A refresh token is used only to obtain a new access token for the same session. After refresh, both token variables rotate.

Do not put tokens into query strings. URLs are more likely to appear in logs, proxies, browser history, metrics, or JTL when URL saving is enabled.

7. SOAP is XML over a protocol contract

SOAP 1.1 messages use an XML Envelope/Body namespace. The authenticated lab request contains the current thread's session ID:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:m="urn:devops-academy:auth">
  <soap:Body>
    <m:GetAccountSummary>
      <m:SessionId>${SESSION_ID}</m:SessionId>
    </m:GetAccountSummary>
  </soap:Body>
</soap:Envelope>

The target verifies bearer token + Cookie Manager session + XML SessionId alignment.

8. XML well-formedness versus SOAP business semantics

XML Assertion checks that the response is formally well-formed XML. It does not prove that the SOAP Body contains the correct user/session/auth state.

Use namespace-aware XPath2 Assertion for semantics:

Namespace aliases:
soap=http://schemas.xmlsoap.org/soap/envelope/
m=urn:devops-academy:auth

Expression:
boolean(
  /soap:Envelope/soap:Body/
  m:AccountSummaryResponse/
  m:AuthState[text()='valid']
)

9. State to define before changing auth flow

10. Non-destructive inspection first

• Inspect fake credential row count and thread count before login load.
• Inspect Cookie Manager count/scope and Clear Cookies Each Iteration behavior.
• Inspect Header Managers for literal Authorization values.
• Inspect JTL save configuration: keep request/response headers, samplerData, and response bodies disabled for load.
• Inspect token TTL/refresh rules in the target contract.
• Inspect SOAP namespaces/action/media type from WSDL/service docs or the local fixture contract.
• Run one-thread GUI validation before any concurrent profile.

11. TLS is a trust boundary, not a workaround

Current JMeter HTTP behavior uses TLS as the default HTTPS protocol family and maintains SSL context per thread. If an authorized real service uses HTTPS, provision valid certificates/trust appropriately. Do not disable TLS verification, edit JVM disabled-algorithm constraints, or switch to insecure endpoints merely to make the test green.

The mandatory lab stays on loopback HTTP so authentication/session semantics can be learned without adding certificate administration to Chapter 15; Chapter 13 already covered recording/certificate trust.

12. Credential-safe result evidence

Current CSV result defaults do not save sampler data, request headers, response headers, or response bodies. Keep those defaults. Preserve label/time/success/response code/message/thread counts and assertion failure messages.

Never add ACCESS_TOKEN, REFRESH_TOKEN, password, or Cookie variables to sample_variables. The target fixture records only SHA-256 token fingerprints and Bearer <redacted>.

13. DevOps connection

Authentication is part of capacity architecture. A release gate must state whether login/token issuance is included, how many identities exist, how long sessions live, whether refresh occurs, what identity provider is authorized for load, and whether protected-service latency is analyzed separately from auth bootstrap.

Knowledge check

Official references and version notes

• Component Reference — HTTP Request, HTTP Cookie Manager, HTTP Authorization Manager, Header Manager, JSON JMESPath Extractor/Assertion, XML Assertion, XPath2 Extractor/Assertion, and result-scope semantics.
• Elements of a Test Plan — execution/scope and thread-local variable behavior.
• Getting Started — Java requirements, TLS/runtime basics, and GUI-versus-CLI guidance.
• Properties Reference — CSV result defaults, request/response header/body retention, TLS defaults, and HTTP client settings.
• Generating Dashboard Report — required result fields and dashboard interpretation.
• Best Practices — non-GUI load execution, listener restraint, and injector validity.
• Apache JMeter downloads — current stable release and Java requirement.