Fix SSO_ONLY users unable to accept org invites (#7072)#7079
Fix SSO_ONLY users unable to accept org invites (#7072)#7079pmhnam wants to merge 1 commit intodani-garcia:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses a gap in the organization invitation flow where SSO_ONLY users (no master password) can’t complete the email-based invite acceptance step, by auto-accepting invites for already-existing SSO_ONLY users so an admin can proceed to the confirmation step.
Changes:
- Auto-accept organization invitations for existing
SSO_ONLYusers during invite creation. - Auto-accept invitations for
SSO_ONLYusers during the reinvite flow (and clear any stored invitation).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
SSO_ONLY users have no master password and cannot use the email-based invite acceptance flow. This change auto-accepts organization invitations for SSO_ONLY users who already exist, allowing them to proceed directly to the confirmation step by an admin. Fixes dani-garcia#7072
pmhnam
force-pushed
the
fix/sso-only-org-invite-7072
branch
from
69899a6 to
994ee0d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Only send the invite email if the member is still in the Invited state. | ||
| // SSO_ONLY users are auto-accepted above and should not receive an invite | ||
| // email with a link they cannot use. | ||
| if CONFIG.mail_enabled() && member_status == MembershipStatus::Invited as i32 { |
There was a problem hiding this comment.
When member_status is force-set to Accepted (e.g., for SSO_ONLY users), the org policy checks that normally run during acceptance (OrgPolicy::check_user_allowed, see src/api/core/mod.rs:275+) are bypassed here. This can leave members in Accepted state even if 2FA/SingleOrg policies would forbid joining. Consider running OrgPolicy::check_user_allowed before persisting an Accepted status (or otherwise ensuring policies are enforced at this transition).
| let mut member = member; | ||
| member.status = MembershipStatus::Accepted as i32; | ||
| member.save(conn).await?; |
There was a problem hiding this comment.
This auto-accept path sets member.status = Accepted without enforcing OrgPolicy::check_user_allowed (2FA / SingleOrg). The regular acceptance flow enforces these policies; consider applying the same check here before saving the updated membership status.
BlackDex
left a comment
BlackDex
left a comment
There was a problem hiding this comment.
I'm not sure if this will work at all, not tested it, not looked at it that good.
But the main flow i see that there is an assumption that there is no master-password for SSO users, which is not correct.
Maybe this changes your way of thinking regarding this PR.
Again, i have not validated if this works or not, but since there are master-passwords needed for SSO users, this whole PR is probably wrong.
| // SSO_ONLY users have no master password and cannot use the email invite | ||
| // acceptance flow, so automatically accept them |
There was a problem hiding this comment.
SSO_ONLY User do have a master-password, not sure why you think this isn't the case.
I'm not sure regarding the flow though how that works. But every user still needs a master-password.
SSO In Bitwarden isn't just login.
|
|
||
| if CONFIG.mail_enabled() { | ||
| if CONFIG.sso_enabled() && CONFIG.sso_only() && user.password_hash.is_empty() { | ||
| // SSO_ONLY users have no master password and cannot use the email invite |
There was a problem hiding this comment.
Same here, this statement is not true
Summary
Fixes #7072
SSO_ONLY users (users who authenticate via SSO and have no master password) cannot accept organization invites because the invite acceptance flow requires a master password login.
Changes
send_invite: Auto-set membership status toAcceptedfor existing SSO_ONLY users when they are invited to an organization_reinvite_member: Prioritize SSO_ONLY auto-accept before attempting to send an email invite that the user cannot act onHow it works
When
SSO_ENABLED=trueandSSO_ONLY=true, users who have an emptypassword_hash(indicating they authenticated only via SSO) are automatically moved toAcceptedstatus when invited. The admin can then confirm them normally through the admin console.Testing