Je eigen identity provider koppelen (Okta, Entra ID, Google Workspace)

Koppel de identity provider van je bedrijf zodat je team inlogt bij InfraNest met de accounts die je al beheert in Okta, Microsoft Entra ID, Google Workspace of een andere OpenID Connect-provider. Dit is bedoeld voor beheerders met een Enterprise-abonnement die toegang centraal willen regelen — iemand die bij je provider wordt verwijderd, verliest ook hier de toegang.

#Overzicht

• Je team logt in met accounts die je al beheert, in plaats van een apart InfraNest-wachtwoord.
• Iemand die bij je provider wordt verwijderd, kan niet meer inloggen bij InfraNest.
• Beschikbaar op Enterprise-abonnementen. Voor inloggen met Google, GitHub of Microsoft zonder je eigen provider, zie in plaats daarvan Single sign-on en aanmeldkoppelingen.

#Instellen

1. Ga naar Instellingen, dan Inloggen, en kies Single sign-on instellen.
2. Provider: kies Okta, Microsoft Entra ID, Google Workspace, of Andere provider (OpenID Connect).
3. E-maildomein (aanbevolen): voer het domein in waarop de adressen van je mensen staan. Zodra dit geverifieerd is, kunnen mensen hun werkadres intypen op de inlogpagina en kunnen nieuwe mensen automatisch toetreden. Je kunt dit overslaan — je team gebruikt dan de aanmeldlink van je workspace, en nieuwe mensen treden toe via een uitnodiging.
4. De app aanmaken: kopieer de Redirect URL, en maak vervolgens bij je provider een applicatie voor InfraNest aan met deze als redirect-URL. Je provider geeft je een Client ID en Client secret om terug te plakken, plus één extra veld afhankelijk van je provider:
   • Okta: je Okta-domein, bijvoorbeeld acme.okta.com.
   • Microsoft Entra ID: je tenant-ID, of elk domein dat bij je tenant hoort.
   • Google Workspace: niets extra's om in te vullen.
   • Andere provider (OpenID Connect): de Discovery URL die deze publiceert, meestal eindigend op /.well-known/openid-configuration.
5. Testen: log in bij je provider met je eigen account, in een nieuw tabblad. Een koppeling kan pas worden aangezet nadat deze test is geslaagd.
6. Wie mag erin: kies wat er gebeurt wanneer iemand nieuw inlogt, en welke rol diegene krijgt. Kies daarna Inschakelen.

InfraNest leest al het andere — het aanmeldadres, het tokenadres en de ondertekeningssleutels van je provider — rechtstreeks van de provider zelf. Als InfraNest de provider niet kan bereiken, wordt de koppeling niet opgeslagen en legt de foutmelding uit wat er is geprobeerd.

Daarna toont elke koppeling waar deze staat: verbonden met je provider, testaanmelding geslaagd, ingeschakeld, en of een e-maildomein is geverifieerd. Ook toont het de Sign-in link van je workspace en blijft het de Redirect URL tonen, voor het geval je een van beide nog eens nodig hebt.

NoteDeze instelflow is beschikbaar op Enterprise-abonnementen.

#Hoe je team inlogt

1. Gebruik de aanmeldlink van je workspace, getoond bij de koppeling met een kopieerknop. Deze ziet er zo uit: https://app.infranest.io/sso/acme, waarbij acme de aanmeldnaam van je workspace is. Mensen kunnen deze als bladwijzer bewaren, en hij werkt ongeacht of je een domein hebt geverifieerd.
2. Of kies Use single sign-on, de link onder de knop Sign in op de inlogpagina. Deze vraagt om de aanmeldnaam van je workspace, of een werk-e-mailadres.
3. Of typ eenvoudigweg een werk-e-mailadres op de inlogpagina. Als het domein daarvan geverifieerd is, verschijnt een knop Continue with ….

Je kunt de aanmeldlink ook plaatsen in het dashboard van je provider, zodat mensen daar kunnen starten vanaf de InfraNest-tegel.

