Users & Companies

Multi-tenancy in FixControl

FixControl is multi-tenant. Eén tenant (intern ook wel "organization" of "company" genoemd) bezit zijn eigen issues, agents, kennis, memory, audit-log en inbox. Een gebruiker hoort altijd bij precies één tenant. Tenants kunnen elkaars data niet zien. Een admin in tenant A kan geen issues van tenant B opvragen, ook niet via een directe API-call: tenant-isolatie wordt op elk endpoint afgedwongen, met extra database-niveau guards in strict mode (zie Security & audit).

De enige uitzondering is de aparte platformAdmin-vlag (zie hieronder). Die staat los van de gewone rol en wordt nooit gezet door self-serve signup.

Een nieuwe tenant aanmaken

Er zijn twee manieren om een tenant te starten:

1. Self-serve signup via /signup. Maakt een nieuwe tenant aan, seedt het canonieke AI-team, maakt de eerste gebruiker als admin binnen die tenant, en logt 'm direct in. De gebruiker landt op /app.
2. Companies-pagina (alleen platformAdmin) — maak een tenant aan namens een klant.

Bij signup wordt de bedrijfsnaam ge-disambiguated — twee onafhankelijke signups voor "Acme" worden "Acme" en "Acme (2)", nooit per ongeluk samengevoegd.

Rollen

Hiërarchisch (admin > manager > operator):

Daarnaast bestaat de losse vlag platformAdmin. Deze geeft cross-tenant leesrechten (Companies-view, audit-aggregaties) en wordt alleen toegekend door FixControl-staff. Self-serve signup zet hem nooit.

Projectgebonden autorisatie

Boven op de tenant-rollen hierboven kan toegang tot projectgebonden data per project worden gescopet. Het model: een gebruiker handelt binnen een project alleen via een actief projectlidmaatschap met een projectrol.

Projectrollen

Twee systeemrollen worden per tenant geseed en zijn niet te bewerken:

• Project Admin — volledig beheer van één project: leden, rollen, instellingen en de projectgebonden resources.
• Project Member — lezen en meedoen: projectdata lezen, communicatie opstellen en aanvragen, workflows uitvoeren, gebonden connectors gebruiken.

Je kunt ook eigen rollen aanmaken, tenant-breed (herbruikbaar over projecten) of gescopet op één project. Permissies kies je uit een vaste catalogus van capability-strings (project-, klant-, communicatie-, workflow-, connector-, audit- en policy-permissies) — er zijn geen vrije-vorm-permissies.

Lidmaatschaps-lifecycle

Elk lidmaatschap heeft een status (active, suspended, revoked) en een optioneel geldigheidsvenster (geldig van / tot) voor tijdelijke toegang. Alles wat niet actief én binnen het venster is, geeft niets — een ingetrokken of verlopen lidmaatschap bijt direct.

Deny by default, gefaseerde uitrol

Handhaving zit achter de tenant-overridebare vlag PROJECT_AUTHORIZATION_ENABLED (standaard uit = compatibiliteitsmodus: bestaande tenant-toegang blijft werken, en gebruik van het legacy-pad wordt gelogd). Met de vlag aan is projectgebonden data deny by default: een operator zonder actief lidmaatschap ziet het project niet — een geraden project-id geeft een kale 404.

Twee dingen om te weten als admin:

• Tenant-admins en -managers houden hun tenant-brede reikwijdte. Eén centrale bypass-regel laat ze door; elke bypass op een actiepad wordt geauditeerd. Operators bypassen nooit — hun toegang loopt uitsluitend via een actief lidmaatschap. Een handvol gevoelige acties (bijvoorbeeld het goedkeuren van externe klantcommunicatie) vereist ook van een admin een echt lidmaatschap.
• Laatste-admin-bescherming. Een rolwijziging, schorsing of intrekking die een project zou achterlaten zonder actieve leden met ledenbeheer-rechten wordt geweigerd — een project kan zichzelf nooit buitensluiten van zijn eigen beheer.

Leden en rollen beheren

Leden- en rollenbeheer zit op de projectpagina (teamtoegang), niet onder tenant-instellingen — en is zelf afgeschermd met projectpermissies: bekijken vereist project.members.read, wijzigen project.members.manage (via de bypass voor tenant-admins/-managers, of via leden met de Project Admin-rol). Managers kunnen hun eigen lidmaatschap niet aanpassen. Een lid uit een andere tenant toevoegen wordt hard geweigerd.

Inlogmethoden

Beide kunnen tijdens een migratie tegelijk draaien. Configureer onder Settings → Identity.

OIDC SSO

Configureer je IdP in de admin-tenant-instellingen:

1. Ga naar Settings → Identity → OIDC.
2. Voeg een provider toe met issuer, clientId, clientSecret, redirectUri.
3. Zet allowed email domains (de allowlist).
4. Kies JIT provisioning als je wilt dat nieuwe gebruikers bij eerste login worden aangemaakt, met een standaardrol.
5. Map claims: email, name, optioneel groups.

Wat op de callback wordt afgedwongen:

• Issuer-match, audience-match, nonce-match, exp in de toekomst, gesigneerd met het algoritme dat door de JWK gepind is.
• State + PKCE one-shot — replay-pogingen geven 401.
• Domain-allowlist-check op de email-claim.

