Skip to main content
Version: 1.0.0

Outbound Policy & Network Boundaries

Shyntr applies Zero Trust principles not only to authentication and token handling, but also to outbound network communication.

Whenever Shyntr initiates a security-sensitive outbound HTTP request—such as OIDC discovery, SAML metadata fetching, webhook delivery, or backchannel logout—that request is evaluated through a policy-driven control layer.

This ensures that outbound communication is treated as a privileged capability, not a default behavior.

Why Outbound Policy Exists​

Outbound HTTP requests can become a high-risk attack surface if left unrestricted.

Typical risks include:

  • Server-Side Request Forgery (SSRF)
  • Internal network exposure
  • Access to cloud metadata endpoints
  • Redirect-based bypasses
  • Data exfiltration through untrusted integrations

Shyntr mitigates these risks by enforcing explicit outbound policy checks before requests are executed.

Enforcement Points​

Outbound policy validation is applied to operations such as:

  • OIDC discovery
  • SAML metadata fetching
  • Webhook delivery
  • Backchannel logout requests

These checks are performed before the request is sent, not after the response is received.

Evaluation Model​

Shyntr evaluates outbound requests using a layered model:

  1. Tenant-specific policy (if present)
  2. Global fallback policy
  3. Otherwise: request is denied
Request → Tenant Policy → Global Policy → DENY

This creates a default-deny model for outbound communication.

What a Policy Controls​

An outbound policy can restrict requests based on:

  • Allowed schemes
  • Allowed host patterns
  • Allowed path patterns
  • Allowed ports
  • DNS resolution requirements
  • Redirect handling
  • Response size limits
  • Timeout limits

This makes outbound behavior both explicit and auditable.

Default Protections​

By default, Shyntr blocks requests that resolve to:

  • Private IP ranges
  • Loopback addresses
  • Link-local addresses
  • Multicast addresses
  • Localhost references

This prevents identity flows from being used as a tunnel into internal infrastructure.

TLS Behavior​

TLS certificate validation is enabled by default.

SKIP_TLS_VERIFY exists only for development scenarios and affects TLS verification behavior only. It does not disable outbound policy enforcement.

Global vs Tenant Policies​

Shyntr supports two levels of outbound policy:

Global Policy​

By default, migration seeds global outbound policies for:

  • Webhook delivery
  • SAML metadata retrieval
  • OIDC discovery
  • OIDC backchannel logout

These defaults enforce a secure baseline with HTTPS-only communication, blocked internal address ranges, disabled redirects, DNS resolution checks, and strict request limits.

The global policy acts as the system-wide fallback when no tenant-specific rule exists.

This allows the platform to remain secure by default even before tenant customization is applied.

Tenant Policy​

A tenant-specific policy overrides the global policy for that tenant.

This is useful when one tenant needs stricter host allowlists or different external integrations than another.

Managing Policies​

Outbound policies are managed through the Admin API.

Available operations include:

  • Create outbound policy
  • List outbound policies
  • Get outbound policy by ID
  • Update outbound policy
  • Delete outbound policy

This makes outbound network controls explicit, reviewable, and tenant-aware.

Example Use Cases​

Restricting OIDC Discovery​

A tenant can allow discovery only against approved corporate identity providers.

Limiting Webhook Destinations​

Webhook delivery can be constrained to a known set of domains or paths.

Controlling Metadata Retrieval​

SAML metadata can be fetched only from approved partner endpoints.

Security Posture​

Outbound policy turns Shyntr into more than an identity broker. It makes Shyntr a system that enforces trust boundaries both:

  • inside identity protocols
  • and across network execution paths

Next Steps​