Skip email entry on login when SSO is the only auth method

[IacopoSb]

Why

Today, with SSO_ONLY enabled, the login page still shows the email input field and the "Remember email" checkbox, and clicking the SSO button requires entering an email even though that email is ignored by the backend (single-tenant vaultwarden uses FAKE_SSO_IDENTIFIER server-side).

Two small changes were made in libs/auth/src/angular/login/login.component.{html,ts}:

• class="vw-email-form-field" on the <bit-form-field> wrapping the email inputs, and class="vw-remember-email" on the Remember-email <bit-form-control>. These hooks let the vaultwarden SCSS template hide both elements when sso_only=true.
• handleSsoClick() now tolerates an empty email: if the form has no email it skips validation and proceeds. Single-tenant vaultwarden does not require an email to start the SSO flow.

Test done

• Built locally with make full. With SSO_ENABLED=true SSO_ONLY=true and the companion vaultwarden SCSS change, the login page shows only the "Continue with SSO" button.

[stefan0xC]

that email is ignored by the backend

Last time I checked dani-garcia/vaultwarden#6793 (comment) it was not ignored but it is actually used to determine the 2FA remember token saved on a client. So by not entering a mail address you will always always have to enter your second factor. This would be a client side limitation until upstream changes their behavior (or we make it possible to skip 2FA for SSO, as suggested in dani-garcia/vaultwarden#6833).

vw_web_builds/libs/auth/src/angular/login/login.component.ts

Lines 609 to 615 in 4c96310

	// Vaultwarden has a single SSO configuration so the org identifier is always
	// FAKE_SSO_IDENTIFIER. Pass it explicitly so the /sso component skips the
	// "type your organization SSO identifier" prompt and proceeds to the IdP.
	await this.loginComponentService.redirectToSsoLoginWithOrganizationSsoIdentifier(
	email,
	"00000000-01DC-01DC-01DC-000000000000",
	);

I'm not sure how I feel about this change though. I mean I think this currently is a bit messy and I'm not sure if that would further prevent changes to the master password policy on the org level (as discussed in dani-garcia/vaultwarden#7163 (comment)) if we use the FAKE_SSO_IDENTIFIER here. Personally I think this should be fine to streamline the SSO experience as assumed by the comment but maybe @Timshel could chime in and confirm that this is something we actually want? I.e. if we should diverge from upstream by not having SSO related with a single organization at all.

Besides that those two reservations this change works just fine.

[Timshel]

I probably would recommend setting the identifier in the logic which try to restore it from storage (cf probably should be in an else branch 🤔 ) this way if a different value is set by an url parameter it won't be overridden (might happen in the invitation flow).

No idea for 2FA would have to do some tests

Edit: for the password policies made more tests and even with latest change the correct org policies can still be used. So it should have no impact.
It has a certain logic since SSO is activated globally no need to check the user email, and we can't really trust the input anyway until the user is authenticated.