Je eigen identiteitsprovider koppelen (Okta, Entra ID, Google Workspace)

Koppel de identiteitsprovider van je bedrijf — Okta, Microsoft Entra ID, Google Workspace of een andere OpenID Connect-provider — zodat je team inlogt met de accounts die je IT-afdeling al beheert. Dit is bedoeld voor beheerders met Enterprise-abonnementen.

Overzicht

• Je team logt in met de accounts die ze al op het werk hebben.
• Je houdt de controle op één plek: iemand die bij je provider wordt verwijderd, kan niet meer inloggen bij InfraNest.
• Wil je alleen dat mensen inloggen met een persoonlijk Google-, GitHub- of Microsoft-account (zonder je eigen provider), bekijk dan in plaats daarvan Single sign-on en aanmeldkoppelingen.

Instellen

1. Ga naar Instellingen → Inloggen en kies Single sign-on instellen.
2. Kies bij Provider voor Okta, Microsoft Entra ID, Google Workspace, of Andere provider (OpenID Connect).
3. Vul bij E-maildomein (Optioneel) het domein in waarop de adressen van je team staan. Door dit te verifiëren 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 organisatie, en nieuwe mensen treden toe via een uitnodiging.
4. Kopieer bij Create the app de Redirect URL en gebruik deze om een applicatie voor InfraNest aan te maken bij je provider. Plak de Client ID en Client secret die je provider je geeft terug, plus het ene extra veld dat nodig is:
   • Okta: je Okta-domein, bijvoorbeeld acme.okta.com.
   • Microsoft Entra ID: je tenant-ID, of een willekeurig domein in je tenant.
   • Google Workspace: niets extra's om in te vullen.
   • Andere provider (OpenID Connect): de Discovery URL, meestal eindigend op /.well-known/openid-configuration.
5. Log bij de stap Try it bij je provider in met je eigen account in een nieuw tabblad. Je kunt de koppeling pas inschakelen nadat deze test is geslaagd.
6. Kies bij de stap Who gets in wat er gebeurt wanneer iemand nieuw inlogt, en welke rol die persoon krijgt. Kies daarna Switch on.

NoteInfraNest leest het aanmeldadres, tokenadres en de ondertekeningssleutels rechtstreeks van je provider. Als InfraNest je 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 — gekoppeld, test-aanmelding geslaagd, ingeschakeld, en of een e-maildomein is geverifieerd — samen met de Sign-in link van je organisatie en de bijbehorende Redirect URL.

Zo logt je team in

