Soak Testing for Keyclock using JMeter

The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behaviour and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. 

Apache JMeter may be used to test performance both on static and dynamic resources, Web dynamic applications. 
It can be used to simulate a heavy load on a server, group of servers, network or object to test its strength or to analyze overall performance under different load types.

Apache JMeter features include:

• Ability to load and performance test many different applications/server/protocol types:
  • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP / REST Webservices
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail - SMTP(S), POP3(S) and IMAP(S)
  • Native commands or shell scripts
  • TCP
  • Java Objects

Soak Testing is a non-functional testing in which, the System under Load (SUL) is tested & verified so that it can withstand a huge volume of the load for an extended period of time. Soak testing is running a system at high levels of the load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) that would be expected in a busy day, to identify any performance problems that appear after a large number of transactions have been executed.

Also, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed due to memory leaks or other defects. Soak tests provide an opportunity to identify such defects, whereas load tests and stress tests may not find such problems due to their relatively short duration.

A system may behave normally when used for 2 hours, but when the same system is used continuously for 10 hours or more than that then it may fail or behave abnormally/randomly/it may crash. To predict such failure Soak Testing is performed.

• Serious memory leaks that would eventually result in a memory crisis.
• Failure to close connections between tiers of a multi-tiered system under some circumstances which could stall some or all modules of the system.
• Failure to close database cursors under some conditions which would eventually result in the entire system stalling.
• The gradual degradation of the response time of some functions as internal data-structures become less efficient during a long test.

• The duration of most Soak Test is often determined by the time available.
• Any application must run without any interruption if it requires an extended period of time.
• Mostly every system has a regular maintenance window time period and the time between such window periods is a key driver for determining the scope of a Soak Test

Authentication is the identification of a user or service by the system. We use Keycloak as an OpenID Connect and OAuth2 identification service which is currently backed by a MySQL database running on a dedicated Azure Virtual Machine. Users that are accessing the system using a browser, whether or desktop or on mobile, use the OpenID Connect(OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. It provides information about the end user in the form of an id_token that verifies the identity of the user and provides basic profile information about the user.) flow to login.

Authentication is handled at the API Gateway layer so all requests to our services have the security principal information available in the request headers.

1. The user's browser attempts to access the application via Apache with no session present
2. The Apache configuration for the URL being accessed is checked and if the location has "AuthType openid-connect" and "Require valid-user" requirements then mod_auth_openidc redirects the browser to Keycloak using a 302 redirect plus a URL parameter of the page where to return to after authenticating (the redirect URL)
3. The browser then displays the Keycloak login page where the user enters credentials
4. Assuming that the credentials are correct, Keycloak redirects the browser to the redirect URL provided in step 2 along with an authorisation code and an opaque session cookie
5. The browser then connects to Apache and provides an authorisation code along with the session cookie.
6. mod_auth_openidc takes the authorisation code and passes it to Keycloak
7. Keycloak exchanges the code for an access token.  This token is a JWT token which contains information about the user (username, email, etc) and their entitlements (roles and groups) that mod_auth_openidc can use along with the Apache permission rules to determine if the user is allowed access to that URL for that HTTP method (GET, POST, etc).  A session is also started by mod_auth_openidc that is used to cache the information from the access token to avoid having to make a callback to Keycloak on every access.  It also stores the refresh token, which is used to get a new access token when it expires
8. Assuming that access is allowed, Apache forwards the original request to the back end along with all of the claims of the JWT passed as HTTP headers (such as OIDC_CLAIM_username, OIDC_CLAIM_groups, etc).  One of these claims is the Keycloak access token, which can be used by the back end service to authenticate the user to other services
9. The back-end service uses the OIDC_CLAIM_* headers to implement any fine-grained permissions (such as restricting a trainee to seeing only their own records) and returns the appropriate data
10. Apache returns the data to the user