TipDe aanmeldnaam van je workspace is de slug, te vinden onder Settings → General. Als je deze wijzigt, verandert de aanmeldlink, waardoor een link die iemand als bladwijzer heeft bewaard niet meer werkt.

Als single sign-on verplicht is, toont het intypen van een werkadres op je domein Continue with … als hoofdknop, met het wachtwoordveld weggeklapt onder Sign in with a password instead.

#Hoe nieuwe mensen toetreden

1. Met een geverifieerd e-maildomein kan iemand nieuw toetreden op het moment dat hij of zij voor het eerst inlogt, afhankelijk van wat je hieronder koos bij "Bepaal wie erin mag".
2. Zonder geverifieerd domein treden mensen in plaats daarvan toe via een uitnodiging. Nodig ze zoals gebruikelijk uit vanuit Team.
3. De uitnodigingsmail opent een pagina met Continue with … je provider: ze loggen daar in als het uitgenodigde adres, en zijn binnen. Als ze al een InfraNest-account met dat adres hebben, wordt dat gebruikt, niet gedupliceerd.

Iemand die via je provider inlogt zonder uitnodiging, zonder geverifieerd domein en zonder gekoppeld account, wordt geweigerd, en er wordt geen account voor diegene aangemaakt.

Mensen die al een account hebben, bijvoorbeeld omdat ze zijn toegetreden met een wachtwoord, kunnen dit koppelen aan je provider onder My account → Sign-in & security → Connected accounts. Daarna loggen ze in via je provider, domein of niet.

InfraNest herkent een bestaand account ook zelf, als het adres op je geverifieerde domein staat en je provider aangeeft dat het adres geverifieerd is. Providers melden dit niet altijd: bij Okta heeft iemand die door een beheerder is aangemaakt met een wachtwoord een ongeverifieerd adres totdat deze persoon het zelf bevestigt. De testaanmelding laat zien wanneer je provider het adres niet heeft bevestigd. Die mensen koppelen dan in plaats daarvan vanuit hun profiel, of bevestigen hun adres bij je provider.

#Bepaal wie erin mag

Twee aparte instellingen horen bij de koppeling:

• Toegestane e-maildomeinen beperkt welke adressen deze mogen gebruiken. Subdomeinen zijn niet inbegrepen — acme.com staat mail.acme.com niet toe.
• Wanneer iemand nieuw inlogt bepaalt wat een geslaagde aanmelding oplevert:
  • Niets doen — ze hebben nog steeds een uitnodiging nodig.
  • Een beheerder vragen — hun aanmelding maakt een toetredingsverzoek aan dat een beheerder moet goedkeuren.
  • Meteen toevoegen — ze krijgen direct een plek, met de rol die je kiest.

De derde optie bestaat alleen voor je eigen identity provider, niet voor inloggen met Google of GitHub, omdat alleen je provider weet wie InfraNest mag gebruiken: iemand die je IT-afdeling niet aan de app in Okta of Entra ID heeft toegewezen, komt het inlogscherm helemaal niet voorbij. Google daarentegen authenticeert gewoon elk adres op je domein — inclusief freelancers, gedeelde mailboxen en mensen die vertrokken zijn maar wiens account nog bestaat.

De rol die nieuwe leden krijgen, kan nooit eigenaar zijn, of een rol die dingen kan wijzigen of verwijderen — verhoog individuele mensen achteraf.

Toetreden is altijd aanvullend. Iemand die al een eigen InfraNest-workspace had, houdt die en krijgt daarnaast lidmaatschap in de jouwe.

#Rollen toekennen op basis van je eigen groepen

Als je provider al onderscheid maakt wie wat doet — bijvoorbeeld een groep infra-admins en een groep infra-readonly — kan InfraNest dat gebruiken in plaats van dat jij hier per persoon een rol instelt.

Onder Credentials and claim names:

