Getting Started
Architecture
Service Platform
NServiceBus
Transports
Persistence
ServiceInsight
ServicePulse
ServiceControl
Monitoring
Modernization
Shape the future
Samples

ServicePulse Security Overview

Component: ServicePulse

This section covers security features for ServicePulse, including authentication, transport layer security (TLS), and reverse proxy configuration.

In this section

  • Security Configuration - Configuration reference for TLS and forward headers
  • Hosting Guide - Deployment scenarios with complete configuration examples

Authentication

ServicePulse supports standards-based authentication using OAuth 2.0 with JSON Web Tokens (JWT), and OpenID Connect (OIDC).

When authentication is enabled on ServiceControl:

  1. ServicePulse retrieves authentication configuration from an anonymous ServiceControl endpoint
  2. Users sign in through the configured identity provider
  3. API requests to ServiceControl include a JWT bearer token in the Authorization header
  4. ServiceControl validates the token against the configured authority
sequenceDiagram participant User participant ServicePulse participant ServiceControl participant IdP as Identity Provider User->>ServicePulse: Open ServicePulse Note over ServicePulse,ServiceControl: Anonymous endpoint (no auth required) ServicePulse->>ServiceControl: GET /api/authentication/configuration ServiceControl-->>ServicePulse: Auth settings (authority, clientId, scopes) ServicePulse->>IdP: Redirect to sign-in User->>IdP: Enter credentials IdP-->>ServicePulse: Access token (JWT) Note over ServicePulse,ServiceControl: Authenticated request ServicePulse->>ServiceControl: API request + Authorization: Bearer {token} ServiceControl->>IdP: Validate token (via OIDC metadata) IdP-->>ServiceControl: Token valid ServiceControl-->>ServicePulse: API response ServicePulse-->>User: Display data

TLS

When authentication is enabled, access tokens are exchanged between ServicePulse and ServiceControl. To protect these tokens, TLS must be enabled.

ServicePulse supports two approaches for HTTPS:

  • Direct HTTPS: Configure Kestrel to handle TLS with a certificate
  • Reverse proxy: Terminate TLS at a reverse proxy (NGINX, IIS, Azure App Gateway, etc.) and forward requests to ServicePulse over HTTP

Reverse proxy support

When ServicePulse runs behind a reverse proxy, forwarded headers ensure ServicePulse correctly interprets client requests. This is important for:

  • Determining the original client IP address
  • Understanding whether the original request used HTTPS
  • Generating correct redirect URLs

Deployment scenarios

The Hosting Guide provides complete configuration examples for common deployment patterns:

  • Default configuration: No authentication, HTTP only (backward compatible)
  • Reverse proxy with authentication: TLS termination at proxy
  • Direct HTTPS with authentication: Kestrel handles TLS directly
  • End-to-end encryption: TLS at both proxy and Kestrel for internal traffic encryption

Related Articles

Feedback