Authenticating ServicePulse with Duende IdentityServer: plugging ServiceControl in
The four ServiceControl env vars from Part 3, repointed at Duende. Same login flow, same audience validation, different IdP.
I'm a developer, international speaker and coach/trainer. I love to discuss code, software architecture and distributed systems, messaging, star wars and lego with anyone who wants to listen or speak.
I currently work at Particular Software on NServiceBus.
The four ServiceControl env vars from Part 3, repointed at Duende. Same login flow, same audience validation, different IdP.
A minimal ASP.NET Core app embedding Duende IdentityServer, configured for the same servicecontrol-api audience the Keycloak path uses. Same SPA flow, different IdP, more code.
The error messages every first-time setup hits, what each one actually means, the fix, and the list of things that need to change before this configuration leaves the lab.
The four values that change when you swap identity providers, the audit instance that mirrors them, the forwarded headers ServiceControl trusts behind a reverse proxy, and the moment the browser finally lands back in ServicePulse with a token.
A realm, a client scope, the audience mapper that catches every first-time setup, and the public client ServicePulse uses to redirect through Keycloak.
ServiceControl 6.13 lets ServicePulse sit behind any OpenID Connect identity provider. This series wires it to Keycloak in Docker, end to end, on a home server.
How this blog now pulls snippets from real source files at build time, with a CI check that fails when an example stops compiling and a per-snippet link straight to GitHub.
I built a GitHub Action that checks links in pull requests, including links to private repositories.
Two fixes after the series - letting Claude run without interruptions inside Docker, and a git-wtadd bug that was silently pushing commits to main