feat(iam): email-based login for Datum Cloud

[drewr]

Summary

• Adds a provisional enhancement document proposing email/password login for Datum Cloud
• The platform currently requires Google or GitHub OAuth for all user accounts
• Documents the specific changes needed across four repositories to enable this

Architecture

System Context	Container View
New SMTP email delivery service is a distinct external system, separate from the Milo notification path.	The DefaultEmailProvider (red) was the blocking pre-requisite. Two independent email paths are shown.

What this proposes

Minimal changes, maximum leverage of existing infrastructure:

1. datum-cloud/infra (step 0) — Add a zitadel.SmtpConfig Pulumi resource pointing at Resend's SMTP relay (smtp.resend.com:587) with a dedicated API key, sender noreply@mail.datum.net. Store the API key in Pulumi ESC as zitadel-setup:smtp-password. Validate end-to-end email delivery in staging before proceeding.

2. datum-cloud/infra — Update the Pulumi-managed LoginPolicy to set disableLoginWithEmail: false, allowRegister: true, and hidePasswordReset: false. Add a PasswordComplexityPolicy for the Datum Cloud organization. Depends on step 1.

3. datum-cloud/milo-os (upstream) — Extend the AuthProvider enum on User.Status.LastLoginProvider from [github, google] to [github, google, email]. Regenerate CRDs.

4. datum-cloud/auth-provider-zitadel — Fix parseIDPUserData in the actions server to return AuthProviderEmail instead of an error when Zitadel's local provider fires an idpintent.succeeded event.

5. datum-cloud/cloud-portal — Replace hardcoded mock data in AccountSignInMethodSettingsCard with live UserIdentity API data. Add "Manage" / "Connect" / "Set password" actions for each provider.

Nothing in auth-ui needs to change. The login v2 app already has all the required routes (/register, /register/password, /password, /verify, /password/set, /password/change). They are currently gated by loginSettings.allowUsernamePassword, which this proposal enables.

Resolved: SMTP provider

Zitadel will use Resend via smtp.resend.com:587 — the same delivery service already used by the Milo notification system. A dedicated Resend API key will be provisioned for Zitadel (separate from the one held by email-provider-resend) so credentials can be rotated independently. The mail.datum.net sending domain is already verified in Resend. Secret lives in Pulumi ESC; no external-secret.yaml change is needed.

Resolved: registration approval

Email self-registration will go through the existing waitlist/approval gate at launch (no code change needed — the UserWaitlistController already handles this). Once anti-fraud infrastructure is validated in production, open registration can be activated by toggling a single flag in the fraud-check service. The LoginPolicy does not change between modes.

Test plan

• Set zitadel-setup:smtp-password in Pulumi ESC (staging); run pulumi up
• Register a test account via email in staging; confirm verification email arrives within 60s
• Click verification link; confirm account is activated
• Use "Forgot password?" on the login page; confirm reset email arrives
• Confirm User.Status.LastLoginProvider is set to email after email login
• Confirm new email signups land in Pending waitlist state
• Confirm existing OAuth users can add email credentials via account settings
• Confirm existing email users can add Google/GitHub via account settings
• Confirm LoginPolicy rollback disables email login without affecting existing sessions

[scotwells]

Is this something we want to do? We intentionally avoided password based logins in the past because of the security risks they bring to the platform. We've talked about supporting passkeys as an alternative to identity provider based logins.