Eigenen Identitätsanbieter verbinden (Okta, Entra ID, Google Workspace)

Verbinde den Identitätsanbieter deines Unternehmens, damit sich dein Team mit den Konten, die du bereits in Okta, Microsoft Entra ID, Google Workspace oder einem anderen OpenID-Connect-Anbieter verwaltest, bei InfraNest anmeldet. Das richtet sich an Admins im Enterprise-Tarif, die den Zugriff zentral steuern möchten — jemand, der bei deinem Anbieter entfernt wird, verliert auch hier den Zugriff.

#Übersicht

• Dein Team meldet sich mit Konten an, die du bereits verwaltest, statt mit einem separaten InfraNest-Passwort.
• Jemand, der bei deinem Anbieter entfernt wird, kann sich nicht mehr bei InfraNest anmelden.
• Verfügbar in Enterprise-Tarifen. Für die Anmeldung mit Google, GitHub oder Microsoft ohne eigenen Anbieter siehe stattdessen Single Sign-on und Anmeldeverbindungen.

#Einrichtung

1. Gehe zu Einstellungen, dann Anmeldung, und wähle Set up single sign-on.
2. Provider: wähle Okta, Microsoft Entra ID, Google Workspace oder Another provider (OpenID Connect).
3. E-Mail-Domain (empfohlen): Gib die Domain ein, auf der die Adressen deiner Mitarbeitenden liegen. Nach der Verifizierung können Personen auf der Anmeldeseite ihre dienstliche Adresse eingeben, und neue Personen können automatisch beitreten. Du kannst diesen Schritt überspringen — dein Team nutzt dann den Sign-in link deines Workspace, und neue Personen treten per Einladung bei.
4. App erstellen: Kopiere die Redirect URL, und erstelle dann bei deinem Anbieter eine Anwendung für InfraNest mit dieser URL als Redirect-URL. Dein Anbieter gibt dir eine Client ID und ein Client secret, die du zurück einfügst, sowie ein zusätzliches Feld je nach Anbieter:
   • Okta: deine Okta-Domain, zum Beispiel acme.okta.com.
   • Microsoft Entra ID: deine Tenant-ID oder eine beliebige Domain, die zu deinem Tenant gehört.
   • Google Workspace: keine zusätzliche Eingabe nötig.
   • Another provider (OpenID Connect): die Discovery URL, die er veröffentlicht, meist endend auf /.well-known/openid-configuration.
5. Testen: Melde dich in einem neuen Tab mit deinem eigenen Konto bei deinem Anbieter an. Eine Verbindung kann erst eingeschaltet werden, wenn dieser Test erfolgreich war.
6. Wer hineinkommt: Lege fest, was passiert, wenn sich jemand Neues anmeldet, und welche Rolle diese Person erhält. Wähle dann Switch on.

InfraNest liest alles andere — die Anmeldeadresse, die Token-Adresse und die Signaturschlüssel deines Anbieters — direkt vom Anbieter aus. Kann er den Anbieter nicht erreichen, wird die Verbindung nicht gespeichert, und der Fehler erklärt, was versucht wurde.

Danach zeigt jede Verbindung ihren Status an: verbunden mit deinem Anbieter, Test-Anmeldung bestanden, eingeschaltet, und ob eine E-Mail-Domain verifiziert ist. Außerdem werden der Sign-in link deines Workspace und seine Redirect URL weiterhin angezeigt, falls du einen der beiden erneut benötigst.

NoteDieser Einrichtungsablauf ist in Enterprise-Tarifen verfügbar.

#Wie sich dein Team anmeldet

1. Verwende den Sign-in link deines Workspace, der bei der Verbindung mit einer Kopierschaltfläche angezeigt wird. Er sieht aus wie https://app.infranest.io/sso/acme, wobei acme der Anmeldename deines Workspace ist. Personen können ihn als Lesezeichen speichern, und er funktioniert unabhängig davon, ob du eine Domain verifiziert hast.
2. Oder wähle Use single sign-on, den Link unter der Schaltfläche Sign in auf der Anmeldeseite. Dort wird nach dem Anmeldenamen deines Workspace oder einer dienstlichen E-Mail-Adresse gefragt.
3. Oder gib einfach eine dienstliche E-Mail-Adresse auf der Anmeldeseite ein. Ist deren Domain verifiziert, erscheint eine Schaltfläche Continue with ….

Du kannst den Sign-in link auch im Dashboard deines Anbieters hinterlegen, sodass Personen von der InfraNest-Kachel dort aus starten können.

