DEV Community: Pascal Reitermann

Design-First or Infrastructure-as-Code? Choosing the Source of Truth for your Solace Broker

Pascal Reitermann — Wed, 11 Mar 2026 19:51:58 +0000

In a modern Event-Driven Architecture (EDA), the broker is no longer just "infrastructure". It is the heartbeat of the business. As enterprises scale their event meshes, the question isn't if they should automate, but where the "Source of Truth" should live.

In the Solace ecosystem, you have two powerful paths: Terraform (Infrastructure-as-Code) or Event Portal (Design-First). Both are excellent, but they represent fundamentally different philosophies. To avoid configuration drift and operational chaos, you must choose your "North Star."

The IaC Path: Terraform & Engineering Excellence

This approach treats your Solace broker like any other cloud resource, such as an S3 bucket or an EC2 instance. You define your queues, RDPs, and ACLs as code.

resource "solacebroker_msg_vpn_queue" "this" {
  msg_vpn_name        = "default"
  queue_name          = "acme-queue"
  max_msg_spool_usage = 70000
  ingress_enabled     = true
  egress_enabled      = true
}

Key Benefits:

Unified Pipeline: Seamless integration into existing CI/CD and GitOps workflows.
Version Control: Every change is documented in Git, requiring Pull Requests and Peer Reviews.
Scale: Manage hundreds of Message VPNs across different regions with a single command.

Ideal for: Platform teams who prioritize operational consistency, auditability, and infrastructure automation.

The Design-First Path: Solace Event Portal

The Design-First approach focuses on modeling your "Event API" before a single line of infrastructure is provisioned. It’s about the "What" and "Why" rather than just the "How".

Key Benefits:

Visual Governance: Stakeholders and architects see the flow of data through visual graphs, not just lines of code.
Schema Registry: Native management of payloads (Avro, JSON, etc.) and versioning of events.
Discovery: Developers can easily find existing events to subscribe to, preventing the creation of redundant "event silos."

Ideal for: Organizations that require strong cross-team alignment on data contracts and focused on data contracts and architectural visibility.

You Can’t Have Two Masters

Without a clear boundary, organizations may face Configuration Overlap. If both Terraform and the Event Portal attempt to manage the same broker objects without a hierarchy, the system state can become inconsistent.

The Solution: Establish a clear hierarchy. For example, use the Event Portal for high-level design and contract definition, while designating Terraform as the final authority for deploying those resources to the broker.

Decision Matrix: Which one is for you?

Feature	Terraform (IaC)	Event Portal (Design-First)
Primary User	DevOps / Platform Engineer	Architect / Application Developer
Visibility	Low (Code-centric)	High (Visual/Graph-centric)
Schema Management	Manual / External	Native / Integrated
Best For	Infrastructure Automation	Event Governance & Discovery

Conclusion: Picking Your North Star

Choosing between Terraform and Event Portal isn't about which tool is "better". It's about who owns the Source of Truth.

If your team lives in the terminal and manages 50+ production brokers with a focus on uptime and reliability, Terraform is your best friend.
If your team is building a complex ecosystem of microservices and needs to govern data contracts and event discovery, Event Portal is your home.

The "Hybrid" Bridge: Keep in mind that Solace Event Portal and Terraform can co-exist. You can, for example, deploy your entire infrastructure with Terraform and use the Discovery functionality in Event Portal to scan, load, and visualize your runtime environment. This gives you the best of both worlds: automated, code-based deployments and a clear, graphical map of your ecosystem. However, even in this setup, the hierarchy must be clear: One tool configures, the other visualizes.

🚀 Unlocking the Future: My AI Agent Mesh Portfolio Backend for the New Year, New You Challenge

Pascal Reitermann — Fri, 09 Jan 2026 21:35:27 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hello DEV.to community! I'm Pascal, a Senior Engineer with a passion for building robust, event-driven systems. My career has spanned significant challenges, including managing and scaling over 14,000 endpoints at dmTECH. Starting from march, I'm leveraging this extensive enterprise background as a Customer Technical Trainer at Solace, where I empower developers to master Event-Driven Architecture (EDA) and messaging technologies.

