Issue: SAML Redirect URI Uses HTTP Instead of HTTPS in Requests Despite Correct HTTPS Display in UI

[schneefisch]

Environment

• Deployment: Azure Container Apps (applicable to Kubernetes and similar environments)
• TLS Termination: External (Azure Container Apps ingress)
• Eramba Port: 80 (HTTP)
• External Protocol: HTTPS
• IdP: Keycloak

Problem Description

When configuring a SAML connector, the Eramba UI correctly displays HTTPS redirect URIs:

https://eramba.my-domain.com/login
https://eramba.my-domain.com/portal/policy/login

However, the actual SAML authentication request sent to the IdP contains HTTP redirect URIs instead:

http://eramba.my-domain.com/login?...

This forces us to register insecure HTTP URIs as valid redirect targets in the IdP configuration, creating a security vulnerability.

Expected Behavior

SAML authentication requests should use the same protocol (HTTPS) that is displayed in the Eramba UI redirect URL configuration.

Actual Behavior

SAML requests contain HTTP redirect URIs despite:

• The UI showing HTTPS URLs
• The application being accessed via HTTPS
• No explicit HTTP configuration in our setup

Root Cause Analysis

The application appears to be constructing SAML redirect URIs based on the container's listening port (80/HTTP) rather than:

• The actual external-facing protocol (HTTPS)
• Standard reverse proxy headers (X-Forwarded-Proto, X-Forwarded-Ssl)
• The protocol used in the UI's own redirect URL display

Questions for Maintainers

1. Is there a configuration option to force HTTPS in SAML requests that we're missing?
2. Does Eramba read standard proxy headers (X-Forwarded-Proto, X-Forwarded-Ssl, X-Forwarded-For)? If not, can this be added?
3. Why the inconsistency? If the UI can correctly determine and display HTTPS URLs, why doesn't the SAML request generation use the same logic?

Impact

This issue affects all deployments behind reverse proxies, load balancers, or ingress controllers - essentially any modern cloud-native or Kubernetes deployment. The docker-compose setup masks this issue because it typically doesn't use TLS termination at a separate layer.