TipDer Anmeldename deines Workspace ist sein Slug, zu finden unter Einstellungen → Allgemein. Wenn du ihn änderst, ändert sich auch der Sign-in link, sodass ein zuvor gespeichertes Lesezeichen nicht mehr funktioniert.

Wenn Single Sign-on verpflichtend ist, erscheint bei Eingabe einer dienstlichen Adresse auf deiner Domain Continue with … als Hauptschaltfläche, während das Passwortfeld unter Sign in with a password instead eingeklappt ist.

#Wie neue Personen beitreten

1. Mit verifizierter E-Mail-Domain kann jemand Neues sofort bei der ersten Anmeldung beitreten, abhängig von der Auswahl unter „Wer hineinkommt entscheiden“ weiter unten.
2. Ohne verifizierte Domain treten Personen stattdessen per Einladung bei. Lade sie wie gewohnt über Team ein.
3. Die Einladungs-E-Mail öffnet eine Seite mit Continue with … deinem Anbieter: Dort meldet sich die Person als die eingeladene Adresse an, und sie ist dabei. Besteht bereits ein InfraNest-Konto mit dieser Adresse, wird dieses verwendet und nicht dupliziert.

Jemand, der sich über deinen Anbieter anmeldet, ohne Einladung, ohne verifizierte Domain und ohne damit verknüpftes Konto, wird abgewiesen, und es wird kein Konto für diese Person erstellt.

Personen, die bereits ein Konto haben — etwa weil sie sich mit einem Passwort angemeldet haben — können es unter My account → Sign-in & security → Connected accounts mit deinem Anbieter verknüpfen. Danach melden sie sich über deinen Anbieter an, mit oder ohne Domain.

InfraNest erkennt ein bestehendes Konto auch von selbst, wenn dessen Adresse auf deiner verifizierten Domain liegt und dein Anbieter die Adresse als verifiziert meldet. Anbieter tun das nicht immer: In Okta hat eine Person, die ein Administrator mit einem Passwort angelegt hat, eine unverifizierte Adresse, bis sie diese bestätigt. Die Test-Anmeldung zeigt an, wenn dein Anbieter die Adresse nicht bestätigt hat. Diese Personen verknüpfen stattdessen über ihr Profil oder bestätigen ihre Adresse bei deinem Anbieter.

#Wer hineinkommt entscheiden

Auf der Verbindung gibt es zwei getrennte Einstellungen:

• Allowed email domains schränkt ein, welche Adressen sie nutzen dürfen. Subdomains sind nicht eingeschlossen — acme.com erlaubt nicht automatisch mail.acme.com.
• When somebody new signs in legt fest, was eine erfolgreiche Anmeldung gewährt:
  • Do nothing — es wird trotzdem eine Einladung benötigt.
  • Ask an admin — die Anmeldung löst eine Beitrittsanfrage aus, die ein Administrator genehmigen muss.
  • Add them straight away — die Person erhält sofort einen Platz, mit der von dir gewählten Rolle.

Die dritte Option gibt es nur für deinen eigenen Identitätsanbieter, nicht für die Anmeldung über Google oder GitHub, denn nur dein Anbieter weiß, wer InfraNest nutzen darf: Jemand, den deine IT-Abteilung der App in Okta oder Entra ID nicht zugewiesen hat, kommt gar nicht erst über den Anmeldebildschirm hinaus. Google dagegen authentifiziert bereitwillig jede Adresse deiner Domain — einschließlich externer Mitarbeitender, geteilter Postfächer und Personen, die das Unternehmen verlassen haben, deren Konto aber noch besteht.

Die Rolle, die neue Mitglieder erhalten, kann niemals Inhaber sein, oder eine Rolle, die Dinge ändern oder löschen kann — hebe einzelne Personen im Nachhinein an.

Der Beitritt ist immer additiv. Jemand, der bereits einen eigenen InfraNest-Workspace hatte, behält ihn und erhält zusätzlich eine Mitgliedschaft in deinem.

#Personen Rollen aus deinen eigenen Gruppen zuweisen

Wenn dein Anbieter bereits trennt, wer was tut — etwa eine Gruppe infra-admins und eine infra-readonly — kann InfraNest das nutzen, statt dass du hier pro Person eine Rolle festlegst.

Unter Credentials and claim names:

1. Trage bei Groups claim das Feld ein, in dem dein Anbieter Gruppen sendet. Okta sendet meist groups; Entra ID sendet roles für App-Rollen. Lässt du es leer, werden Gruppen überhaupt nicht genutzt. Nach einer Test-Anmeldung zeigt InfraNest, welches Feld dein Anbieter tatsächlich verwendet hat, mit einer Schaltfläche, um es zu übernehmen.
2. Füge pro Gruppe eine Zeile hinzu: den Gruppennamen genau so, wie dein Anbieter ihn schreibt, und die Rolle, die er hier erhalten soll. Gruppennamen, die dein Anbieter bei früheren Anmeldungen bereits gesendet hat, werden dir beim Tippen vorgeschlagen.

