Fragmented login
Teams still sign in separately to developer tools even after the company standardizes on a modern identity provider.
Open source SSO
Bring Open Source Tools Into Your Secure SSO Environment
Datawiza Access Proxy adds SSO, MFA, policy, and audit in front of Jenkins, Grafana, Kibana, Kubernetes dashboards, admin consoles, and other open source tools without rewriting each tool or buying separate SSO add-ons.
Why it matters
Open source tools often sit outside the SSO program
Engineering and operations tools are business-critical, but they are often protected by local passwords, VPN-only access, or expensive per-tool enterprise SSO upgrades.
Weak offboarding
Local accounts and shared credentials make it harder to remove access when users change roles or leave.
Costly SSO upgrades
Commercial editions may put SSO behind a premium tier for every tool, which adds cost across the toolchain.
Limited audit evidence
Security teams need centralized logs for sensitive tools, admin consoles, and production-adjacent workflows.
How it works
Put SSO controls in front of the tools
Route access through Datawiza
Place Datawiza Access Proxy in front of each tool so users authenticate before traffic reaches the application.
Connect your identity provider
Use Microsoft Entra ID, Okta, Auth0, Ping, Google Workspace, Duo, Amazon Cognito, or another SAML/OIDC identity provider.
Forward trusted identity
Pass identity context to the tool with headers or the integration pattern the application can support.
Enforce policy and audit
Apply group, role, path, and network-aware policies and keep centralized access logs for review.
Best fit
Where this pattern works best
Datawiza is useful when the tool is important enough to require centralized access control, but modifying the tool or buying a new enterprise tier would slow the project down.
For the broader no-code pattern, see Datawiza Access Proxy and MFA without code changes.
Good candidates include
Jenkins, Grafana, Kibana, Kubernetes dashboards, Airflow, internal dashboards, and admin consoles
Open source or self-hosted tools with local login, basic auth, or limited native SSO support
Tools used by engineers, SREs, analysts, vendors, contractors, or privileged administrators
Internet-facing or production-adjacent tools that need MFA and stronger audit trails
Teams standardizing access through Entra ID, Okta, Auth0, Ping, Duo, or Cognito
Controls
What security teams can standardize
Single sign-on
Let users sign in with the same identity provider and lifecycle controls used across the rest of the business.
MFA enforcement
Require MFA before users reach tools that expose production, customer, or operational data.
URL-level policy
Use access-layer rules for sensitive paths, admin areas, and user groups without changing the tool source code.
Central access logs
Keep authentication and policy events in one place for investigations, reviews, and audit support.
FAQ
Open source SSO FAQ
Do we need to modify each open source tool?
In many deployments, no. Datawiza can sit in front of the tool and enforce authentication before requests reach it. The exact integration depends on how the tool accepts trusted identity.
Can this reduce SSO licensing pressure?
It can help when teams want centralized SSO without upgrading every tool to a commercial tier just for SSO. The right model depends on the tool and your access requirements.
Can we add MFA too?
Yes. Datawiza can enforce MFA through your identity provider or through Datawiza-supported access flows before a user reaches the tool.
Which tools are common candidates?
Jenkins, Grafana, Kibana, Kubernetes dashboards, Airflow, monitoring dashboards, admin consoles, and internal developer portals are common examples.
Bring one tool into SSO first
Datawiza can review the tool, login flow, and identity provider setup and show the fastest way to add SSO, MFA, and audit at the access layer.
Developer auth proxy guides