Matcht de email met een bestaande gebruiker, dan wordt de OIDC-login aan die gebruiker gekoppeld. Staat JIT aan en is het domein toegestaan, dan wordt een nieuwe gebruiker geprovisioneerd met de geconfigureerde standaardrol. Anders wordt de login geweigerd.

Vandaag linkt OIDC op email. SAML-stijl external-id-only linking is niet ondersteund.

SCIM 2.0 provisioning

Kan je IdP gebruikers pushen (Okta, Azure AD, Google Workspace, anderen), koppel dan via SCIM:

1. Ga naar Settings → Identity → SCIM tokens (of Admin → SCIM tokens voor platform admins).
2. Genereer een tenant-scoped bearer token. Eenmalig getoond.
3. Configureer in je IdP de SCIM-connector met:

- Endpoint: https://<your-deployment>/api/scim/v2 - Auth: Authorization: Bearer scim_…

1. Selecteer welke Users en Groups gepusht worden.

Geïmplementeerde endpoints:

• Users GET (paginated, userName eq filter), POST, GET/PATCH/DELETE per id.
• Groups GET (paginated), POST, GET/PATCH/DELETE per id.
• ServiceProviderConfig, Schemas, ResourceTypes discovery.

Group → role mapping is vandaag handmatig. SCIM maakt en update gebruikers; jij beslist in de UI hoe groups op FixControl-rollen mappen. (Auto-mapping staat op de roadmap.)

Deprovisioning

Wanneer je IdP een user-removal pusht (DELETE /scim/v2/Users/{id} of active=false PATCH):

• De gebruiker wordt soft-deleted.
• Alle sessies worden ingetrokken.
• Het deprovision-event wordt geaudit.

Handmatig deactiveren werkt hetzelfde — onder Settings → Users, klik Deactivate. Gebruikers zijn her-activeerbaar zolang de soft-delete-record nog bestaat.

Gebruikers uitnodigen (zonder SCIM)

Een tenant-admin gaat naar Settings → Users (/settings/users) en klikt op Create user. Verplichte velden zijn naam, e-mail, initieel wachtwoord (min. 8 tekens) en rol. De nieuwe gebruiker krijgt automatisch jouw tenant toegewezen — er is geen UI-weg om iemand in een andere tenant te plaatsen. Bestaande gebruikers kunnen vanuit dezelfde pagina worden bewerkt, gedeactiveerd, gereset of verwijderd. De Last seen-kolom toont de laatste succesvolle login uit het audit-log.

Admin-lijstpagina's — DataTable

/settings/users, /settings/audit, de platform-admin Companies-lijst en de overige admin-tabellen draaien allemaal op de canonieke operator-DataTable. Dat betekent:

• Server-side sort + filter + paginering — grote directories pagineren sauber; URL legt de slice vast, dus je kunt een link naar "alle admins van de afgelopen 7 dagen" delen en een collega ziet hetzelfde resultaat.
• Keymap — j/k voor rij-stappen, / voor search, Enter om in te duiken, [ / ] op een detailpagina lopen prev/next binnen hetzelfde filter. Zie Toetsenbord & command palette.
• Bulk select — x, Shift+x, Cmd/Ctrl+A. Bulk Deactivate en bulk Reset password verschijnen in de sticky bulk-toolbar; destructieve acties bevestigen met de impact-lijst inline.
• Saved views — admins slaan vaak Active, Inactive, Admins, Operators zonder recente login op, zodat de volgende admin meteen dezelfde lens oppakt.
• Audit-context — /settings/audit profiteert het meest: filter op actor + verb + tijdsbereik, Save view, link delen.

De admin-tabellen delen hun keymap en command-palette commando's met de operator-pagina's — er is één set spiergeheugen door het hele product heen.

De Companies-view

/companies is een platform-admin overzicht. Per tenant zie je: aantal issues, agents, members, plan, contact-mailbox en brand-kleur. Vanuit deze pagina kun je tenants aanmaken, bewerken, verwijderen of switchen. Alleen platform admins zien hier alle tenants — een gewone tenant-admin ziet alleen zijn eigen workspace.

Beveiligingsnotitie — een tenant verwijderen via deze view dropt ook agents en (cascade) alle issues, knowledge en memory van die tenant. Dat is onomkeerbaar. De actie wordt afgevangen door de twee-personen-regel.

FAQ

Kan een gebruiker in twee tenants tegelijk? Nee. Een gebruiker leeft in één tenant. Maak een tweede account aan met een ander e-mailadres als dat nodig is.

Wat gebeurt er met issues als ik een gebruiker verwijder? Issues blijven bestaan; alleen het user-record wordt verwijderd. Toewijzingen aan die gebruiker worden los referenties.

Hoe maak ik iemand platformAdmin? Niet via self-service — neem contact op met FixControl-support. Dit is met opzet niet in de UI beschikbaar.

Wat als mijn IdP een SCIM PATCH pusht die een gebruiker uit een andere tenant aan mijn group toevoegt? Wordt server-side geweigerd. Cross-tenant group-membership is op de SCIM-laag geblokkeerd.

Kan ik OIDC SSO en wachtwoord-login tegelijk actief hebben? Ja, tijdens een migratie. Schakel wachtwoorden uit zodra SSO volledig uitgerold is.