Was danach zu erwarten ist:

• Rollen folgen deinem Anbieter. Verschiebst du jemanden in eine andere Gruppe, ändert sich seine Rolle hier bei der nächsten Anmeldung.
• Eigene Änderungen bleiben bestehen. Änderst du die Rolle einer Person hier manuell, bleibt sie so, wie du sie festgelegt hast — ihre Gruppen entscheiden ab dann nicht mehr darüber.
• Eine nicht zugeordnete Gruppe ändert nichts. Jemand, dessen Gruppen zu keiner Zeile passen, behält die Rolle, die er hat, sodass ein falsch geschriebener Claim-Name nicht dein ganzes Team herabstufen kann.
• Rollen, die Dinge ändern oder löschen können, lassen sich nicht zuordnen, ebenso wenig wie die Standardrolle. Hebe einzelne Personen selbst an.

#Sensible Aktionen bestätigen

Dein Workspace kann Personen auffordern, Löschungen, Neuaufbauten und Power-Aktionen durch einen erneuten Identitätsnachweis zu bestätigen (Einstellungen → Zugriffsrichtlinie). Jemand, der sich über deinen Identitätsanbieter anmeldet, kann das dort tun: Die Bestätigung zeigt Confirm with deinem Anbieter, ein kleines Fenster öffnet sich, und die Person meldet sich erneut an.

InfraNest akzeptiert dies nur, wenn dein Anbieter die Person wirklich zur erneuten Anmeldung aufgefordert hat, nicht wenn er sie über eine bereits bestehende Sitzung durchgelassen hat. Es prüft den von deinem Anbieter gesendeten Anmeldezeitpunkt, und eine Bestätigung wird einmal verwendet, für die Aktion, für die sie angefordert wurde.

• Okta funktioniert so, wie es ist.
• Entra ID benötigt den Claim auth_time, der der App hinzugefügt werden muss — das dauert eine Minute.
• Google Workspace kann das nicht, weil Google keine Möglichkeit bietet, jemanden erneut zur Anmeldung zu zwingen. Personen bestätigen stattdessen mit einem Passkey, einer Authenticator-App oder ihrem Passwort.
• Andere Anbieter funktionieren, wenn sie auth_time im ID-Token senden. Tut deiner das nicht, zeigt das Fenster dies an.

Blockiert ein Browser das Fenster, erlaube Pop-ups für InfraNest und versuche es erneut.

#Client-Geheimnis erneuern

1. Gehe zu Credentials and claim names bei der Verbindung.
2. Gib das neue Geheimnis ein.
3. Wähle Replace.

WarningDas gespeicherte Geheimnis wird nie wieder angezeigt. Lässt du das Feld leer, bleibt immer das aktuelle erhalten — prüfe daher sorgfältig, ob du das neue Geheimnis korrekt eingefügt hast, bevor du es ersetzt.

#Fehlerbehebung

• Teste die Verbindung zuerst — in den meisten Fällen benennt der Test das Problem, etwa einen nicht erreichbaren Anbieter oder einen Anbieter, der nun einen anderen Issuer meldet als den, mit dem diese Verbindung eingerichtet wurde.
• „Your identity provider rejected this connection's credentials“ bedeutet, dass das Client-Geheimnis bei deinem Anbieter abgelaufen ist oder erneuert wurde. Ersetze es wie oben beschrieben.
• „ does not use for single sign-on“ bedeutet, dass die Person zu einem anderen Workspace gehört, der seinen eigenen Anbieter erfordert. Über den richtigen anzumelden funktioniert.
• Ein Anbieter, der zu einem anderen Tenant gewechselt ist, benötigt eine neue Verbindung: Der Issuer wird beim Erstellen der Verbindung festgelegt, und jede Anmeldung wird dagegen geprüft. Das ist beabsichtigt — es verhindert, dass ein Anbieter unbemerkt gegen einen anderen ausgetauscht wird.
• Deine Administratoren sehen jeden fehlgeschlagenen Versuch mit Begründung in Einstellungen → Audit-Log.

#Claim-Namen

Lass Claim names leer, es sei denn, dein Anbieter verwendet nicht standardmäßige Namen für die E-Mail-Adresse oder den Namen einer Person. Die Standardwerte sind für Okta, Entra ID und Google Workspace korrekt.