16 October update: the initial UAT rollout and further acceptance stages have taken place. This article preserves the 7 October snapshot; see current progress and remaining work.
What was delivered
On 7 October we completed another development stage for Kulinaryos authentication and authorization. Coordinated changes to the Go API, app, CRM, ADM and FIC GARA were merged into the UAT repositories. All five pipelines succeeded and published immutable images. Each image and its digest were confirmed in the registry.
This stage has not yet been deployed to UAT or promoted to production. Publishing the images prepares the release, but end-to-end consolidation still requires a reviewed migration, GitOps deployment and authenticated environment tests. This post follows the 3 October record, which covered the sign-in and recovery changes released at that time.
One person, explicit permissions
The new implementation uses the person's internal identifier and their association with the identity issued by ZITADEL. Email is a contact that can change; licenses, organization memberships and administrative powers follow explicit associations with the person. Changing a contact or choosing another sign-in method does not transfer these rights.
Registering a person also creates their CRM profile in the same transaction. CRM records the commercial source and license lifecycle; the Go API checks current rights on every request. Access considers organization, module, status and validity. When rights cannot be confirmed, access is denied.
Sign-in, recovery and sessions
The app, CRM, ADM and FIC received coordinated Google flows through ZITADEL and owner-managed account linking. Automatic linking requires the contact proofs defined by policy. When contacts differ, the owner can prove possession of the existing account without an individual approval queue.
Sessions use protected cookies and server-side revocation checks. Sign-out and password recovery update session state; recovery checks the current contact and uses single-use links. Tests also cover concurrent contact and password changes. Brevo remains the transactional email service.
Licenses and delegations
Issuance now requires an authorization with explicit scope: beneficiary, product, country, validity and issuance limit. Delegation, issuance and revocation leave audit records. Commercial paths check the required confirmation before activating rights; a pending payment does not release the product.
Suspension, expiry and revocation are checked during use. The interface follows the API's decision, including for an already-open session. The infrastructure proposal restricts UAT origins and includes FIC in promotion and image verification.
Evidence for this stage
- The API harness, using disposable PostgreSQL, synthetic OIDC and captured email, passed 1,624 tests for UAT code and 1,607 for code prepared for production, with no failures or skipped tests. Synthetic tests do not prove real Google or Brevo delivery.
- Local checks, tests and builds passed for the UAT frontends: 1,264 app tests, 61 CRM tests, 55 ADM tests and 98 FIC tests. Publication pipelines also succeeded.
- Read-only preflights inventoried the current environments. Manifest rendering, schema and architecture checks passed for the infrastructure proposal. Public probes proved health and anonymous-access denial; they do not prove the authenticated matrix.
What remains
The next stage is to review administrative UUID associations, staff associations and reconciliation of existing licenses. An authorized UAT migration and GitOps promotion of the five images follow, with rollback coordinates recorded.
Once the versions are deployed, acceptance must exercise controlled accounts: passwords, real Google sign-in, owner linking, recovery delivered through Brevo, delegation, issuance, suspension and revocation. It must also prove denial across organizations and modules, and app, CRM, ADM and FIC behavior for the same person with different powers. Preparing production code remains separate from any production deployment.