Tomcat Single Sign on
You set up tomcat single sign on by enabling the built-in valve in your host settings. This valve shares one login state across all web apps on that virtual host. Engineering teams often use this setup so users log in just once per day. Still, shared sessions can create risk if app roles are too broad. When one user gets admin rights in one app, they might get them everywhere. Teams must plan role names with care before they turn this feature on. How tomcat single sign on works across web apps
Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up tomcat single sign on by enabling the built-in valve in your host settings. This valve shares one login state across all web apps on that virtual host. Engineering teams often use this setup so users log in just once per day. Still, shared sessions can create risk if app roles are too broad. When one user gets admin rights in one app, they might get them everywhere. Teams must plan role names with care before they turn this feature on.
How tomcat single sign on works across web apps
In a standard setup, each Java web app manages its own user logins. If a company runs five apps on one server, users must log in five times. The single sign on valve fixes this issue at the container host level. When a user logs into the first app, the server checks the central realm. The realm holds all the user names, passwords, and role maps. It can read from a database, a directory server, or an external identity provider.
Once the realm confirms the user, the server creates a special session cookie. The browser stores this cookie and sends it with every request to that host. When the user clicks a link to a second app, the valve reads the cookie. It sees the valid login state and attaches the user identity to the request. The second app skips the login screen and checks if the user has the right role.
For this flow to work, all apps on the host must share the same realm. If apps define their own separate realms, the shared cookie cannot verify the roles. You also need to align role names across all your web apps. If one app uses a general role name, another app might grant too much power. Teams often integrate external identity protocols like SAML or OIDC to handle the login step. These protocols let companies enforce multi-factor checks before the server ever creates a session cookie.
What native login sharing solves and where gaps remain
Native login sharing solves password fatigue for your users and support teams. Users do not have to type passwords over and over as they switch tools. Support teams spend less time resetting forgotten passwords for five different internal apps. It also gives security teams one central place to turn off a user account. When someone leaves the team, disabling their directory account stops their login right away.
Still, a login valve only checks who enters the front door of the app. It does not track or control what the user does after they log in. Once the session starts, the server trusts every action that fits the assigned role. If an engineer logs into an admin app, they can run any command in it. The native valve does not log the specific queries or data requests they run.
Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This creates a blind spot when engineers need direct server or database sessions for debugging. A shared web login cannot inspect live traffic or rewrite sensitive fields in query results. For example, it cannot mask emails, phone numbers, card numbers, or national IDs in flight. Teams still need a way to govern individual actions and commands during active work sessions.
Best practices for managing shared server sessions
First, always run your server over encrypted transport so attackers do not receive unmasked session cookies. Set the secure flag and the HTTP-only flag on all cookies the host sends. Second, keep session timeout values short for apps that handle sensitive business data. When a user logs out of one app, the valve ends the session for all apps. Make sure every app has a clear logout button that triggers this host-wide reset. Finally, review your role maps every quarter to ensure users only keep the roles they need.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the built-in valve work across multiple server instances?
The basic valve only shares sessions across web apps on a single virtual host. If you run a cluster of servers, you must use the cluster valve version instead. That version copies the login state across all nodes in the server cluster.
What happens when a user logs out of one web app?
When a user logs out of any connected app, the host destroys the shared token. This action logs the user out of all other apps on that host right away. They will have to log in again to use any app on the server.
Can apps use different login methods with single sign on?
Yes, one app can use a form login while another uses basic browser login. As long as they share the same host and realm, the shared cookie works. Once the user logs into one app, the others accept the shared identity.