1. Vul Groups claim in met het veld waarin je provider groepen meestuurt. Okta stuurt meestal groups; Entra ID stuurt roles voor app-rollen. Laat het leeg en groepen worden helemaal niet gebruikt. Na een testaanmelding toont InfraNest welk veld je provider daadwerkelijk heeft gebruikt, met een knop om dat te gebruiken.
2. Voeg per groep een rij toe: de naam van de groep precies zoals je provider die schrijft, en de rol die daarbij hier hoort. Groepsnamen die je provider bij eerdere aanmeldingen heeft gestuurd, worden voorgesteld terwijl je typt.

Wat je daarna kunt verwachten:

• Rollen volgen je provider. Verplaats iemand naar een andere groep en hun rol hier verandert bij de volgende aanmelding.
• Je eigen wijzigingen blijven staan. Wijzig iemands rol hier handmatig, en deze blijft zoals je hem hebt ingesteld — hun groepen bepalen die daarna niet meer.
• Een groep die je niet hebt gekoppeld, verandert niets. Iemand wiens groepen bij geen enkele rij passen, houdt de rol die hij of zij heeft, zodat een verkeerd getypte claimnaam niet je hele team kan degraderen.
• Rollen die dingen kunnen wijzigen of verwijderen kunnen niet worden gekoppeld, net als de standaardrol. Verhoog individuele mensen zelf.

#Gevoelige acties bevestigen

Je workspace kan mensen vragen verwijderingen, herbouwacties en krachtige acties te bevestigen door opnieuw te bewijzen wie ze zijn (Settings → Access policy). Iemand die inlogt via je identity provider kan dat daar doen: de bevestiging toont Confirm with je provider, er opent een klein venster, en diegene logt opnieuw in.

InfraNest accepteert dit alleen wanneer je provider de persoon echt opnieuw om aanmelding heeft gevraagd, niet wanneer deze werd doorgelaten op een sessie die al bestond. Het controleert het aanmeldtijdstip dat je provider meestuurt, en een bevestiging wordt eenmalig gebruikt, voor de actie waarvoor erom werd gevraagd.

• Okta werkt zoals het is.
• Entra ID heeft de auth_time-claim nodig die aan de app wordt toegevoegd, wat een minuutje kost.
• Google Workspace kan dit niet, omdat Google geen manier biedt om iemand opnieuw te laten inloggen. Mensen bevestigen dan in plaats daarvan met een passkey, een authenticator-app of hun wachtwoord.
• Andere providers werken wanneer ze auth_time in het ID-token meesturen. Doet de jouwe dat niet, dan meldt het venster dat.

Als een browser het venster blokkeert, sta pop-ups voor InfraNest toe en probeer het opnieuw.

#De client secret vernieuwen

1. Ga naar Credentials and claim names bij de koppeling.
2. Voer het nieuwe geheim in.
3. Kies Replace.

WarningHet opgeslagen geheim wordt nooit opnieuw getoond, dus als je het veld leeg laat, blijft altijd het huidige geheim gebruikt — controleer dubbel of je het nieuwe geheim correct hebt geplakt voordat je het vervangt.

#Problemen oplossen

• Test de koppeling eerst — in de meeste gevallen benoemt dit het probleem, zoals een onbereikbare provider, of een provider die nu een andere issuer aankondigt dan die waarmee deze koppeling is ingesteld.
• "Your identity provider rejected this connection's credentials" betekent dat de client secret is verlopen of bij je provider is vernieuwd. Vervang het zoals hierboven beschreven.
• " does not use for single sign-on" betekent dat de persoon bij een andere workspace hoort die zijn eigen provider vereist. Inloggen via de juiste werkt wel.
• Een provider die naar een andere tenant is verhuisd heeft een nieuwe koppeling nodig: de issuer ligt vast op het moment dat de koppeling wordt aangemaakt, en elke aanmelding wordt daartegen gecontroleerd. Dat is bewust zo — het voorkomt dat een provider stilletjes voor een andere wordt verwisseld.
• Je beheerders kunnen elke mislukte poging, met de reden, bekijken in Settings → Audit Log.

#Claimnamen

Laat Claim names leeg tenzij je provider niet-standaard namen gebruikt voor het e-mailadres of de naam van een persoon. De standaardwaarden zijn correct voor Okta, Entra ID en Google Workspace.