Currently, Rushomon operates on a strict multi-tenant SaaS model where every new user signup automatically provisions a brand new personal organization.
While this works for public deployment, it creates friction for internal company/organizational workspaces like mine. If an organization wants all their employees to share a single workspace, admins currently have to manually invite every single employee, or users end up scattered across isolated personal orgs.
While this could be solved using a global instance-level "workspace mode" setting, I think a more scalable and flexible solution is just in time domain provisioning.
To securely implement this without forcing an immediate frontend login flow redesign, I propose separating the concept of domain authority (claiming) from user membership (joining).
1. The claiming flow (proving domain authority)
- An admin creates an account the usual way, which automatically generates a new organization.
- The admin navigates to their organization settings page, and sees a new section "organizational domains" with an "add domain" button.
Option A: "Verify via DNS"
- The admin is given a txt entry to add to their domain's dns
- Rushomon then confirms that with a simple dns lookup
Option B: "Configure single sign-on (OIDC)"
- The admin configures a custom OIDC implementation by providing a client ID, secret, and Issuer URL (e.g from their google workspace admin console).
- Rushomon performs a one-time verification flow by forcing the Admin to authenticate through those provided credentials. If successful, we extract the domain (e.g the hd claim) directly from the returned verification token. This proves the admin has authority over that domain, and the domain is marked as verified for that organization.
2. The auto-join flow (proving membership)
Because the domain is now securely locked to the organization, we do not need to alter the frontend UI.
- The existing global "sign in with google" button remains as it is.
- When a new user signs in via google, Rushomon checks the token payload. If the hd (hosted domain) claim matches a verified domain in our database, the user is automatically added to that organization as a member, bypassing the personal organization creation step.
- Users would still have the option of creating a separate organization, but the default would be for links they create to remain consolidated within the existing verified organization.
- When an existing user signs in, if their email matches, they are added to the organization, but keep their previously created personal organization / links. (A case could be made for consolidation, but this is the simplest approach for now.)
Future Roadmap
This architecture solves the immediate problem for Google Workspace-based organizations like mine gracefully, but it also creates the exact database foundation needed for future enterprise features:
- Home realm discovery: Adding an initial "enter your email" field to the login page to support routing users to other third-party oidc providers (e.g. entra) or the oidc flow already configured for google.
- This would seamlessly flow into oidc for relevant domains, existing sso options for personal users, or email/password based signup.
This initial step that verifies the domain ownership and bypasses the personal organization creation is all I need for our use. My first thought when considering this feature was the OIDC/SSO, but given that google SSO is already in place, and the OIDC setup would be more work, I'd lean towards doing DNS-based verification first for this. I'd love to get your thoughts on this approach and then I'm happy to work on the pr!
Currently, Rushomon operates on a strict multi-tenant SaaS model where every new user signup automatically provisions a brand new personal organization.
While this works for public deployment, it creates friction for internal company/organizational workspaces like mine. If an organization wants all their employees to share a single workspace, admins currently have to manually invite every single employee, or users end up scattered across isolated personal orgs.
While this could be solved using a global instance-level "workspace mode" setting, I think a more scalable and flexible solution is just in time domain provisioning.
To securely implement this without forcing an immediate frontend login flow redesign, I propose separating the concept of domain authority (claiming) from user membership (joining).
1. The claiming flow (proving domain authority)
Option A: "Verify via DNS"
Option B: "Configure single sign-on (OIDC)"
2. The auto-join flow (proving membership)
Because the domain is now securely locked to the organization, we do not need to alter the frontend UI.
Future Roadmap
This architecture solves the immediate problem for Google Workspace-based organizations like mine gracefully, but it also creates the exact database foundation needed for future enterprise features:
This initial step that verifies the domain ownership and bypasses the personal organization creation is all I need for our use. My first thought when considering this feature was the OIDC/SSO, but given that google SSO is already in place, and the OIDC setup would be more work, I'd lean towards doing DNS-based verification first for this. I'd love to get your thoughts on this approach and then I'm happy to work on the pr!