Keycloak Home IdP Discovery
Keycloak home idp discovery routes users to their right login provider based on email domain. You set up an identity step that reads the email and redirects the user. Many teams build this flow when they serve partners or acquired companies. Still, routing users to the right login page only checks who they are. If you grant broad roles after login, users gain too much power over production data. How keycloak home idp discovery works in practice Standard login pages often show a long list of b
Keycloak + AI-Assisted Vulnerability Discovery: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Keycloak home idp discovery routes users to their right login provider based on email domain. You set up an identity step that reads the email and redirects the user. Many teams build this flow when they serve partners or acquired companies. Still, routing users to the right login page only checks who they are. If you grant broad roles after login, users gain too much power over production data.
How keycloak home idp discovery works in practice
Standard login pages often show a long list of buttons for outside providers. Users get confused and click the wrong company login button. Domain discovery fixes this problem by splitting the login screen into two steps. First, the user types their work email address without a password. The server splits the email string and reads the domain name after the symbol.
Next, the server checks that domain against its list of registered identity providers. Each provider holds a saved list of domains that it owns and manages. When the system finds a match, it skips the local password screen. It sends the browser straight to the external identity provider for that domain. If no provider matches the domain, the flow falls back to a local password prompt.
Mapping claims and roles after the redirect
Once the outside provider checks the user, it sends a signed token back. The server reads the token claims and links them to a local user profile. Admins set up mappers that turn external group claims into internal app roles. This step lets teams manage user groups inside their main home directory.
Teams must test how the login flow handles users who belong to multiple domains. A clear naming rule for external groups prevents role clashes across different partner companies. Admins should also require verified email claims from every connected external identity provider. Without this check, an outside system could assert an email domain it does not own.
Where identity routing stops in production
Home provider discovery solves the front door problem for web apps and consoles. It proves user identity and assigns coarse roles at the start of a session. Yet this login check cannot see what a user does inside a database or server. Once an engineer passes the login check, their session often gets full network reach.
Keycloak + AI-Assisted Vulnerability Discovery: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Coarse group roles do not stop a bad query from dropping a production table. They also do not stop a query from pulling raw customer records in bulk. Identity providers only issue tokens and cannot read live database queries or shell commands. Real security requires checking every single command and masking fields like emails, phone numbers, card numbers, or national IDs in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does domain discovery handle unknown email domains?
When an email domain matches no outside provider, the flow stays on the local server. You can ask for a local password or block the login attempt right away.
Can two identity providers share the same email domain?
Sharing one domain across two providers creates a conflict during the lookup step. The system picks the first match it finds, so keep domain mappings unique.
Does provider discovery secure direct database sessions?
No, provider discovery only routes browser login flows to the right identity system. It does not inspect SQL statements or mask sensitive columns during a database session.
Teams that document these role rules and review logs each month catch config drift early. Clear ownership for each role keeps live systems simple to run and easy to audit across the whole team.