This portfolio represents my next step: merging my deep understanding of distributed systems with the transformative power of Google AI. My goal is to showcase not just what I've done, but how I build scalable, intelligent, and cloud-native applications — and to connect with the incredible community driving innovation in AI and cloud engineering.

Portfolio

Get a live look at my AI Agent Mesh in action! This interactive component demonstrates real-time insights and asynchronous processing.

Note: As a serverless application, the first request might experience a brief "cold start" delay.

How I Built It

My journey in this challenge was about pushing the boundaries of what a portfolio can be, leveraging Google Cloud Platform (GCP) and Google AI to create an AI Agent Mesh.

Tech Stack:

Language: Go (Golang) - Chosen for its efficiency, concurrency, and robust standard library (net/http) for a lean, high-performance backend.
AI Model: Google Gemini 2.0 Flash - The core intelligence powering dynamic interactions and context-aware responses.
Compute: Google Cloud Run - Fully serverless, offering "scale-to-zero" for cost efficiency and automatic scaling under load.
Messaging: Google Pub/Sub - The backbone of my Event-Driven Architecture, enabling asynchronous communication and decoupling services.
CI/CD: GitHub Actions - Automating Docker builds, image pushes to Google Artifact Registry, and deployments to Cloud Run.
IaC: Terraform - Managing IAM roles and cloud infrastructure with code for consistency and repeatability.

Design Decisions & Development Process:

From the outset, I aimed for an "AI-native" and "cloud-native" design. My backend, built with the Go standard library, emphasizes minimal overhead, crucial for serverless environments. The "Agent Mesh" concept means that user interactions don't block the UI; instead, they trigger a cascade of lightweight, asynchronous events handled by Pub/Sub, allowing for parallel processing, logging, and interaction with Gemini.

Google AI Tools in Action – My DevOps Partner:

A pivotal aspect of this project was my Human-AI Collaboration with Google Gemini. Gemini wasn't just a chatbot; it was an integral partner throughout the development and deployment cycle:

Architecture & Best Practices: Gemini helped refine my event-driven architecture, advising on optimal Pub/Sub topic structures and Go concurrency patterns.
Cloud Engineering & Debugging: When faced with platform challenges - such as multi-platform Docker builds (linux/amd64 for Cloud Run from my ARM64 local machine), intricate IAM permissions (artifactregistry.writer, run.developer), or exec format error - Gemini acted as a Senior SRE, providing precise debugging steps and gcloud commands. This significantly accelerated problem-solving and deployment.
Code Optimization: Gemini assisted in ensuring my Go code adhered to idiomatic patterns, making it clean, maintainable, and efficient for serverless execution.

What I'm Most Proud Of

The "Agent Mesh" in Action: I'm particularly proud of demonstrating how an event-driven approach, powered by Pub/Sub, allows for a truly decoupled and scalable AI interaction. It showcases how to move beyond simple request-response to a more robust, extensible system where user input can trigger multiple parallel intelligent agents.
Lean & Performant Go Backend: Building with just the Go standard library for the backend was a deliberate choice. It proves that powerful, efficient applications don't always need heavy frameworks, especially in serverless contexts where binary size and cold start times are critical.
Mastering the DevOps Struggles with AI: Overcoming deployment hurdles - from Docker architecture mismatches to intricate Google Cloud IAM policies - with Gemini as my guide was incredibly rewarding. It highlights how modern engineers can leverage AI not just for code, but for navigating the complexities of cloud infrastructure, making the entire CI/CD pipeline robust and efficient.

PEM vs. PKCS#12 (P12/PFX): Understanding the Difference Between Certificate Formats

Pascal Reitermann — Fri, 26 Dec 2025 22:46:47 +0000

When working with TLS, HTTPS, OAuth, API gateways, or modern messaging platforms, you’ll eventually encounter two very common certificate formats: PEM and PKCS#12 (P12/PFX).

They both deal with keys and certificates – but they are not the same thing, and using the wrong one can cause frustrating errors.

This post explains what each format is, what problems they solve, how they differ, and when to use which.

What problem do certificate files solve?

Digital certificates are used to:

Prove identity (who am I?)
Enable encryption
Establish trust between systems

To do that, we need:

A private key
A public certificate
Sometimes: intermediate + root certificates
Sometimes: credentials to protect them

Different tools and ecosystems expect these packaged in different ways — that’s where PEM and P12 come in.

