Repository navigation
Configurator MVP: verify organisation tenants and STACKIT user bindings #91
Description
Current acceptance scope decision (2026-10-23)
At the user's explicit decision, a second real STACKIT organization is removed from the current Dev/MVP acceptance scope because another organization is not available. Cross-organization live acceptance is deferred to a future expressly authorized customer validation; it is not recorded as passed and does not block completion of the current scope. Existing tenant/organization authorization and isolation guards remain required and unchanged.
Current live acceptance uses the available organization with separate Platform Owner and Application Owner accounts. Role/owner boundaries, stale sessions, queued jobs and grant expiry/revocation remain in scope within that organization. Automated cross-tenant isolation tests remain required. This scope decision does not authorize production or customer infrastructure operations.
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. Live acceptance with a second organization is deferred by the 2026-10-23 scope decision above; production-client acceptance remains 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 separate Platform Owner/Application Owner roles, owner boundaries, revocation and stale sessions/queued jobs in the available organization; retain automated cross-tenant ID isolation tests. Live acceptance in a second organization is deferred to future customer validation and is outside the current scope.
- 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. The current criteria above apply, including the explicit 2026-10-23 second-organization deferral; this issue stays open for the remaining requirements.
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.
lweberru commentedon Oct 23, 2026
Customer-selectable Application project IAM — agreed design direction (2026-10-23)
The user accepts granular Application-team permissions as the recommended default, with an explicit customer-selectable full project
owneroption retained. Do not silently remove existing owner grants, force a Portal-free workflow, or treat the Configurator Application Owner role as automatic cloud-project ownership.Implementation must define versioned permission profiles and the approval/publication boundary: Platform Owners choose which profile a template grants; orders record the immutable choice, and applicants cannot escalate through request inputs. Separate initial project-creation ownership required by API/provider behavior (#69), long-lived Application-team permissions, and privileged execution identity. An owner profile must explain the additional ability to change IAM/networking/audit configuration where those permissions apply; full owner cannot simultaneously be advertised as enforcing centrally immutable project controls (#99). STACKIT's additive/inherited grants must be considered.
When implemented, keep standalone native configuration, Configurator contracts/compiler/UI, migration compatibility and Assistant facts/proposals aligned. Qualify the Assistant against both choices and reject claims that the recommended restricted profile is mandatory or that an additional restricted binding cancels inherited owner access. Concrete permissions require API/provider verification before advertising supported profiles. No permission changes are performed by this design decision.
Future workload Building Blocks above existing Application Landing Zones are recorded separately in #137 and are explicitly outside the current scope. Their absence is one reason to preserve customer flexibility and direct Portal access today.
lweberru commentedon Oct 23, 2026
Implementation boundary identified for customer-selectable project permissions
The current native
stackit_resourcemanager_project.this.owner_emailcomes directly from the resolved Applicationowner_email. Configurator order resolution binds that value to the verified requester. Consequently, adding product-specific/custom role assignments alone would not create a restricted Application-team profile: the requester would still hold the initial project owner grant.The agreed design therefore needs three separate identities/contracts before advertising granular defaults:
Permission names and required read/dependency rights need verification against the supported product APIs. Standard
editoris broad service administration and is not automatically a safe restricted workload profile. STACKIT grants are additive and inherited; a restricted project binding cannot cancel inherited owner access. IAM role/assignment mutation permits escalation, and full owner cannot be described as enforcing immutable central routing/audit controls. These boundaries follow the official roles/custom-role documentation:Implementation must cover native Application inputs, reviewed source pins, platform/template/order contracts, SQL enforcement, UI, preservation/migration tests and source-bound Assistant qualification for both granular and owner choices. Existing initial-owner behavior has not been changed by this investigation. #69 remains the separate owner-less-project request; using a centrally designated initial owner would not fulfill that issue. Future Portal-free workload bundles remain out of scope in #137.
lweberru commentedon Oct 26, 2026
PR #161 is merged. New Public/Corporate template versions can define immutable cloud project access profiles independently of the verified requester, STACKIT IDP and Configurator workspace roles. Granular team/automation workload roles are the new-draft default; customers may explicitly select full Owner. Existing published versions, orders, State and cloud grants are not migrated.
Native source is pinned to 08ac257. CI is fully green; local evidence includes 1,253 unit tests (76 gated skips), 70 database integration tests, 63 platform database tests, 350 desktop/mobile browsers and 20/20 affected real-model cases across two repetitions, plus native/compiler/recovery/adapter contracts. Qualified Dev release is running: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/40299502159 . This is not yet a deployment acceptance claim.
Keep this issue open: actual effective cloud IAM allow/deny checks for representative restricted user and automation identities are still pending. Reviewed permission names and admission/compilation tests do not prove actual provider authorization. Inherited rights remain additive; owner-less provisioning (#69), production OIDC, and outstanding expiry/revocation acceptance are separate work. No customer infrastructure Plan/Apply was run for this implementation.
lweberru commentedon Oct 26, 2026
Qualified Dev deployment of #161 completed successfully: source1e92cb80e3ddf0a51427b5a753d082d0e3438aa9, https://github.com/stackitcloud/stackit-landing-zone/actions/runs/40299502159 . Complete real-model qualification passed134/134 across two repetitions plus13/13 continuous journey steps; build, publication, deployment and isolated Runner probes all succeeded.
Independent read-only runtime verification confirms the actual App source/droplet, migration073 admission trigger enabled, cloud-access-profile UI, Assistant enabled, exact matching live Ready pool of1, protected routes and removal of the temporary diagnostic app. Existing recovery receipts and successful follow-up Apply remain present; the prior State inspection confirmed serial7/12resources with original/adopted identities preserved and no lock. No State/lock or customer infrastructure mutation was performed.
The independent quota change #162 has a separate Dev release in progress with the requested live-Assistant skip. This does not supersede the outstanding real cloud IAM acceptance: allowed workload actions and denied IAM/project deletion/central routing for separate restricted human and automation identities must still be verified. Existing inherited grants are additive; existing orders/rights are not silently upgraded. #91 remains open for its remaining acceptance.
lweberru commentedon Oct 26, 2026
Dev acceptance update: PR #163 is merged and deployed with PR #162 in release 40312586216, source
ba3adeb89079f1fdde441340b86cc5d680c487d5.This UI/quota release explicitly used
dev-skip-assistant-qualification; the Assistant remains enabled. The earlier source-bound full live qualification (134/134 cases and 13/13 journey steps) belongs to release 40299502159 and is not represented as a new qualification of this source.Keep this issue open: effective cloud IAM acceptance (including inherited permissions), the remaining binding/revocation checks and production identity integration are not established by a UI chooser or read-only deployment audit. No customer infrastructure Plan/Apply or State/lock mutation was performed for this release.
lweberru commentedon Oct 26, 2026
Dev validation completed for PRs #164, #165 and #166 at source ba0fc27.
Release: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/40334302222 (successful; dev-skip-assistant-qualification, Assistant active, runner_pool_size=1).
The Platform Owner flow now follows template drafts → platform binding → publication → catalogue. Configuration editing is accessible explicitly. Permissions use the requester and Application Service Account terminology with grouped, searchable permission controls. Platform credential context is matched using the persisted configuration row ID rather than the document-local ID; stored resource identities remain unchanged.
Validation: 1,258 app checks passed, 76 existing gated skips, and 372 browser tests passed. Independent runtime verification confirmed the actual deployed source, protected metadata routes, access-profile and order-quota database guards, and one matching live warm runner. Temporary privileged diagnostic apps were removed.
Existing guided recovery receipts and the successful follow-up Apply remain intact. Read-only backend verification confirmed serial 7, 12 managed resources, preserved identities and a free lock. No customer infrastructure Plan/Apply or remote State/lock changes were performed. The earlier combined release 40329649547 was deliberately cancelled before App rollout when the configuration-ID mismatch was discovered.
This records the delivered UI and metadata-context improvements, not full closure of all remaining acceptance criteria. Effective cloud IAM/inherited rights and broader quota/concurrency and lifecycle acceptance remain separate. No new live Assistant qualification is claimed for this UI release.