1. Gebruik de Sign-in link van je organisatie, die bij de koppeling wordt getoond met een kopieerknop (bijvoorbeeld https://app.infranest.io/sso/acme). Mensen kunnen deze bladwijzeren; het werkt met of zonder geverifieerd domein.
2. Of kies op de inlogpagina Use single sign-on onder de knop Sign in, en voer de aanmeldnaam van je organisatie of een werk-e-mailadres in.
3. Of typ rechtstreeks een werk-e-mailadres op de inlogpagina. Als het domein geverifieerd is, verschijnt een knop Continue with ….

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

TipDe aanmeldnaam van je organisatie is de slug, te vinden onder Instellingen → Organisatie. Als je deze wijzigt, verandert de aanmeldlink, waardoor een gebladwijzerde link niet meer werkt.

Als single sign-on verplicht is, verschijnt bij het typen van een werkadres Continue with … als hoofdknop, met het wachtwoordveld weggestopt onder Sign in with a password instead.

Zo treden nieuwe mensen toe

1. Met een geverifieerd e-maildomein kan iemand nieuw toetreden zodra die voor het eerst inlogt, volgens wat je hebt gekozen onder Decide who gets in.
2. Zonder geverifieerd domein nodig je ze zoals gebruikelijk uit via Leden. Hun uitnodigingsmail bevat een knop Continue with … voor je provider — ze loggen in als het uitgenodigde adres en zijn er direct bij. Als ze al een InfraNest-account met dat adres hebben, wordt dat hergebruikt, niet gedupliceerd.
3. Iemand die via je provider inlogt zonder uitnodiging, zonder geverifieerd domein en zonder gekoppeld account, wordt geweigerd en er wordt geen account aangemaakt.
4. Mensen die al een InfraNest-account hebben (bijvoorbeeld aangemaakt met een wachtwoord) kunnen dit koppelen onder My account → Sign-in & security → Connected accounts. Daarna loggen ze in via je provider, domein of niet.

Bepalen wie toegang krijgt

Er zijn twee afzonderlijke instellingen op de koppeling:

• Allowed email domains beperkt welke adressen deze mogen gebruiken. Subdomeinen worden niet automatisch meegenomen — acme.com staat mail.acme.com niet ook toe.
• When somebody new signs in bepaalt wat een geslaagde aanmelding toekent:
  1. Do nothing — ze hebben nog steeds een uitnodiging nodig.
  2. Ask an admin — hun aanmelding creëert een toetredingsverzoek dat een beheerder moet goedkeuren.
  3. Add them straight away — ze krijgen direct een plek, met de rol die je kiest.

De derde optie is alleen beschikbaar voor je eigen identiteitsprovider, niet voor Google- of GitHub-aanmelding — alleen jouw provider weet wie InfraNest daadwerkelijk mag gebruiken. De rol waarop nieuwe leden terechtkomen kan nooit eigenaar zijn, of een rol die dingen kan wijzigen of verwijderen; verhoog individuele personen achteraf.

Toetreden is altijd aanvullend: iemand die al een eigen InfraNest-organisatie beheert, behoudt die gewoon en krijgt er simpelweg een lidmaatschap bij jouw organisatie bij.

Mensen rollen geven op basis van je eigen groepen

Als je provider al scheidt wie wat doet in groepen, kan InfraNest dat gebruiken in plaats van dat jij per persoon een rol instelt.

1. Vul onder Credentials and claim names het veld Groups claim in met het veld waarin je provider groepen verstuurt (Okta stuurt meestal groups; Entra ID stuurt roles voor app-rollen). Laat het leeg en groepen worden helemaal niet gebruikt.
2. Na een test-aanmelding toont InfraNest welk veld je provider daadwerkelijk heeft gebruikt, met een knop om het te gebruiken.
3. Voeg een rij per groep toe: de naam van de groep precies zoals je provider die schrijft, en de rol die daarbij hoort. Eerder geziene groepsnamen worden gesuggereerd terwijl je typt.

Wat je daarna kunt verwachten:

• Rollen volgen je provider — verplaats iemand naar een andere groep en hun rol verandert de volgende keer dat ze inloggen.
• Als je iemands rol hier handmatig wijzigt, blijft dat zo staan — hun groepen bepalen dit vanaf dat moment niet meer.
• Een groep die je niet hebt gekoppeld verandert niets — mensen behouden hun bestaande rol.
• Rollen die dingen kunnen wijzigen of verwijderen kunnen hier ook niet worden gekoppeld; verhoog die mensen handmatig.

Gevoelige acties bevestigen

Je organisatie kan vereisen dat mensen verwijderingen, herbouwingen en poweracties bevestigen door opnieuw te bewijzen wie ze zijn, onder Instellingen → Toegangsbeleid.

• Iemand die via je provider is ingelogd ziet Confirm with je provider; er opent een klein venster en ze loggen opnieuw in.
• InfraNest accepteert dit alleen wanneer je provider daadwerkelijk om een verse aanmelding heeft gevraagd, door het verzonden aanmeldtijdstip te controleren. Elke bevestiging wordt eenmalig gebruikt, voor de actie waarvoor die werd aangevraagd.
• Okta werkt zoals het is.
• Entra ID heeft eerst de auth_time-claim nodig die aan de app wordt toegevoegd.
• Google Workspace kan dit niet — mensen bevestigen in plaats daarvan met een passkey, een authenticator-app of hun wachtwoord.
• Andere providers werken als ze auth_time in het ID-token versturen; anders geeft het venster dit aan.

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

Het client secret vervangen

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

WarningHet opgeslagen geheim wordt nooit opnieuw getoond. Als je het veld leeg laat, blijft het huidige geheim altijd staan.

Claim names

Laat Claim names leeg, tenzij je provider niet-standaard namen gebruikt voor iemands e-mailadres of naam. De standaardwaarden werken al voor Okta, Entra ID en Google Workspace.

Problemen oplossen

• Voer eerst Check (test-aanmelding) uit — dit benoemt de meeste problemen rechtstreeks, zoals een onbereikbare provider of een provider die nu een andere issuer aankondigt dan waarmee de koppeling is ingesteld.
• "Your identity provider rejected this connection's credentials" betekent dat het client secret bij je provider is verlopen of vervangen — vervang het zoals hierboven beschreven.
• " does not use for single sign-on" betekent dat de persoon bij een andere organisatie hoort die haar eigen provider vereist — inloggen via de juiste provider werkt wel.
• Een provider die naar een andere tenant is verhuisd heeft een gloednieuwe koppeling nodig, omdat de issuer vastligt op het moment dat een koppeling wordt aangemaakt en bij elke aanmelding wordt gecontroleerd.
• Beheerders kunnen elke mislukte poging, met de reden, bekijken in Instellingen → Auditlog.