[M0-S][AUTH] Bootstrap the platform owner and establish recoverable administrator access

[andreazedda]

Problem

The internet-exposed bmyCure4MM deployment currently has no governed guarantee that the platform owner can authenticate as an administrator. The current application routes expose Django admin at /admin/, but the normal application login contract is incomplete and LOGIN_URL points to /admin/login/.

A deployment that contains protected product functionality but no recoverable owner identity cannot approve users, administer access, or complete authenticated acceptance.

Verified current state

• /admin/ exists in the Django URL configuration.
• LOGIN_URL=/admin/login/.
• No deployment-managed owner bootstrap contract is present in the canonical repository.
• Local documentation only describes an optional manual manage.py createsuperuser step.
• A normal non-staff user cannot authenticate through Django admin by design.
• Creating or promoting an arbitrary synthetic staff user is not an acceptable substitute for a governed owner identity.

Objective

Guarantee that every governed production installation has exactly one recoverable initial platform-owner identity, provisioned from deployment secrets and able to administer access without embedding credentials in source code, manifests, images, logs, Notion, Trello, or CI artifacts.

Required design

1. Idempotent owner-bootstrap command

Create a management command or application service such as:

bootstrap_platform_owner

Inputs must come from runtime configuration/secrets, for example:

PLATFORM_OWNER_USERNAME
PLATFORM_OWNER_EMAIL
PLATFORM_OWNER_DISPLAY_NAME

The actual email address and any credential material must remain in the runtime secret store, not in Git.

The command must:

• create the owner only when absent;
• reconcile the expected owner identity without creating duplicates;
• fail closed on conflicting owner identities;
• be safe to rerun;
• never print passwords, reset tokens, session identifiers, or full secret values;
• emit a privacy-safe audit result.

2. First-access credential flow

Do not ship a static default password. Use one of these governed paths:

preferred: account created with unusable password → one-time password-set link
fallback: random one-time credential sourced from a Secret → mandatory change at first login

The one-time credential or token must expire and be revocable.

3. Deployment integration

Run owner bootstrap exactly once per release through a migration-adjacent Kubernetes Job or equivalent controlled deployment action—not from every web pod startup.

Required ordering:

database ready
→ migrations complete
→ owner bootstrap
→ authenticated owner smoke test
→ deployment acceptance

4. Separation of duties

The platform owner may retain Django superuser access for recovery and configuration, but routine demo-account approval should use a dedicated least-privilege product role such as Access Approver, not require unrestricted Django admin for every action.

5. Recovery and revocation

Document and test:

• password reset;
• owner email change under dual confirmation or explicit break-glass procedure;
• account lockout recovery;
• session invalidation;
• credential rotation;
• owner bootstrap after database restore;
• duplicate/conflict rejection.

6. Admin exposure

Production admin access must be protected by the M0-S security profile. Evaluate restricted network access, stronger authentication/MFA-ready architecture, rate limits, audit events, secure cookies, CSRF, HTTPS and session controls. Public product access must not imply unrestricted public administration.

Tests

• fresh database creates exactly one owner;
• rerun creates no duplicate and changes nothing semantically;
• conflicting username/email fails closed;
• no password/token appears in stdout, logs, manifests or test artifacts;
• owner can complete first password setup and authenticate;
• ordinary users remain non-staff/non-superuser;
• restored database preserves or safely re-establishes owner access;
• admin and product-role authorization remain distinct.

Acceptance criteria

• A versioned owner-bootstrap contract exists.
• Production deployment provisions the configured owner idempotently.
• No static or source-controlled provisional password exists.
• First access requires a one-time, expiring credential flow and password setup/change.
• The owner can reach the administrative surface after deployment.
• Routine access approval can be delegated to a least-privilege Access Approver role.
• Recovery, rotation, revocation and restore procedures are documented and tested.
• Security, audit, PHI/secret and deployment gates pass.

Dependencies

Coordinate with:

• [M0-S][SECURITY] Enforce object-level patient authorization, RBAC, and auditable access #8 object-level authorization and RBAC;
• [M0-S][SECURITY] Enforce production HTTPS, security headers, CSP, and iframe policy #9 production HTTPS/security profile;
• [M0-S][DEPLOYMENT] Build a production-grade settings, database, container, and runtime architecture #17 production runtime/deployment architecture;
• [M0-S][OBSERVABILITY] Add privacy-safe structured logging, audit events, metrics, and health checks #21 privacy-safe audit and observability.

Non-goals

This issue does not create public self-service activation and does not grant demo users access to private patient-derived data. The approval-gated user lifecycle is tracked separately.