Load tests a Shibboleth Identity Provider (v4 and v5): metadata, SP-initiated SSO in both bindings, passive and forced login, unknown and malformed requests, single logout, unsolicited SSO, the status page, a login spike and a capacity ramp.
It holds 32 ready-made jobs: 14 single scenarios and an enterprise test plan of 18 stages to run in order, 16 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include IdP metadata, IdP metadata (cache bypass), SP-initiated SSO (HTTP-Redirect binding), SP-initiated SSO (HTTP-POST binding) and passive SSO (IsPassive).
How to load test Shibboleth IdP
Open the template in BLASTA.
Set metadataUrl, ssoUrl, sloUrl, spEntityId, acsUrl, idpInitiatedUrl and statusUrl to point at your own Shibboleth IdP system, ideally a staging copy.
Pick a job and choose the rate and duration.
Start the run and watch requests per second, latency percentiles and errors live; the result is saved to your history.
What you set before running
metadataUrl
URL of the IdP's SAML metadata
ssoUrl
The IdP single sign-on URL (HTTP-Redirect / POST binding)
sloUrl
The IdP single logout URL
spEntityId
Entity ID of a service provider registered at the IdP
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. The start of every SAML login: the IdP parses the request, looks up the SP and shows a login page or continues an existing session. Redirects are not followed.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Same login, sent as a form POST. Some IdPs handle the two bindings in different code paths.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Must answer WITHOUT showing a login page: either a response or a NoPassive status. Used by silent session checks.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Ignores the existing session and demands a fresh login: the login page is rendered every time.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Error path: an unregistered entity ID must be refused cheaply with an error page, never redirected to its ACS URL.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Logout of a session that does not exist: should return a logout response or an error page quickly. The SP also needs a single-logout URL registered at the IdP: in testing, a Keycloak client without one answered 500 ('uri parameter is null') instead of a clean error, which this job will show as errors.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Everyone logs in at 09:00. Reaches a high rate in ten seconds and holds, then watch recovery.
The AuthnRequest is generated when you render this template, unsigned, with a fresh ID and the current time: render it shortly before the run, and register the SP entity ID at the IdP first. Slow ramp to find the rate where the IdP's latency climbs. Staging only.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Sends Connection: close, so every request pays for a new TCP and TLS handshake: the cost for clients that do not reuse connections (scripts, some mobile SDKs, health checkers). Shows load balancer and TLS termination limits. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Same request identified as a search crawler. Tests WAF and bot-management rules and whether crawlers get cached or origin responses. Crawlers can easily be a third of all traffic. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Adds a 4 KB Cookie header, like a logged-in user with many tracking cookies. Proxies and servers reject headers around 8 KB, so this shows how close you are to that limit. Reference request: SP-initiated SSO (HTTP-Redirect binding).
A fleet of synthetic monitors checking the URL with HEAD requests every 30 seconds from 20 locations, plus load balancer probes. Cheap each, constant in total. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Every employee opens their SAML-protected apps at the start of the day. Ramps SP-initiated logins to eight times normal over 60 seconds. Reference request: SP-initiated SSO (HTTP-Redirect binding).
Same login via the POST binding, which some SPs use exclusively. Three times normal for 10 minutes. Reference request: SP-initiated SSO (HTTP-POST binding).
Single logout requests arrive in a wave when sessions time out together. Three times normal for 10 minutes. Reference request: single logout request (HTTP-Redirect).
Frequently asked questions
What does the Shibboleth IdP load test cover?
The Shibboleth IdP template has 32 jobs: 14 single scenarios and an enterprise test plan of 18 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include IdP metadata, IdP metadata (cache bypass), SP-initiated SSO (HTTP-Redirect binding) and SP-initiated SSO (HTTP-POST binding). 16 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
How do I load test Shibboleth IdP with BLASTA?
Open the template in BLASTA and set metadataUrl, ssoUrl, sloUrl, spEntityId, acsUrl, idpInitiatedUrl and statusUrl, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new shibboleth-idp with your address.
Is it safe to run the Shibboleth IdP load test against production?
All 32 jobs in this template are read-only: they request pages or data and do not change anything. Even so, a load test can slow a live system down, so start with a low rate and prefer a staging copy. Only test systems you own or have permission to test.
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Load generator resources
CPU used by BLASTA % of capacity
RAM used by BLASTA
Requests per second
Latency p95 lower is better
Response time
Status codes
Errors
Pick a template
Ready-made jobs for common systems. Search by system, protocol or what you want to test
(wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.