LastPass’ SSO implementation (including the generation of a hidden master password) is described here under the section “LastPass Federated Login Services” on page 12. This is how they are able to support SSO without having the user enter a second password and still meet their “zero-knowledge” policy.
The strategy varies slightly by identity provider but ultimately the user’s master password is derived from multiple key parts, one part typically stored at the identity provider (IdP) as a “user account attribute” (e.g. ADFS/AD) and one or more at the password store service provider (e.g. LastPass). A secondary mechanism is used for synchronization of user status (e.g. LastPass Active Directory Connector).
I believe this strategy permits the IdP to decrypt the user’s vault if they desire (whether by impersonation or simply having access to both the IdP and SP key parts). This might be a negative for the user but might be a positive for the entity (e.g. an enterprise needing to access a deceased/terminated employee’s credentials). Assuming Bitwarden went with this strategy, I’d think it would make sense to have an admin-level setting such as, “Allow users to override hidden master password”. If turned on, the user could be prompted at provisioning to provide an optional master password and the pros and cons of doing so; a “pro” being that the IdP could not decrypt their data and “con” being they’d have to provide the password every time.