Skip to main content

SSO Integration: Connecting SAML and OIDC Identity Providers

Single sign-on matters in Keeptrusts because governance tooling only works well when the identity boundary is clear. The console supports corporate SSO with both OIDC and SAML, routes users through same-origin login flows, preserves returnTo state for workbench redirects, and completes the session server-side so the browser never receives the upstream bearer token. In practice, that means you can connect the identity provider your organization already trusts without splitting your operators across a separate auth domain or making chat and console entry points behave differently.

Use this page when​

  • You are onboarding multiple teams and want identity to follow the same standards as the rest of your platform.
  • You need to connect an OIDC or SAML identity provider to the Keeptrusts console.
  • You want to verify that chat-first or task-first entry points still land users in the correct workspace after SSO.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Platform administrators, security teams, technical leaders

The problem​

Identity integration often fails at the seams, not in the protocol spec. The IdP may authenticate correctly, but users land on the wrong page. The console may sign in correctly, but a chat-first workflow forgets where the user was headed. SAML assertions may be accepted, yet the login experience still feels bolted on because the product uses a different origin or a separate session boundary.

That is a real issue in AI governance platforms because users do not only start from one page. Some people arrive at the main console. Others start from chat or tasks. Administrators need a clean corporate sign-in path, but end users also need to return to the workbench they originally requested.

Keeptrusts addresses that operational problem directly. The console supports SSO discovery and callback handling in a way that keeps the session same-origin and preserves the requested destination after authentication completes.

What the platform supports​

The core behavior is straightforward.

  • The login experience can route users into corporate SSO from the main sign-in surface.
  • Keeptrusts supports both OIDC and SAML provider flows.
  • The callback bridge uses /sso/callback for both protocols.
  • OIDC returns by redirect with code and state parameters.
  • SAML returns by POST with a SAMLResponse, and Keeptrusts completes that flow server-side because the payload can be too large for cookie-based session handling.
  • The browser is then sent through /sso/complete and ultimately into the authenticated console surface.

That unified callback behavior is more important than it sounds. It reduces the number of moving parts your identity team has to reason about, and it keeps the user journey consistent whether the provider is redirect-based or assertion-post based.

The platform also preserves continuation state. If a user starts from chat or tasks while signed out, the login flow can keep the intended destination and return the user to that workspace after authentication instead of dumping them into a generic landing page.

Practical workflow​

The safest way to connect SSO is to treat it as a controlled rollout rather than a one-click setting.

Use this sequence.

  1. Decide whether your identity provider should use OIDC or SAML for the Keeptrusts application.
  2. Confirm the public console URL that users will actually access in production.
  3. Register the Keeptrusts callback endpoint with the identity provider.
  4. In Keeptrusts, create or enable the corresponding SSO connection for that provider type.
  5. Test sign-in from the console login page with a dedicated non-admin account.
  6. Test chat-first entry by opening a protected workbench while signed out and confirming that the user returns to the requested workspace after SSO completes.
  7. Repeat with an administrator account to confirm that role-sensitive surfaces still load correctly.

For most teams, the important validation points are not deep protocol internals. They are practical behavior checks:

  • Does the login page route users into the correct corporate sign-in flow?
  • Does the callback succeed without losing the session?
  • Does a chat-first entry keep the intended destination?
  • Does the user land in the expected organization and role context?

Those are the checks that prevent post-launch confusion.

A concrete example​

Imagine an organization that wants all engineering and compliance staff to sign in through its existing corporate IdP. The rollout goal is not just successful authentication. The goal is for an engineer who starts from the console overview and a reviewer who starts from a shared chat or task link to both end up in the right governed workspace without extra handoffs.

The admin team registers the Keeptrusts application with the IdP, points the return path at /sso/callback, and enables the connection inside Keeptrusts. They then test two scenarios.

In the first scenario, an engineer opens the console login page and chooses corporate SSO. Authentication completes, and the session lands in the authenticated shell.

In the second scenario, a reviewer opens a chat or task workbench link while signed out. Keeptrusts redirects the user into sign-in, preserves the requested path, completes the SSO flow, and returns the reviewer to the requested workspace instead of a generic home screen.

That second test is where many integrations fail in other products. In Keeptrusts, it should be part of the standard validation, not an afterthought.

Implementation guidance​

There are a few habits worth adopting when you connect SSO.

First, test with real user roles, not only with the identity team’s highest-privilege admin account. SSO that only works for one privileged user is not ready.

Second, validate both console-first and workbench-first entry points. The console is not the only door into the product.

Third, stage the change with a limited cohort before treating SSO as the mandatory path for everyone. That gives you room to catch misconfigured callback URLs, unexpected provider-side errors, or role-mapping surprises before they become an organization-wide outage.

Fourth, make a deliberate decision about recovery paths. Keeptrusts supports password and non-password sign-in patterns alongside SSO where organization policy allows it, and administrators should choose that posture intentionally rather than by accident.

Finally, watch the administrative history after rollout. Identity changes are governance changes. You want a visible record of who enabled the connection, when the cutover happened, and how operators confirmed the result.

Why this matters operationally​

SSO is not just a convenience feature. In a governance platform, it affects access to policies, escalations, evidence, wallets, tokens, and knowledge assets. A fragmented identity flow weakens operator trust because people stop knowing whether a denied action is a policy problem, a role problem, or a broken login state.

When SSO is cleanly integrated, onboarding gets simpler and support load drops. New users can follow the same corporate sign-in they already know. Chat-first users do not need a separate explanation. Admins can expand access across teams without creating another island of credentials. And security teams get a login boundary that fits the organization’s existing identity controls.

That is the standard you want: identity that disappears into the normal working flow while remaining auditable and controlled.

Key takeaways​

  • Keeptrusts supports both OIDC and SAML for corporate SSO.
  • The platform uses a unified same-origin callback path at /sso/callback.
  • OIDC and SAML complete differently under the hood, but the operator workflow should feel consistent.
  • Always test console-first and chat-first entry paths before broad rollout.
  • Treat SSO activation as an operational change with explicit validation and follow-up review.

Next steps​