🔐

SSO

Zeus SSO is treated here as one logical project with production and development environments. The intended model is parity between zeus01.lan and zeus01-dev.lan; where current evidence is incomplete or inconsistent, this page marks that explicitly as parity drift or verification work rather than splitting it into separate projects.

Production

Host: zeus01.lan

Verified Reference environment

Confirmed SSO codebase at /APPS/SSO.
Reviewed plan describes a TypeScript/Node monorepo using pnpm.
Auth/session handling appears to use Lucia.
Persistence appears to use SurrealDB.

Development

Host: zeus01-dev.lan

Expected to mirror prod Needs verification

Expected to correspond to the same Zeus SSO codebase as production.
The reviewed plan did not confirm /APPS/SSO in the checked dev location.
That should currently be treated as parity drift or incomplete verification, not a separate project.

Parity status

Dimension	zeus01.lan	zeus01-dev.lan	Status
Project identity	Zeus SSO	Zeus SSO	Same logical project
Code location evidence	`/APPS/SSO` confirmed	Checked location did not confirm equivalent path	Needs verification
Intended relationship	Production	Development	Expected parity
Operational interpretation	Current reference	Possible drift	Do not split into separate projects

Plan reference

The main comparison plan referenced by this page is:

/home/jd/.windsurf/plans/green-link-auth-vs-zeus-sso-a2ee05.md

This is the plan comparing Green-Link local auth versus adopting Zeus SSO, and it is the main source for the verified findings summarized here.

Verified findings from the reviewed plan

The Zeus SSO implementation on production looks like a reusable authentication service rather than a simple placeholder.
The integration model appears to be a custom redirect/session validation flow rather than conventional provider-branded OAuth screens.
The reviewed recommendation for Green-Link was local auth first, while staying SSO-ready for later integration.

Additional context

Because the dev and prod hosts are conceptually one project, the right way to model mismatches is through environment status and verification notes. Treating zeus01.lan and zeus01-dev.lan as separate projects would encode a deployment inconsistency into the project taxonomy, which would be misleading once parity is restored.

Recommended interpretation: one project, two environments, with any mismatch shown as parity status rather than separate ownership.