What is a PEM Certificate?

PEM stands for Privacy Enhanced Mail, but today it’s a general-purpose certificate format used almost everywhere.

PEM files are:

Text-based (Base64 encoded)
Human-readable
Easy to copy, paste, and version
Very common on Linux, cloud environments, and DevOps tooling

They look like this:

-----BEGIN CERTIFICATE-----
MIID2zCCAsOgAwIBAgIUWlK...
-----END CERTIFICATE-----

PEM files can contain:

Public certificates (.crt\, .cer\, .pem\)
Private keys (.key\, sometimes .pem\)
Certificate chains (multiple certs in one file)

Advantages of PEM

Easy to inspect
Git- and diff-friendly
Supported by OpenSSL, Kubernetes, NGINX, Apache, Keycloak, Solace, Prometheus, etc.
Flexible: multiple certificates can be stored together

Disadvantages

Private keys may be unencrypted
Not ideal for securely bundling multiple credentials
Lacks built-in password protection

What is a PKCS#12 / P12 / PFX File?

PKCS#12 (also known as P12 or PFX) is a binary, standardized container format defined in Public Key Cryptography Standards.

A P12 file is basically a secure bundle that can contain:

Private key
Public certificate
Certificate chain (intermediate + root)
Optional trust store
Protected with a password

This is why Windows, macOS Keychain, browsers, enterprise IAM tools, and hardware security devices love it.

Advantages of P12

Designed for secure transport of identities
Password protected
One file contains everything
Great for importing identities into:
- Browsers
- Windows Certificate Store
- Java KeyStores
- Enterprise systems

Disadvantages

Binary → harder to inspect
Not Git-friendly
Requires tooling to open
Slightly heavier operationally

PEM vs P12 — Quick Comparison

