Stakeholder review · three protection patterns on the same conceptual endpoint · all data shown is fake
The /files/ service will eventually expose S3-backed copies of /mnt/md0 (Munin → S3 via DataSync). Before wiring real data we want to align on how access is gated. Three options are pre-staged below; click through, try them, then weigh in.
Single shared username/password in the browser. Enforced at the Nginx layer; no identity provider required.
Pros: trivial to provision, no IdP dependency, works in any client (browser, curl, scripts).
Cons: no per-user identity, no audit trail, password sharing is invisible, rotating means everyone gets new creds.
Try it: /files/basic/ — credentials stakeholder / review
Real-identity sign-in via OIDC (AWS Cognito, UW SSO, Google Workspace, …). Per-user audit, group-based policy, MFA support.
Pros: real identity, audit trail, per-user revoke, MFA, group/role-based scoping.
Cons: needs an IdP decision (long-lived org choice), more setup, slightly slower for ad-hoc external users.
Try it: /files/login/ — login form is fake; click "Sign in" to see the post-auth view.
Programmatic access via a long-lived token in a request header. Best fit for scripts, CI pipelines, and external tools.
Pros: machine-friendly, no browser flow, easy to rotate per consumer.
Cons: token leaks are silent, no MFA, requires a separate token-issuing flow for humans.
Try it: /files/token/ — page shows curl examples, real token gate behind the data endpoint.
Add comments on the EPS-HPC Confluence page (link forthcoming) or in the EHC ticket created for this review. Specifically interested in: which audiences each option fits, how rotation and bus-factor are handled, and any red lines (e.g. "must have audit"; "must work without an IdP").