[PM-40314] fix: Enforce Master Password policy on SSO/TDE vault unlock

[matt-livefront]

🎟️ Tracking

PM-40314

📔 Objective

Users signing in via SSO or TDE with a master password were not being checked against their organization's active Master Password policy, and were never prompted to update a non-conforming master password — unlike non-SSO logins, which already enforce this correctly.

Non-SSO login already runs this check via AuthService.checkMasterPasswordPolicies → requirePasswordChange, setting forcePasswordResetReason on failure so the existing AuthRouter+Redirects logic redirects to the Update Master Password screen. SSO and TDE master-password entry both converge on AuthRepository.unlockVaultWithPassword(password:), which never called this check.

• Capture IdentityTokenResponseModel.masterPasswordPolicy in AuthService.loginWithSingleSignOn, keyed by email, immediately after the identity token response is fetched — before branching into deviceKey / masterPassword / keyConnector / TDE-decryption-options handling, so it's captured regardless of which branch is taken. Also captured in loginWithTwoFactorCode, since an SSO/TDE login that also requires 2FA gets its final identity token response there instead, after the initial loginWithSingleSignOn attempt threw twoFactorRequired before it could cache anything.
• Add a new AuthService.checkMasterPasswordPolicyAfterUnlock(email:masterPassword:) method that consumes that cache (clearing it unconditionally on read, and only trusting it when the email matches, to avoid a stale policy leaking into an unrelated account's later unlock) and reuses the existing checkMasterPasswordPolicies orchestration, falling back to PolicyService.getMasterPasswordPolicyOptions() when nothing is cached.
• Call the new method from AuthRepository.unlockVaultWithPassword(password:) after a successful unlock, non-fatally (logged, not thrown) so a policy-check failure can never be mistaken for a wrong master password or block an unlock that already succeeded.
• This intentionally makes the check run on every master-password vault unlock, not just at login — a safe, backward-compatible improvement for the existing vault-timeout re-lock flow, since it only uses whatever policy data is already locally available and never forces an extra sync.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the new AuthService.checkMasterPasswordPolicyAfterUnlock(email:masterPassword:) method, the email-keyed ssoMasterPasswordPolicy cache populated in loginWithSingleSignOn / loginWithTwoFactorCode, and the non-fatal call added to AuthRepository.unlockVaultWithPassword(password:). I traced the SSO master-password, TDE "approve with master password", SSO+2FA, and plain-password+2FA paths, and confirmed the .authorizationCode guard correctly avoids double-checking password logins that already run the pre-auth check in getIdentityTokenResponse. Also verified the cache is not consumed on a failed unlock (the check runs after unlockVault succeeds), that requirePasswordChange prefers PolicyService data and only falls back to the cached token policy — which is the nil case immediately after login and before the first sync — and that UpdateMasterPasswordProcessor.syncVault() self-heals by clearing the reason when no policy turns out to apply. Test coverage is thorough and the new JSON fixture is picked up by the **/Fixtures/* glob in project-common.yml.

Code Review Details

• ❓ : Policy check now runs on every master-password unlock, so the Update Master Password redirect is reachable from inside app extensions (AuthRouter+Redirects.swift:35 checks forcePasswordResetReason above the isInAppExtension guard)
  • BitwardenShared/Core/Auth/Repositories/AuthRepository.swift:1162

[claude]

❓ QUESTION: Running this on every master-password unlock means the Update Master Password screen can now be triggered from inside an app extension.

Trace and consideration

VaultUnlockProcessor.unlockVault() calls unlockVaultWithPassword and then coordinator.handleEvent(.didCompleteAuth), which routes through AuthRouter.completeAuthRedirect():

if account.profile.forcePasswordResetReason != nil {
    return .updateMasterPassword
}

if !isInAppExtension {
    ...
}

The forcePasswordResetReason check sits above the isInAppExtension guard, so this path applies in the AutoFill/Share/Action extensions too. An SSO/TDE user whose master password violates the policy — precisely the population this PR targets — may well perform their first master-password unlock inside the AutoFill extension. They would then be dropped into Update Master Password mid-autofill (which triggers settingsRepository.fetchSync() and, on success, logout) instead of getting their credential.

This was reachable before only via a reason already persisted from a main-app login; this change makes the extension itself a place where the reason first gets set. Was the extension context considered? If enforcement should be main-app-only, gating the new call (or the router's redirect) on isInAppExtension would keep autofill unaffected — the reason would still be set on the next main-app unlock. Note AppProcessor.removeMasterPassword already applies exactly this kind of guard.

The PR description discusses the vault-timeout re-lock flow but not extensions, so flagging in case it was an unconsidered side effect rather than an intentional trade-off.

[fedemkr]

Perhaps something to raise to Product.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.80%. Comparing base (b714401) to head (5ed3325).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2980      +/-   ##
==========================================
+ Coverage   79.50%   81.80%   +2.29%     
==========================================
  Files        1170     1047     -123     
  Lines       75192    67934    -7258     
==========================================
- Hits        59781    55572    -4209     
+ Misses      15411    12362    -3049     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fedemkr]

Looks good, just two questions that I think Product would need to revise.

[fedemkr]

🤔 I think there's an edge case here where it would fail where you have a user with two SSO accounts on different servers but using the same email and the stale policy from one account leaks into the other, so given the email is the same this would actually be returning the policy.
Not sure if that would be a plausible scenario in real life but perhaps something to run by Product so they're aware. If necessary we could fix this in a future PR as there are slim chances of happening.

[fedemkr]

Perhaps something to raise to Product.