Customer onboarding often starts with a small identity change: add a tenant, register a federated identity provider, upload a customer logo, activate provisioning. In many SaaS platforms, that small change still turns into an application release because the authentication behavior is wired into application code or static deployment configuration.
That is the wrong boundary. Customer-specific identity changes should be operational changes in the identity platform, not redeployments of every application that depends on authentication.
ProAuth was designed around this separation. Applications keep a single trust relation to ProAuth, while ProAuth handles tenant-specific identity providers, claim normalization, login views, user stores, and directory synchronization behind that boundary. The ProAuth documentation describes this as an API-first management model: functionality is available by API and can also be managed through the Management UI.
The problem with redeployment-driven identity onboarding
Redeploying applications for identity onboarding creates a slow and fragile workflow. The customer sends its requirements. The platform team changes configuration in code. The application is rebuilt, tested, scheduled, deployed, and monitored. If the configuration is wrong, the rollback path is another release.
That model has three practical problems.
First, identity configuration changes more often than application behavior. A tenant may need a new redirect URI, a different federated IdP instance, adjusted claim rules, branded login views, or SCIM provisioning before the application itself changes.
Second, authentication is shared infrastructure. A release that touches only one customer’s login path can still put a shared deployment pipeline under pressure.
Third, onboarding is usually time-sensitive. Enterprise customers expect their identity setup to be tested with their administrators, corrected quickly, and repeated safely for the next tenant.
The better operating model is to keep applications stable and move identity change into ProAuth configuration.
flowchart LR
subgraph ReleasePath["Redeployment-driven onboarding"]
A1["Customer identity requirement"] --> A2["Change application or deployment config"]
A2 --> A3["Build and release application"]
A3 --> A4["Retest authentication path"]
A4 --> A5["Rollback requires another release"]
end
subgraph RuntimePath["Runtime ProAuth onboarding"]
B1["Customer identity requirement"] --> B2["Update ProAuth via Admin UI, Management API, or CLI"]
B2 --> B3["New tenant pipeline is created at runtime"]
B3 --> B4["Existing requests keep using the previous pipeline definition"]
B4 --> B5["Validate and iterate without application redeployment"]
end
classDef slow fill:#fff4e5,stroke:#b45309,color:#3f2a00
classDef runtime fill:#eef8f2,stroke:#15803d,color:#12351f
class A1,A2,A3,A4,A5 slow
class B1,B2,B3,B4,B5 runtimeWhat runtime configuration means in ProAuth
Runtime configuration in ProAuth is not a loose collection of feature toggles. It is the operating model for tenant-specific authentication.
The ProAuth feature documentation states that each tenant configuration spins up an authentication pipeline, so authentication always happens in a tenant context. When configuration changes, ProAuth updates the authentication pipelines during runtime. New configurations and federated IdP instances can be added, modified, or removed without downtime; new pipeline definitions are created while old definitions continue to process ongoing requests.
That matters because a SaaS platform can keep its relying applications focused on OpenID Connect and OAuth integration, while ProAuth absorbs customer-specific differences behind the identity boundary.
Three management surfaces support that model:
- The Admin Application gives operators a guided interface for tenant, IdP, client, user, group, view, and provisioning changes.
- The Management API supports automation, onboarding workflows, and integration with internal platform processes.
- The CLI gives teams a scriptable option for repeatable operational tasks without moving identity behavior into application releases.
The important point is not which surface a team prefers. The important point is that all three target the identity platform instead of forcing every relying application to know about each customer’s authentication setup.
Common onboarding changes that should not require application releases
Create a new tenant. The existing tenant identification article shows how ProAuth can route authentication requests by tenant-specific subdomain, route segment, IP range, or the OpenID Connect acr_values parameter. Once the tenant is known, ProAuth routes the request into the tenant-specific authentication pipeline. The application still talks to ProAuth as its trusted issuer.
Add or adjust a federated identity provider. ProAuth federates with customer identity providers and normalizes claims before issuing tokens to applications. The application should not need a new deployment because one tenant changed its upstream IdP configuration.
Customize the login view. ProAuth supports tenant, client application, and subscription-level view customization. The existing view customization post shows that custom assets and views can be managed through the Admin UI and Management API, with changes taking effect at runtime after the assets are updated.
Activate directory synchronization. Federation tells ProAuth who the user is when the user signs in. SCIM provisioning tells ProAuth which users and groups exist before they sign in. ProAuth supports SCIM endpoints on IdP instances, and the SCIM protocol itself is standardized by the IETF in RFC 7644.
These are real production changes. They affect who can sign in, which claims are issued, what the user sees, and which users are available for application-level assignments. They belong in a controlled operations workflow, not in ad hoc edits to application code.
Guardrails for runtime tenant pipelines
Runtime configuration should make onboarding faster. It should not make identity changes casual.
A practical ProAuth onboarding workflow usually needs four guardrails:
- Auditability: keep a record of the requested change, the actor who applied it, the affected tenant or client application, and the validation result.
- Approval: separate business approval from technical execution for sensitive changes such as federated IdP setup, redirect URI changes, claim rules, and SCIM activation.
- Testing: validate the tenant login path with a small set of users before declaring onboarding complete. Include token claims, redirect behavior, view customization, and provisioning state where relevant.
- Rollback: keep the previous configuration or import definition available so the team can return to a known working state if customer-side metadata, certificates, claim mappings, or provisioning settings are wrong.
Those guardrails are ordinary release discipline applied at the right layer. The difference is that the release unit becomes identity configuration, not the application binary.
Why this helps onboarding velocity
Enterprise identity onboarding is rarely a single clean handoff. A customer may provide metadata that needs correction. The first test user may carry unexpected claims. A logo may need to be replaced. Provisioning may start before federation is fully validated, or the other way around.
When those changes require application redeployments, the onboarding team waits on the application release process. When those changes are ProAuth runtime configuration, the team can iterate inside the identity platform while the application stays stable.
That is the core operational benefit: fewer application releases for customer-specific identity work, less risk in shared application deployments, and a cleaner boundary between SaaS product behavior and tenant authentication behavior.
For a deeper look at the building blocks, see the earlier ProAuth posts on tenant identification, view customization, and directory synchronization. For the broader product model, start with the ProAuth features documentation.