Repository navigation
Configurator MVP: verify organisation tenants and STACKIT user bindings #91
Description
Current Status (2026-10-06)
Primary STACKIT device login, verified human identity, tenant/role/owner checks and the optional user-bound GitHub connector are implemented. The authoritative human organization-binding path is activated and accepted in the existing real customer organization. Two independent customer organizations and production-client acceptance remain open. Local evidence does not establish least-privilege execution grants or production OIDC approval.
- Implement the authoritative human IAM organization-binding path: exact-resource effective permissions and the complete official owner-role permission set using the same verified human device-grant token; explicit separate confirmation; immutable SQL-generated authorization evidence and idempotent binding receipt; fresh session/role/expiry/revocation checks.
- Establish and accept the authoritative tenant-to-STACKIT-organization binding in the intended runtime. Typing an ID, possessing a service-account key or passing local HTTP fixtures is not live human organization-admin proof.
- Bind application-owner records to verified human STACKIT identity; use the trusted identity rather than client-provided owner/email. Do not merge accounts solely by email.
- Define least-privilege provisioning/ownership permissions and verify actual API/provider behavior (Create projects without default owner role #69).
- Implement bounded platform-job credential grants: immutable job/tenant/owner/preparation/organization/profile/version/key/manifest/operation bindings, expiry capped by job and issuer session, one-time claim before technical credential use, final expiry recheck, confirmed idempotent revocation and cancellation integration. Migration 025 is activated locally; live expiry/revocation and least-privilege acceptance remain separate requirements.
- Complete bounded credential-use/job grants for Application Owner instance dispatch and accept expiry/revocation against the live runtime; never export platform credentials to Application Owners.
- Implement server-side tenant, role, owner and RLS isolation, including rechecks on application Plan input.
- Accept two independent customer organizations with different roles, cross-tenant IDs, revocation and stale sessions/queued jobs before widening organization execution.
- Retain GitHub as an optional user-bound connector; support the existing verified STACKIT device-login flow without mandatory GitHub.
- Resolve/document the production OIDC client registration or explicitly approved fallback; registration remains an external prerequisite, not an assumption.
Historical Evidence and Next Step (before current activation)
Migrations 023/024 persist immutable current-human authorization evidence and an atomic explicit organization binding. A new proof attempt clears prior current organization authority while preserving identity and audit history. Read-only, absent/empty/duplicate owner roles, foreign/malformed IAM responses, stale sessions, revoked/expired proofs and Application Owners cannot bind.
The DE/EN UI capability-gates this workflow and never binds automatically or starts Plan/Apply. Evidence: 55 device/API tests, 29 isolated real PostgreSQL identity/catalogue/policy/binding tests, full npm check with 331 passed unit tests (25 gated skips), and all 152 desktop/mobile browser cases passed. IAM/browser HTTP responses are controlled contract fixtures, not live customer acceptance. Official contract reference: stackitcloud/stackit-sdk-go revision 7746310c7fe0a5e3f5c5e6e9b1be69d48c6184d9, services/authorization/v2api.
Running customer API/database/native package unchanged; migrations 021–024 are not activated there. No customer Apply, release or merge. Details: landing-zone-configurator/docs/github-login.md, mvp-readiness.md and runtime-validation-report.md.
Next: integrate the bounded-grant mechanism with approved application-root/instance dispatch, qualify least privilege against actual APIs/providers, activate the reviewed binding path safely, and execute real two-organization/revocation acceptance. Historical organization_verified metadata is not perpetual current owner authority and does not replace job grants.
Current Activation and Acceptance (2026-10-06)
Normal human PKCE login, exact Resource Manager organization/container binding, all 965 official owner permissions, explicit organization-binding confirmation and password-free owner-proof renewal succeeded. Provider bodies remain bounded and permission arrays are capped at 4096; foreign resource/tenant/session gates remain enforced. An already-bound tenant can renew current owner proof without another binding. Group member emails are disclosed only through the existing authorized manager member view in the active tenant. Production OIDC, two-organization isolation/revocation and remaining bounded Application execution acceptance are NOT complete; issue remains open.
Local-only commits: a8447b6 (#91), 53b806b (#92), 798661a (#93). Final validation: 403 unit tests, 30 real isolated identity/PostgreSQL cases, 49 platform broker cases and all 32 desktop/mobile management/publication/proof flows passed. Schema 039 activated after fresh private backup, full restore, repeated migration and unchanged operational-table verification. No push, merge, release or new Application cloud execution.
Dependencies
Enables production tenant publication (#92), instance execution (#93) and tenant-aware chat (#94). Related Accelerator least privilege: #69. Production OIDC registration remains external. All original required criteria remain; this issue stays open.
Platform Grant Checkpoint (2026-10-05)
The platform broker requires a persisted grant before technical credential verification or secret fetch, and rechecks validity before returning the input. Expired/revoked/missing grants never reach those credential-use calls; concurrent requests can claim only once. Old queued jobs receive no implicit grant. A consumed grant cannot truthfully recall already transferred cloud keys: explicit revocation returns 409 and requires separate worker/key/recovery handling. Grants do not reduce cloud IAM permissions.
Final checks: canonical lint/types/build and 331 unit tests passed (33 gated skips); all 31 real isolated PostgreSQL platform broker/grant tests and 29 isolated identity/catalogue/policy/binding tests passed. The eight new broker cases cover expiry/revocation, immutable owner/tenant bindings, HTTP confirmation, cancellation, expiry during verification, missing legacy grants and concurrent claims. No frontend behavior changed; the previous 152-browser-case result was not rerun for this backend-only slice.
Migration 025, customer API and native package were not activated or rebound. No customer Plan/Apply, commit, release or merge. Application execution and least-privilege/two-organization/production-client acceptance remain open; #91 remains open.
Activity
lweberru commentedon Oct 4, 2026
MVP audit 2026-10-04: Updated the description and acceptance checklist against the current implementation. Implemented criteria are checked; remaining requirements are retained. Local tests are not a release or live customer acceptance. This issue stays open until its remaining criteria are met. The first remaining safety fix (#89, backend-free initial plans on existing/partial/legacy state) is now implemented locally: 23/23 isolated PostgreSQL tests and the full check gate (310 unit tests) pass. No customer Apply, API restart, native artifact rebind, commit or merge was performed.
lweberru commentedon Oct 5, 2026
Local implementation checkpoint (2026-10-05): human IAM owner binding, immutable SQL authorization evidence and explicit idempotent confirmation are implemented. Final gates: 331 unit tests, 29 isolated PostgreSQL tests and all 152 desktop/mobile browser cases passed; 55 device/API contract cases included. IAM/browser fixtures are not real two-customer acceptance. Running customer API, database and native artifact were not changed. Original live binding, least-privilege, bounded job-grant, two-organization and production OIDC criteria remain open.
lweberru commentedon Oct 6, 2026
Local feature commit 929f7fd (not pushed): organization proof UI now shows the signed-in Configurator user and verified STACKIT email, handles known access/permissions/identity errors with controlled DE/EN messages, rejects unknown inherited error dictionary keys, and clears stale identity/approval UI across tenant/session changes. No permission relaxation, automatic organization binding, customer migration or API restart. Validation: 61 device/i18n tests, app/test TypeScript, focused Biome and 14 desktop/mobile Playwright proof cases passed; screenshot review and staged repository-root Gitleaks passed. Browser proof cases use synthetic identities and API mocks, not live organization acceptance.
New blocking cold-login evidence: isolated anonymous provider browsers with the explicitly approved CLI device client reach /ui/login/user with only Weiter and hidden form fields, no login inputs; submitting Weiter returns to the same page. Complete verification URI, base URI with manual code entry, and additional profile scope all reproduce the failure. Pre-authenticated STACKIT login remains only an observed workaround. This is a provider-page failure; exact provider/client login-policy cause still requires STACKIT investigation. No speculative link/scope workaround shipped, and a registered production web OIDC client is still required.
The reported real organization proof failure remains unidentified. The refreshed UI now provides safe specific messages and the verified identity for the user to report; it does not establish that the root failure is fixed. #91 remains OPEN with the original acceptance criteria intact.
lweberru commentedon Oct 6, 2026
Correction and local fix: commit ce6db69 (not pushed or activated). The user supplied a local STACKIT CLI checkout. internal/pkg/auth/user_login.go confirms stackit auth login uses Authorization Code with S256 PKCE, not Device Flow. A fresh anonymous CLI-style authorization-code start renders an actual username input, including with the Configurator added state and nonce. The previous classification as a general provider/client-policy blocker was too broad; the grant-flow difference is the demonstrated discriminator.
Implemented local CLI-compatible PKCE with openid/offline_access/email, fresh state/nonce/verifier, fixed loopback callback on a free localhost:8000-8020 port, same-browser/same-session/same-tenant callback gates, one-time code acceptance, required signed ID token and nonce checks, existing issuer/audience/userinfo verification, no refresh-token persistence. Loopback bridge can only return to the fixed Configurator origin and does not log callback URLs/codes or forward provider descriptions. Callback alone neither creates a session nor saves/binds an organization. Existing protected polling and explicit owner binding remain authoritative. Device Flow stays compatible; both web surfaces support PKCE without a device code.
Evidence: 62 auth tests including real loopback HTTP forwarding and cookie/session/tenant/replay/expiry/nonce guards; 395 total unit tests passed, 45 gated skipped; app/test TypeScript and scoped Biome passed; 4 login plus 16 proof desktop/mobile browser cases passed (synthetic API fixtures). Real anonymous provider start shows username input, but no human login or real organization proof completed by the agent. Global npm run check is currently blocked by five format/import diagnostics in paused Applied-Platform work, which was preserved unchanged.
Local API not restarted; customer DB remains on 034, native package and state unchanged. Local activation needs an isolated login-only runtime so neither committed group migration 035 nor pending Applied-Platform migration 036 is activated accidentally. CLI localhost callbacks are local-development-only: hosted production still needs its own registered web OIDC client/callback. Original #91 acceptance criteria retained; issue remains OPEN.
lweberru commentedon Oct 6, 2026
Lokale Login-only-Aktivierung abgeschlossen (kein Push/Merge/Release): isolierter geprüfter Stand mit CLI Authorization Code + S256 PKCE, weiterhin exakt Migrationen 001–034 und unverändertem Plattform-Runner; Application-Ausführung bleibt deaktiviert. Private Datenbanksicherung vollständig in eigenem PostgreSQL-Container wiederhergestellt; alle 33 Kundentabellen nach API-Neustart unverändert. Aktiver anonymer Start über die reale UI erreicht /ui/login/user mit sichtbarem Benutzernamenfeld, ohne Device-Code. Eigener Prüfflow beendet. Vollständiger menschlicher Login und echter Organisationsnachweis sind noch nicht abgenommen, daher bleibt #91 offen. Gruppen-/Applied-Platform-Migrationen 035/036 wurden nicht aktiviert. Anschließend wird die pausierte serverbasierte Applied-Platform-Anbindung lokal fortgesetzt.
lweberru commentedon Oct 6, 2026
Rueckkehr-/Session-Fehler lokal behoben und Login-only aktiviert: Commit 26b2b2b, kein Push/Merge/Release. Nutzer bestaetigte erfolgreichen STACKIT-Login, aber Gastanzeige in der App. Zwei neue Sessions waren bereits gespeichert. Bisher fragte das Rueckkehr-Tab nur einmal vor moeglichem Poll-Abschluss im Ursprungstab nach der Session. Fester geheimnisfreier Callback-Marker startet jetzt geschuetztes Polling auch im Rueckkehr-Tab, selbst nach Schliessen des Ursprungstabs. Bei konkretem flow-missing nach Parallelabschluss wird ausschliesslich die echte serverbestaetigte Session eingelesen; Marker alleine meldet niemanden an. Cookie/State/Nonce/Replay-Gates unveraendert, Callback erzeugt weiterhin keine Session. 62 Auth-Tests, 10 Desktop/Mobil-Loginfaelle (API-Mocks, Return/Race/Missing), Types und scoped Lint bestehen. Voller npm run check am Ende: 395 Unit passed/45 expected gated skips; erster Vollauf einmal kill EPERM in unabhaengigem Runner-Cleanup, gezielter und voller Retry bestanden, kein Runner-Code geaendert. Neue private Sicherung; isolierter Runtime Auth/Types bestanden. Nach API-Neustart exakt Schema 034 und alle 33 Kundentabellen unveraendert, unbound Callback400/App-Runner404, bisheriger Runner unveraendert/App-Ausfuehrung deaktiviert. Migrationen035/036 nicht aktiviert; keine Cloud-Aktion. Nutzer soll App neu laden und Session-Anzeige erneut pruefen; echte Browser-Rueckkehr und Organisations-/IAM-Abnahme noch offen, deshalb bleibt #91 offen.
lweberru commentedon Oct 6, 2026
Nutzer bestaetigt nach Rueckkehrfix26b2b2b: Login funktioniert. Zusaetzliche echte Einladungsabnahme readonly geprueft: eingeladener Benutzer und vorhandener Platform-Engineer-Admin sind zwei getrennte Konten; Einladung accepted_by ist der neue Application Owner, nicht der Admin. Keine falsche Identitaetsverknuepfung und keine Mitgliedschaftsaenderung durch die Diagnose. Organisationsnachweis-Panel zeigt absichtlich den aktuell angemeldeten Benutzer, nicht das eingeladene Mitglied. Einladungsannahme vergibt nur Configurator-Rollen und verifiziert keine STACKIT-Organisationszuordnung/IAM-Rechte. Die aktuelle Organisationszuordnung bleibt unverified, deshalb bleibt #91 fuer die getrennte autoritative IAM-/Bindungsabnahme offen. Keine Migration035/036, kein Cloud-Plan/Apply, kein Push/Merge/Release.
lweberru commentedon Oct 6, 2026
Actual human Owner proof and explicit organization binding accepted in the existing local customer runtime; full 965-right and exact-container checks, safe renewal, schema039 backup/restore and regression evidence are now recorded in the updated body. Local commit a8447b6. Remains OPEN for production OIDC, independent-organization/revocation/least-privilege and remaining bounded Application execution acceptance. No push/release.
lweberru commentedon Oct 6, 2026
Lokale UI-Folgekorrektur 785bc69 (kein Push): Nach geschuetzter Owner-Verifikation kann die aufrufende Application-Ansicht ihre Daten neu laden. Bei einem bereits in einem anderen Tab abgeschlossenen PKCE-Flow wird stackit_flow_missing nur durch einen erneuten echten Serverstatus mit verifizierter Identitaet UND vollstaendigem aktuellem Owner-Nachweis aufgeloest. Identitaet allein oder fehlende/abgelaufene Rechte bleiben gesperrt. Reales passwortfreies SSO und geschuetzte Owner-Erneuerung erfolgreich; 403 Unit-Tests und 36 betroffene Desktop/Mobil-Browserfaelle bestehen. Keine API-/Schema-/Runner-Aenderung oder neue Cloud-Ausfuehrung. #91 bleibt fuer die weiteren urspruenglichen Abnahmen offen.
fix(configurator): expose organization proof identity and safe errors (…
fix(configurator): use CLI-compatible PKCE for local STACKIT login (#91)
docs(auth): record isolated PKCE activation (#91)
fix(auth): resume PKCE login in the callback return tab (#91)
fix(configurator): verify real organization owner evidence (#91)
fix(configurator): reload verified owner proof after PKCE completion (#…
lweberru commentedon Oct 16, 2026
Source integration is in #102. STACKIT login now returns in the current tab while preserving the draft. Login, verified organization binding, tenant membership, optional GitHub access and technical execution grants remain separate authorities. Server-side tenant/owner/revision checks and isolated PostgreSQL/browser tests are part of the automatic Configurator checks.
Keeping this issue open: two independent customer organizations with stale/revoked/queued work, live Application credential expiry/revocation, effective least-privilege provisioning behavior (#69) and production identity/operator acceptance are not certified by these tests. Development login or possession of a service-account key is not production or organization-execution approval.