Authentication and Security

Solace Schema Registry supports two authentication methods: an internal identity provider for simple deployments and external identity providers for production environments. Choose the method that best fits your security requirements and infrastructure.

The internal and external identity provider configurations are mutually exclusive. You must choose one authentication method and configure only the variables for that method.

Internal Identity Provider Configuration

Solace Schema Registry uses a lightweight internal IdP (node-oidc-provider) for basic authentication. This is suitable for development environments or smaller deployments where integration with an external IdP is not required. Configure the internal IdP using the following settings in values.yaml:

When using the embedded (internal) OIDC provider in your Kubernetes deployment, Solace Schema Registry requires HTTPS. This is because the embedded provider's reliance on secure communication protocols to protect authentication data.
Configuration Key Description Required
idp.registryOidcClientSecret Secure client secret for OIDC authentication Yes
idp.registryIdpKey A Base64-encoded private key for signing JWTs Yes
idp.developerPassword Password for developer role access Yes
idp.readonlyPassword Password for read-only role access Yes
idp.service.port Port for the internal IdP service No (default: 3000)

Example Internal Authentication Configuration

idp:
  registryOidcClientSecret: ""  # Set a secure client secret
  registryIdpKey: ""            # Set a secure IdP key
  developerPassword: ""         # Password for developer role
  readonlyPassword: ""          # Password for readonly role
  service:
    name: schema-registry-idp-service
    port: 3000
  image:
    name: solace-schema-registry-login
    tag: latest

External Identity Provider Configuration

For enterprise deployments, Solace Schema Registry supports integration with external OIDC providers. This section provides comprehensive configuration guidance including general OIDC setup and provider-specific instructions.

OIDC Configuration Variables

An external IdP allows you to leverage your existing identity management infrastructure and provides more advanced security features such as multi-factor authentication and single sign-on. To configure an external IdP, you need to set the following variables in the values.yaml file:

Configuration Key Description
externalIdp.enabled Set to true to enable external identity provider authentication
externalIdp.uiIssuer Token issuer URL for UI authentication
externalIdp.apiIssuer Token issuer URL for API authentication
externalIdp.apiRolesClaimPath Path to roles claim in API tokens (for example, roles)
externalIdp.uiRolesClaimPath Path to roles claim in UI tokens (for example, groups)
externalIdp.authRolesDeveloper Role or group ID that grants developer access
externalIdp.authRolesReadonly Role or group ID that grants read-only access
externalIdp.oidcDiscoveryEnabled Set to true to enable OIDC discovery
externalIdp.oidcResolveTenantsWithIssuer Set to true for multi-tenant environments (required for Azure)
externalIdp.oidcAuthServerUrl Base URL of your OIDC provider (for example, https://your-keycloak.com/auth/realms/registry)
externalIdp.clientId Client ID registered with the OIDC provider
externalIdp.apiSecret Client secret for API authentication
externalIdp.authnBasicScope Authentication scope for basic auth (for example, api://clientId/.default for Azure)

Example External Authentication Configuration

externalIdp:
  enabled: true                        # Enable external IdP integration
  uiIssuer: ""                         # Token issuer URL for UI authentication
  apiIssuer: ""                        # Token issuer URL for API authentication
  apiRolesClaimPath: "roles"           # Path to roles claim in API tokens
  uiRolesClaimPath: "groups"           # Path to roles claim in UI tokens
  authRolesDeveloper: ""               # Group/role ID that grants developer access
  authRolesReadonly: ""                # Group/role ID that grants read-only access
  oidcDiscoveryEnabled: "true"         # Enable OIDC discovery protocol
  oidcResolveTenantsWithIssuer: "true" # Required for multi-tenant environments like Azure
  oidcAuthServerUrl: ""                # Base URL of your OIDC provider
  clientId: ""                         # Client ID registered with the OIDC provider
  apiSecret: ""                        # Client secret for API authentication
  authnBasicScope: ""                  # Authentication scope for basic auth

When using an external Identity Provider (IdP), the deployment does not include or configure an internal IdP. The Solace Schema Registry expects role-based authorization information in the groups claim by default, but this can be customized using the registryOidcRoleClaimKey setting.

Supported Identity Providers

While the OIDC configuration variables above work with any compatible provider, some identity providers require additional configuration steps, have specific limitations, or need workarounds. This section provides detailed guidance for Microsoft Entra ID.

Getting Started with Microsoft Azure Entra ID

When configuring Azure application registrations to interact with the Registry REST API, there are additional configuration requirements and key limitations around role support.

Limitations

  1. The REST API only supports one role type, read-only OR developer, not both simultaneously.
  2. Users and app registrations cannot share the same role configuration values.

Azure Entra ID Configuration

The following configuration variables must be set in your values.yaml file for Azure Entra ID integration:

externalIdp:
  enabled: true
  oidcResolveTenantsWithIssuer: "true"
  uiIssuer: "https://login.microsoftonline.com/<tenant ID>/v2.0"
  apiIssuer: "https://sts.windows.net/<tenant ID>/"
  uiRolesClaimPath: "groups"
  apiRolesClaimPath: "roles"
  authRolesDeveloper: "<group object ID>"
  authRolesReadonly: "<group object ID>"
  authnBasicScope: "api://<clientId of app registration>/.default"

Matching Group IDs and App Role Values

Azure Entra ID presents a unique challenge: Solace Schema Registry uses a single set of role configuration values (externalIdp.authRolesDeveloper and externalIdp.authRolesReadonly), but Azure handles authentication differently for users versus applications:

  • Interactive users—Azure returns group membership IDs in the groups claim. These are fixed Azure group object IDs that you cannot modify.
  • App registrations (service principals)—Azure includes custom app role values in the roles claim. These are values you define when creating app roles.

As a workaround, when you create app roles in your Azure app registration, set the app role Value field to match your existing Azure group object IDs. This ensures both users and applications can use the same role configuration values in Solace Schema Registry. For example, if your developer Azure group has object ID 12345678-1234-1234-1234-123456789abc, create an app role with Value = 12345678-1234-1234-1234-123456789abc.

App Role Selection

Because only one externalIdp.authnBasicScope is supported, you must choose which role your REST API clients will have:

  • Choose Developer role if REST clients need to create/modify artifacts (for example, creating schemas with references)
  • Choose Read-only role if REST clients should only have read access to the registry
This role selection limitation only affects REST API clients. Web UI users can still use different roles and access the registry without issue.

Example Configuration

Your existing Azure groups:

  • Company Developers group ID: bbdb4071-920e-4704-94da-e43f930a7f96 (should have read-only access)
  • Schema Administrator group ID: 44decace-9a22-4338-b929-e30e4fcf0479 (should have write access)

To configure Azure Entra ID with the required workarounds, follow these steps:

  1. Configure role mappings using your group IDs in your values.yaml file: 
    externalIdp:
  authRolesDeveloper: "44decace-9a22-4338-b929-e30e4fcf0479"
  authRolesReadonly: "bbdb4071-920e-4704-94da-e43f930a7f96"
  2. Create Azure app registration for REST API access:
    1. Create app registration with identifier: api://8b2f9d9d-2ba4-486e-bcf5-5320c90ff0a4
    2. Important: Create an app role named sr-readonly with value bbdb4071-920e-4704-94da-e43f930a7f96 (this matches the group ID from Step 1)
    3. Grant this role to the app registration
  3. Configure the scope in your values.yaml file: 
    externalIdp:
  authnBasicScope: "api://8b2f9d9d-2ba4-486e-bcf5-5320c90ff0a4/.default"

Role-Based Access Control

The Solace Schema Registry supports role-based access control through the IdP's group claims. This allows you to control what actions different users can perform based on their assigned roles. The following roles are available:

  • sr-developer—Can create and manage schemas but cannot modify global settings. When using the internal IdP, access with username sr-developer and the password set in idp.developerPassword.
  • sr-readonly—Read-only access to schemas with no modification privileges. When using the internal IdP, access with username sr-readonly and the password set in idp.readonlyPassword.

These default roles and their permissions can be customized or mapped to your organization's own identity provider roles as needed. Ensure your IdP is configured to provide these roles in the claims specified by externalIdp.uiRolesClaimPath and externalIdp.apiRolesClaimPath. The default values are groups for UI and roles for API.

Troubleshooting Authentication Issues

If you encounter authentication-related issues, try these troubleshooting steps:

  • Internal IdP issues:
    • Verify all required fields are set in values.yaml (registryOidcClientSecret, registryIdpKey, developerPassword, readonlyPassword)
    • Check IdP pod logs: kubectl logs -n solace <idp-pod-name>
    • Verify HTTPS is enabled (required for internal IdP)
    • Test OIDC configuration endpoint: curl -k https://idp.<your-domain>/.well-known/openid-configuration
  • External IdP issues:
    • Verify OIDC client credentials are correct
    • Check issuer URLs match your IdP configuration
    • Ensure redirect URIs are correctly configured in both Solace Schema Registry and your IdP
    • Verify role claim paths match your IdP's token structure
    • Check that required roles are properly configured in your IdP
  • Azure Entra ID specific issues:
    • Verify app role values match Azure group object IDs
    • Check that oidcResolveTenantsWithIssuer is set to true
    • Ensure tenant ID is correct in issuer URLs
    • Verify app registration has correct API permissions
  • Login failures:
    • Check browser console for errors
    • Verify user has correct role assignments
    • Check backend logs for authentication errors: kubectl logs -n solace <backend-pod-name>