Double SSO
To set up double sso, you link two identity providers in a trust chain. Users log in to the first provider and then pass through a second check. Teams often build this flow during company mergers or when using external cloud consoles. They map broad group roles from the first system into the second system. When those mapped roles are too wide, one login gives users too much power. How a double sso workflow runs in practice A double sso setup happens when two separate login systems must work t
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up double sso, you link two identity providers in a trust chain. Users log in to the first provider and then pass through a second check. Teams often build this flow during company mergers or when using external cloud consoles. They map broad group roles from the first system into the second system. When those mapped roles are too wide, one login gives users too much power.
How a double sso workflow runs in practice
A double sso setup happens when two separate login systems must work together. First, a user opens an internal portal and signs in with their main account. That primary identity system checks their password and two-factor token. Next, the user clicks an icon to open a cloud tool or database portal. Instead of opening right away, that tool asks its own identity provider to verify.
In a standard setup, the two systems share trust through SAML or OIDC tokens. The first provider sends a signed claim to the second provider. If the link is missing or broken, the user must type a second password. This double login loop frustrates engineers who switch tools all day. Even when federation links the two systems, group mapping creates a huge headache.
Admins have to sync role names across both directories to keep permissions right. When teams rush this step, they often map everyone to a single admin role. That shortcut stops login errors, but it hands out full write rules to everyone. Soon, every developer holds superuser keys inside the downstream system.
Why login checks leave gaps during live sessions
Linking two identity providers solves the problem of who can enter the front door. It verifies that an employee belongs to the right team before starting a session. Still, identity checks stop working the moment the login handshake finishes. Neither identity provider can see what the user runs inside the database or server.
Once inside, an engineer with a mapped role can run any query or script. If they run a bad delete statement, the identity provider will not stop it. If they pull a table full of customer emails, the login log stays quiet. Identity systems only record the timestamp when the user signed in.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
They do not record the actual SQL queries or shell commands run after login. Also, shared roles make it hard to trace who ran a specific command. The target database only sees the generic mapped role, not the real person. To stay safe, teams need controls that check every single command in flight.
Managing role mapping without broad permissions
To reduce risk in a dual login setup, teams must tighten role mappings first. Start by auditing every group that passes from the primary directory to the second. Remove broad admin mappings that grant full read and write power by default. Instead, split roles by job need, separating read rules from write rules.
Even with clean groups, static roles still grant standing privileges all day long. A user who needs to fix one production row gets full table permissions. You also need a way to inspect live queries and mask sensitive fields. Masking rewrites matched fields like card numbers or national IDs in query results. Adding command-level checks turns a basic login gate into true runtime security.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do users get prompted to log in twice?
Users see two login screens when two tools use different identity systems without federation. You can fix this by linking both systems with SAML or OIDC trust rules.
Does double sso make database sessions safer?
It only checks user identity before the session starts. Once the user logs in, it cannot stop risky queries or mask sensitive data.
How do teams audit actions across two identity providers?
Identity logs only show login times and group claims. To see real actions, you must log each query and command alongside the user email.