Skip to content
Dynamic SSO Configuration: No More Restarts to Update Your Identity Provider

Dynamic SSO Configuration: No More Restarts to Update Your Identity Provider

This is the fifth post in our "Features Sitting Idle" series, where we look at OctoPerf features that are already in your platform but often missed by the teams that would benefit the most.

This one is for IT teams running OctoPerf on-premise.

Features Sitting Idle - Dynamic SSO

"Updating Your SSO Config Shouldn't Require a Full Redeployment."

IT teams managing an on-premise OctoPerf instance regularly run into the same friction around SSO.

The pattern is so consistent that we've come to recognize it as a tell-tale sign that the team hasn't migrated to the new dynamic configuration introduced in version 15.

Want to become a super load tester?
Request a Demo

The Friction We See in Support

A few situations come up repeatedly:

  • Every configuration change costs an outage. Rotating a client secret, updating a redirect URI, switching identity providers requires editing the application.yml file and restarting the entire stack. On a shared platform, that means scheduling a service interruption.
  • Setup that stretches over weeks. SSO setup can stretch across several weeks when the configuration needs to be validated against an external identity provider, with each adjustment requiring a full restart cycle to take effect.
  • Cross-team dependencies on every tweak. Teams that need to involve infrastructure or security stakeholders for every SSO change, because the configuration lives in deployment files rather than in the admin interface.

The compounding effect is the real problem. A single change is fine. Ten changes during an integration project means the IT team is spending most of its week scheduling restart windows.

What Changed in v15.0

Since v15.0, OctoPerf Enterprise Edition stores OAuth2 / OpenID Connect configuration directly in Elasticsearch.

It's no longer a static file you deploy. It's a dynamic configuration, editable from the admin panel, with no restart required.

In practice:

  • Adding a new SSO provider
  • Rotating a client secret
  • Reconfiguring allowed scopes
  • Changing the redirect URI for a staging environment
  • Switching from one identity provider to another

All of these can be done from the admin interface, in real time, without touching YAML, and without service interruption.

OctoPerf supports Azure AD, Okta, and any OpenID Connect-compatible provider.

Backward Compatibility

The application.yml configuration remains supported for backward compatibility. Teams that have automated their deployments around the YAML approach don't need to migrate overnight.

But if you're still using application.yml to manage your SSO and you're not bound by a specific compliance constraint, the dynamic option is simply more flexible:

  • User account management lives in the same panel.
  • Active session management lives in the same panel.
  • SSO provider configuration lives in the same panel.

One place, one role, no shell access required.

A Realistic Migration Path

If you're on v15 or later but still relying on YAML, the migration is straightforward:

  1. Document the current application.yml SSO block.
  2. Recreate the same configuration in the admin panel.
  3. Validate end-to-end with a non-admin user account.
  4. Remove the SSO block from application.yml.
  5. Restart the stack one last time, and never again for an SSO change.

The whole operation typically takes less than an hour for a team that knows its current configuration.

Why It Matters

For an on-premise platform that supports performance testing campaigns, the cost of a restart is rarely "just five minutes". It's a coordination cost: notifying users, freezing in-flight tests, waiting for a window, communicating the all-clear.

Multiplying that cost by every SSO tweak during an integration is what makes SSO projects drag on. Dynamic SSO configuration removes that multiplier.

Final Reflection

The features that quietly disappear from your operations cost sheet are often the ones you don't even talk about. Dynamic SSO is one of those: once you've adopted it, you stop scheduling restart windows for identity changes, and the topic just goes away.

If your team is still negotiating restart windows for SSO updates, this one is worth a Monday morning.

Full documentation: api.octoperf.com/doc/administration/#sso

Want to become a super load tester?
Request a Demo