Feature	PEM	PKCS#12 (P12/PFX)
Encoding	Text (Base64)	Binary
Typical OS	Linux / Unix	Windows + enterprise tools
Can store private key	Yes	Yes
Can store cert chain	Yes	Yes
Stores multiple items	Sometimes	Yes (by design)
Password protection	No (unless manually encrypted)	Yes
Human readable	Yes	No
Typical Extensions	`.pem\`, `.crt\`, `.cer\`, `.key\`	`.p12\`, `.pfx\`

Converting Between PEM and P12

Since tools often disagree on formats, conversion is very common.

Convert PEM → P12

Combine certificate + private key into a secure bundle:

openssl pkcs12 -export \
  -in cert.pem \
  -inkey private.key \
  -certfile chain.pem \
  -out identity.p12

You’ll be asked for a password — this protects the .p12 file.

Convert P12 → PEM

Extract the private key:

openssl pkcs12 \
  -in identity.p12 \
  -nocerts \
  -out private.key

Extract the certificate:

openssl pkcs12 \
  -in identity.p12 \
  -clcerts \
  -nokeys \
  -out cert.pem

Extract the full chain:

openssl pkcs12 \
  -in identity.p12 \
  -nodes \
  -out fullchain.pem

When Should You Use Which?

Use PEM when:

configuring servers or infrastructure
using Linux / DevOps tooling
working with Kubernetes, NGINX, Apache, Envoy
certificates are long-lived and versioned
human readability is useful

Use P12 when:

you need to securely transport an identity
importing into Windows, browsers, Java, Keycloak, etc.
bundling key + cert + chain in one file
password protection is required

Summary

PEM and PKCS#12 aren’t competitors — they solve different problems:

PEM = simple, readable, DevOps & Linux friendly
P12 = secure, portable identity container

You’ll encounter both, and understanding their roles saves a lot of confusion when systems refuse to accept your certificates.

Securing Solace Metrics: How to Use OAuth with solace-prometheus-exporter

Pascal Reitermann — Fri, 19 Dec 2025 00:16:44 +0000

Monitoring often gets less security attention than it deserves. While applications and APIs are protected with modern identity standards, metrics endpoints frequently rely on static credentials. For Solace environments exposed to Prometheus, this can turn monitoring into a weak spot within an otherwise well-secured system.

To address this, the community-driven solace-prometheus-exporter recently gained OAuth 2.0 support, enabling secure, token-based access to the Solace monitoring endpoints.

In this article, I'll explain why this matters, how it works, and how you can configure it in your own environment.

Why Authentication Matters for Metrics

Metrics contain sensitive operational data: queue backlogs, client sessions, system load, and detailed message flow patterns. Exposing these without secure authentication can reveal internal system behavior or traffic patterns to unauthorized parties.

OAuth 2.0 addresses these risks by providing:

Use of short-lived tokens instead of long-lived static secrets
Centralized identity control across environments
Automatic token rotation and refresh without requiring service restarts or redeployment

This makes OAuth 2.0 a natural fit for production monitoring, particularly in Zero Trust or multi-cluster environments.

Introducing OAuth 2.0 Support in solace-prometheus-exporter

Starting from version 1.13.0, the solace-prometheus-exporter supports OAuth 2.0 using the Client Credentials Flow, when scraping metrics from the Solace SEMP API.

The exporter is now capable of:

Requesting access tokens from an Identity Provider (IdP) using a Client ID and Secret.
Automatically refreshing the tokens before expiration to maintain continuous scraping.
Using the returned Bearer tokens in the HTTP Authorization header when calling the Solace SEMP API.

Architecture Overview of the OAuth-Based Setup

This setup consists of three main components:

Identity Provider: Keycloak (issues the tokens)
Resource Server: Solace Broker (validates tokens and provides metrics)
Client: solace-prometheus-exporter (requests tokens and scrapes metrics)

Step-by-Step: Configuring OAuth for Solace Metrics

In this lab, we will generate our own CA and TLS certificates to keep everything self-contained. In a production environment, these certificates would typically be issued by an internal PKI or a trusted corporate CA.

Prerequisites

Before we start, ensure:

Docker is installed and running.
openssl is installed and available to generate the required TLS certificates.

Step 1: Prepare the Demo Infrastructure

OAuth in Solace requires TLS. To enable secure communication between containers using hostnames, we create a dedicated Docker bridge network and a local Certificate Authority (CA).

Certificates must include both the container hostname and localhost as Subject Alternative Names (SANs), allowing access from inside Docker and from the host.

Create a Docker Bridge Network

docker network create solace-net

Create a Root CA

# Generate private key for CA
openssl genrsa -out /tmp/rootCA.key 4096

# Create a self-signed Root CA
openssl req -x509 -new -nodes -key /tmp/rootCA.key -sha256 -days 365 \
  -out /tmp/rootCA.crt -subj "/CN=MyLocalCA"

Step 2: Identity Provider Setup (Keycloak)

In this example, we use Keycloak as our IdP, as it is open source and easily runnable via Docker.

Generate TLS Certificates for Keycloak

# OpenSSL config with SANs for Keycloak
echo '[req]
default_bits       = 4096
prompt             = no
default_md         = sha256
req_extensions     = req_ext
distinguished_name = dn

[dn]
CN = keycloak

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = keycloak
DNS.2 = localhost' > /tmp/keycloak-cert.conf

# Create CSR
openssl req -new -nodes -out /tmp/keycloak.csr -newkey rsa:4096 -keyout /tmp/keycloak.key -config /tmp/keycloak-cert.conf

# Sign CSR with the Root CA
openssl x509 -req -in /tmp/keycloak.csr -CA /tmp/rootCA.crt -CAkey /tmp/rootCA.key -CAcreateserial \
  -out /tmp/keycloak.crt -days 365 -sha256 -extfile /tmp/keycloak-cert.conf -extensions req_ext

Configure the Realm

We set up a Realm (acme-org) to represent our identity domain. Within this realm, we define:

Client prometheus-exporter - The Token Requester
This is the client application requesting the token. It uses the Client Secret (my-secret) to authenticate itself with Keycloak.
Client solace - The Audience
This represents the Resource Server (our Solace Broker) and is the expected Audience (aud) of the token. It tells Keycloak that the issued token is intended for use with Solace.

We rely on specific Mappers within Keycloak to inject the necessary claims into the JWT:

Audience (aud) - Where is this token valid?
The oidc-audience-mapper ensures the issued JWT contains the claim "aud": "solace". This identifies the Solace Broker as the only intended recipient. If a token without this claim is presented, the broker will reject it, preventing tokens meant for other services from being misused here.
Scope (scope) - What permissions does the Client want?
The scope specifies what actions the client is requesting, regardless of the client's assigned roles. In this example, we define a custom client scope called solace.admin. It tells the Solace broker that the exporter is requesting admin access for Solace. Also we assign this scope as a default scope for the client prometheus.exporter. Scopes are usually coarse-grained and represent what the client wants to do, not who the client is.
Roles/Groups (groups Claim) - Who is the client and what privileges does it have?
The oidc-usermodel-realm-role-mapper maps the client's assigned roles (in this case, the default role default-roles-acme-org) into a claim named "groups". Solace uses this claim to map the identity to an internal access level (e.g., read-only). Usually you want to create a custom role for the Client to map the permissions on Solace. But for the blog, we stick to the default roles.

echo '{
  "realm": "acme-org",
  "enabled": true,
  "accessTokenLifespan": 3600,
  "clients": [
    {
      "clientId": "solace",
      "protocol": "openid-connect",
      "publicClient": false,
      "secret": "my-secret",
      "serviceAccountsEnabled": true,
      "directAccessGrantsEnabled": false,
      "standardFlowEnabled": false
    },
    {
      "clientId": "prometheus-exporter",
      "protocol": "openid-connect",
      "publicClient": false,
      "secret": "my-secret",
      "serviceAccountsEnabled": true,
      "directAccessGrantsEnabled": false,
      "standardFlowEnabled": false,
      "defaultClientScopes": ["solace.admin"],
      "protocolMappers": [
        {
          "name": "audience-mapper",
          "protocol": "openid-connect",
          "protocolMapper": "oidc-audience-mapper",
          "consentRequired": false,
          "config": {
            "claim.name": "aud",
            "jsonType.label": "String",
            "access.token.claim": "true",
            "id.token.claim": "false",
            "included.client.audience": "solace"
          }
        },
        {
          "name": "roles-mapper",
          "protocol": "openid-connect",
          "protocolMapper": "oidc-usermodel-realm-role-mapper",
          "consentRequired": false,
          "config": {
            "claim.name": "groups",
            "jsonType.label": "String",
            "access.token.claim": "true",
            "id.token.claim": "false",
            "multivalued": "true"
          }
        }
      ]
    }
  ],
  "clientScopes": [
    {
      "name": "solace.admin",
      "description": "Scope for Prometheus Exporter to read Solace metrics",
      "protocol": "openid-connect",
      "attributes": {
        "display.on.consent.screen": "false"
      }
    }
  ]
}' > /tmp/acme-org.json

Run Keycloak

docker run \
  --network solace-net \
  --platform linux/amd64 \
  -p 8080:8080 \
  -p 8443:8443 \
  -v /tmp/acme-org.json:/opt/keycloak/data/import/realm.json \
  -v /tmp/keycloak.key:/opt/keycloak/data/keycloak.key \
  -v /tmp/keycloak.crt:/opt/keycloak/data/keycloak.crt \
  -e KC_HOSTNAME_STRICT_HTTPS=false \
  -e KC_HOSTNAME_STRICT=false \
  -e KC_HOSTNAME=keycloak \
  -e KC_HTTPS_CERTIFICATE_FILE=/opt/keycloak/data/keycloak.crt \
  -e KC_HTTPS_CERTIFICATE_KEY_FILE=/opt/keycloak/data/keycloak.key \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=admin \
  --name keycloak \
  quay.io/keycloak/keycloak:26.4.7 \
  start-dev \
    --import-realm \
    --https-port=8443 \
    --hostname=keycloak

When you see the log entry [...] Listening on: http://0.0.0.0:8080 and https://0.0.0.0:8443, Keycloak is up and running and you can proceed with the next steps.

Validate Issued OAuth Tokens

We can now test the setup by fetching a token for the prometheus-exporter client with the required scope solace.admin.

curl --insecure -X POST "https://localhost:8443/realms/acme-org/protocol/openid-connect/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=prometheus-exporter" \
  -d "client_secret=my-secret" \
  -d "scope=solace.admin"

The response contains a JSON Web Token (JWT) in the access_token field. When decoded, the payload confirms the configuration:

{
  "exp": 1766104964,
  "iat": 1766101364,
  "jti": "trrtcc:c50ac927-4c81-e22a-83b7-f36fad114c89",
  "iss": "https://keycloak:8443/realms/acme-org",
  "aud": "solace",
  "sub": "85ba915f-6c6f-4109-9704-dca2ff1057cd",
  "typ": "Bearer",
  "azp": "prometheus-exporter",
  "scope": "solace.admin",
  "groups": [
    "offline_access",
    "uma_authorization",
    "default-roles-acme-org"
  ]
}

Step 3: Configure Solace as the OAuth Resource Server

Generate TLS Certificates for Solace

# openssl config with san
echo '[req]
default_bits       = 4096
prompt             = no
default_md         = sha256
req_extensions     = req_ext
distinguished_name = dn

[dn]
CN = solace

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = solace
DNS.2 = localhost' > /tmp/solace-cert.conf

# create csr
openssl req -new -nodes -out /tmp/solace.csr -newkey rsa:4096 -keyout /tmp/solace.key -config /tmp/solace-cert.conf

# sign csr with ca:
openssl x509 -req -in /tmp/solace.csr -CA /tmp/rootCA.crt -CAkey /tmp/rootCA.key -CAcreateserial \
  -out /tmp/solace.crt -days 365 -sha256 -extfile /tmp/solace-cert.conf -extensions req_ext

cat /tmp/solace.key /tmp/solace.crt > /tmp/solace.pem

Start the Solace Broker

docker run \
  --network solace-net \
  --platform linux/amd64 \
  -p 8081:8080 \
  -p 1943:1943 \
  -v /tmp/solace.pem:/etc/solace_tls/solace.pem \
  --shm-size=2g \
  --env tls_servercertificate_filepath=/etc/solace_tls/solace.pem \
  --env username_admin_globalaccesslevel=admin \
  --env username_admin_password=admin \
  --name solace \
  solace/solace-pubsub-standard:10.25.12

Solace distinguishes between client users and management users.
For interacting with the SEMP API - which the Prometheus exporter uses to retrieve metrics - we need a management user, not a client user.

To enable OAuth for management access, we have to configure an OAuth profile at the broker level (outside of any Message VPN). This configuration is currently not available via the web UI, so it must be done via the SEMP API, either through the CLI or a direct REST call. Solace has a good documentation for this.

Since Solace needs to validate the signature of the JWT access tokens issued by Keycloak, we must upload the Root CA certificate which signed the Identity Provider's certificate (Keycloak). This establishes a trust relationship, allowing the broker to securely verify that the token truly came from our Keycloak server.

Establish Trust: Uploading the Root CA to Solace

# store CA in variable and replace newlines
ROOT_CA=$(awk '{printf "%s\\n", $0}' /tmp/rootCA.crt)

# upload domain CA
curl -X POST "http://localhost:8081/SEMP/v2/config/domainCertAuthorities" \
  -u "admin:admin" \
  -H "Content-Type: application/json" \
  -d "{
    \"certAuthorityName\": \"root_ca\",
    \"certContent\": \"$ROOT_CA\"
  }"

OAuth Profiles: Trusting the Identity Provider

An OAuth Profile represents the trust relationship between the Solace broker and an OAuth 2.0 / OpenID Connect IdP.

In simple terms, the OAuth profile answers the question:

"How do I verify that an incoming access token is valid, and what do I expect it to look like?"

An OAuth profile configures:

Who issued the token: The issuer (iss claim) ensures the token comes from the expected IdP.
How tokens are validated
- Verifying the JWT signature using the IdP's JWKS endpoint
- Optionally calling the token introspection endpoint
Which token properties are required, For example:
- Token type (JWT)
- Audience (aud)
- Required scopes
- Required claims
Which OAuth endpoints Solace can use
- Authorization endpoint
- Token endpoint
- Introspection endpoint
- JWKS endpoint
- Userinfo endpoint
What happens if no fine-grained authorization matches
- Default global access level
- Default Message VPN access level
Which claim value grants access (accessLevelGroupsClaimName claim)

From Solace's perspective, the OAuth profile defines authentication rules:
If a token does not match these rules, access is denied before any permissions are evaluated.

Create the OAuth Profile with this:

curl -X POST "http://localhost:8081/SEMP/v2/config/oauthProfiles" \
  -u "admin:admin" \
  -H "Content-Type: application/json" \
  -d '{
    "accessLevelGroupsClaimName": "groups",
    "clientId": "solace",
    "clientSecret": "my-secret",
    "displayName": "keycloak_profile",
    "enabled": true,
    "endpointDiscovery": "https://keycloak:8443/realms/acme-org/.well-known/openid-configuration",
    "interactiveEnabled": false,
    "issuer": "https://keycloak:8443/realms/acme-org",
    "oauthProfileName": "keycloak_profile",
    "oauthRole": "resource-server",
    "resourceServerRequiredAudience": "solace",
    "resourceServerRequiredIssuer": "https://keycloak:8443/realms/acme-org",
    "resourceServerRequiredScope": "solace.admin",
    "resourceServerRequiredType": "JWT",
    "sempEnabled": true,
    "usernameClaimName": "azp"
  }'

OAuth Access Level Groups: Mapping Identity to Permissions

While the OAuth profile validates who you are, OAuth Access Level Groups determine what you are allowed to do.

This answers the question:

"Given this token, what permissions should this identity have inside Solace?"

Solace extracts the value from the configured claim (in our case, groups) and matches it against these groups.

Create the authorization group mapping:

curl -X POST "http://localhost:8081/SEMP/v2/config/oauthProfiles/keycloak_profile/accessLevelGroups" \
  -u "admin:admin" \
  -H "Content-Type: application/json" \
  -d '{
    "description": "Global read-only group",
    "globalAccessLevel": "read-only",
    "groupName": "default-roles-acme-org",
    "oauthProfileName": "keycloak_profile"
   }'

Step 4: Configure the Client (solace-prometheus-exporter)

To use OAuth in the exporter, set the following parameters.

Note: Since this is a demo environment using self-signed certs, SOLACE_SSL_VERIFY is set to false. In production, you would mount the Root CA and set this to true.

The exporter can be run using these parameters:

echo 'SOLACE_LISTEN_ADDR=0.0.0.0:9628
SOLACE_LISTEN_TLS=false
SOLACE_SCRAPE_URI=https://solace:1943
SOLACE_OAUTH_TOKEN_URL=https://keycloak:8443/realms/acme-org/protocol/openid-connect/token
SOLACE_OAUTH_CLIENT_ID=prometheus-exporter
SOLACE_OAUTH_CLIENT_SECRET=my-secret
SOLACE_OAUTH_CLIENT_SCOPE=solace.admin
SOLACE_DEFAULT_VPN=default
SOLACE_TIMEOUT=5s
SOLACE_SSL_VERIFY=false
PREFETCH_INTERVAL=0s
SOLACE_PARALLEL_SEMP_CONNECTIONS=1
' > /tmp/env

docker run \
  --network solace-net \
  --platform linux/amd64 \
  -p 9628:9628 \
  --env-file /tmp/env \
  --name exporter \
  solacecommunity/solace-prometheus-exporter:v1.13.0

Verify Access to Secured Metrics

Accessing a metrics endpoints in your browser should now return metrics. These are being securely fetched from Solace using a short-lived OAuth token.

Security Considerations & Best Practices

Securing metrics endpoints goes beyond enabling OAuth. Keep these best practices in mind:

Enforce TLS: Always use trusted certificates. Self-signed certs are okay for demos but not for production.
Least Privilege: Grant the exporter only the necessary scope and map identity groups carefully (read-only permissions).
Short-Lived Tokens: Use short-lived access tokens and automatic refresh to minimize risk and operational overhead.
Validate Token Claims: Ensure the broker validates the audience (aud), issuer (iss), and token type (JWT) for all requests.
And as always: Observe access events and separate testing and production environments.

Following these practices ensures your metrics infrastructure is secure, reliable, and production-ready.

Conclusion

Monitoring endpoints are production APIs and should be treated as such.

This setup eliminates static secrets from monitoring, closing a commonly overlooked security gap. With OAuth in place, your monitoring endpoints are no longer a weak link, bringing you one step closer to a truly secure and scalable messaging environment.

This article focuses on securing communication between the exporter and the broker. Securing Prometheus scrape endpoints is a separate topic, but applying the same principles can further strengthen your overall monitoring infrastructure.