Auto-join SSO users to first shared search space on login

[jawad-khan]

Description

ProxyAuthMiddleware now checks whether the authenticated user has any non-owner search space membership. If not, they are added to the first shared search space (not owned by them) with the default role.

Motivation and Context

FIX #

Screenshots

API Changes

• This PR includes API changes

Change Type

• Bug fix
• New feature
• Performance improvement
• Refactoring
• Documentation
• Dependency/Build system
• Breaking change
• Other (specify):

Testing Performed

• Tested locally
• Manual/QA verification

Checklist

• Follows project coding standards and conventions
• Documentation updated as needed
• Dependencies updated as needed
• No lint/build errors or new warnings
• All relevant tests are passing

[UsamaSadiq]

Let's remove the comments where another app is being referenced as the solution. This comment is not needed anymore.

[awais786]

Security follow-up — per-request placement created an un-revokable membership path

Heads-up that the per-request placement here (current_active_user invoking auto_join_smb_search_space on every authenticated request) interacts with the hard-delete DELETE /searchspaces/{id}/members/{membership_id} endpoint (rbac_routes.py:705) to make admin removal silently a no-op:

1. Owner Alice calls DELETE /api/v1/searchspaces/<id>/members/<bob-membership-id> to evict Editor Bob → row deleted, returns 200.
2. Bob's frontend polls any authenticated endpoint with his Bearer JWT.
3. current_active_user runs → auto_join_smb_search_space(bob.id) → no membership row → INSERT (Editor again).
4. Bob retains documents:create/read/update, chats:create/read/update, members:invite, connectors:create/update. He cannot be removed at all while his SSO sign-in still works.

SearchSpaceMembership has no tombstone column (no removed_at, is_active, is_blocked on the model — verified at db.py:1811-1857), so the auto-join function has no signal that the user was previously evicted.

The per-request placement was deliberate per the function's docstring ("Safe when auth uses Bearer JWT only: runs from current_active_user as well."), to handle the JWT-only path where the proxy middleware doesn't fire. The trade-off (un-revokability) wasn't called out in the PR description.

Fix

#21 moves the call to UserManager.on_after_register (one-shot at user creation). Both registration paths still trigger it:

• Standard FastAPI Users register flow
• ProxyAuthMiddleware._resolve_user already invokes on_after_register after creating a user (proxy_auth.py:179-209)

So new users are still auto-joined exactly once. Removed users stay removed.

Trade-off acknowledged

The original design intentionally caught the case "user's first auth is JWT, no on_after_register ran on the proxy path" via per-request enforcement. The fix loses that case — users who registered BEFORE the SMB workspace existed aren't retroactively auto-joined and need a one-time INSERT INTO search_space_memberships ... from an operator. Worth knowing if your deployment relied on the catch-up behavior.

Refs

• Fix PR: fix(auth): move SMB auto-join from current_active_user to on_after_register #21
• External writeup: awais786/sso-rules-moneta surfsense-security.md §"Finding 1 (re-audit 2026-05-15)" (PR pending: awais786/sso-rules-moneta#2)

cc @jawad-khan @UsamaSadiq for context — not a critique of the merge, the per-request choice was reasonable for the JWT-only-path concern, just an interaction with the DELETE endpoint that's worth documenting in the followup.

🤖 Generated with Claude Code