Personen mit Ihrem Identitätsanbieter anmelden

Was es tut

• Eine Verbindung pro Organisation. Ein Organisationsadministrator richtet sie in den Organisationseinstellungen des Dashboards unter Single Sign-on ein.
• Ihre Domains entscheiden, wer es nutzt. Die Anmeldeseite fragt zuerst nach der E-Mail-Adresse. Eine Adresse an einer Ihrer verifizierten Domains wird an Ihren Anbieter weitergeleitet.
• Ihr Anbieter entscheidet, wer zugelassen wird. Eine Person, deren Adresse zu keinem Konto gehört, wird bei ihrer ersten Anmeldung angelegt, es sei denn, Sie schalten Create accounts at first sign-in an der Verbindung aus. Eine neue Person hat kein Projekt, bis eine Einladung oder eine bereitgestellte Gruppe ihr eines gibt.
• Ihre Personen sind Mitglieder. Eine Person, die sich über Ihren Anbieter anmeldet, ist ein Mitglied Ihrer Organisation. Nur Ihr Anbieter entfernt sie.
• Require single sign-on lehnt Passwörter und Passkeys an Ihren Domains ab.

Bevor Sie beginnen

• Sie sind Administrator der Organisation.
• Die Organisation hat eine verifizierte Domain. Geben Sie sie in den Organisationseinstellungen unter Verifizierte Domains in Domain hinzufügen ein, wählen Sie DNS-Eintrag abrufen, veröffentlichen Sie den angezeigten TXT-Eintrag und wählen Sie dann example.com verifizieren (an dessen Stelle Ihre eigene Domain). Lassen Sie den Eintrag bestehen: screenRIG prüft ihn täglich und entfernt eine Domain, deren Eintrag 7 Tage lang fehlt, und Single Sign-on funktioniert für ihre Adressen nicht mehr.
• Änderungen an der Verbindung verlangen Ihren Passkey oder Ihr Passwort. Stattdessen zählt eine Single-Sign-on-Sitzung 10 Minuten lang als kürzliche Anmeldung, aber nur, wenn Ihr Anbieter angibt, wann sich die Person authentifiziert hat (auth_time in OpenID Connect, AuthnInstant in SAML). Andernfalls fordert screenRIG die Person vor der Änderung auf, sich beim Anbieter erneut anzumelden.

Ihr Anbieter verlangt diese Werte:

Jede Verbindung hat ihre eigene Redirect-URI, weil die Verbindungs-ID Teil der Adresse ist. Nachdem Sie eine Verbindung gespeichert haben, zeigen die Single-Sign-on-Einstellungen in den Organisationseinstellungen den genauen Wert jeder einzelnen unter Werte für Ihren Identitätsanbieter, mit eingetragener Verbindungs-ID.

Microsoft Entra ID

Die Entra-Voreinstellung meldet die Personen eines Mandanten über OpenID Connect an.

1. Öffnen Sie im Microsoft Entra admin center App registrations und wählen Sie New registration. Geben Sie einen Namen ein und wählen Sie Accounts in this organizational directory only. Lassen Sie die Redirect-URI leer: Schritt 6 fügt sie hinzu.
2. Öffnen Sie Certificates & secrets, erstellen Sie ein Client-Secret und kopieren Sie jetzt dessen Value, nicht dessen ID.
3. Öffnen Sie Token configuration, wählen Sie Add optional claim, wählen Sie den Typ ID und fügen Sie email und daneben auth_time hinzu. Ohne auth_time gibt Entra nicht an, wann sich die Person authentifiziert hat, und eine sensible Aktion schickt die Person zur erneuten Anmeldung zurück zu Entra (siehe Was Personen sehen).
4. Kopieren Sie unter Overview die Application (client) ID und die Directory (tenant) ID.
5. Wählen Sie in den Organisationseinstellungen unter Single Sign-On Single Sign-On einrichten und dann Microsoft Entra ID. Füllen Sie Name (Personen sehen ihn auf der Anmeldeseite), Mandanten-ID, Client-ID und Client-Geheimnis aus und wählen Sie Verbindung speichern.
6. Kopieren Sie unter Werte für Ihren Identitätsanbieter die Redirect-URI, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback mit Ihrer Verbindungs-ID. Öffnen Sie in Entra Authentication, fügen Sie die Plattform Web hinzu (nicht Single-page application: Der Code-Austausch läuft auf unserem Server) und geben Sie den Wert ein.
7. Führen Sie eine Testanmeldung durch.

screenRIG erkennt eine Person an ihrer Entra-Objekt-ID, nie an der E-Mail-Adresse oder dem Benutzerprinzipalnamen, die Entra-Administratoren bearbeiten können: Wird ein Benutzer umbenannt, behält er sein Konto. Tokens aus jedem anderen Mandanten werden abgelehnt. screenRIG liest die Adresse aus dem Claim email und weicht bei einem Entra-Mandanten auf preferred_username aus, wenn email fehlt; der optionale Claim in Schritt 3 macht ihn zur E-Mail-Adresse der Person. Entra sendet email_verified nicht, daher akzeptiert screenRIG die Adresse, weil sie an einer von Ihnen verifizierten Domain liegt. Entra lässt jeden Benutzer im Mandanten sich anmelden, solange Assignment required der Enterprise-Anwendung nicht auf Yes steht.

Okta und andere OpenID Connect-Anbieter

Das passt für Okta, Auth0, Keycloak und jeden Anbieter mit einem Discovery-Dokument unter /.well-known/openid-configuration.

1. Erstellen Sie im Anbieter eine Webanwendung, die den Authorization-Code-Flow verwendet. Wählen Sie in Okta Applications, Create App Integration, OIDC, Web Application. Der Anbieter verlangt möglicherweise eine Redirect-URI, bevor Sie von screenRIG eine erhalten haben: Geben Sie jetzt eine beliebige https-Adresse ein und ersetzen Sie sie in Schritt 4. Weisen Sie die Personen oder Gruppen zu, die sich anmelden dürfen.
2. Kopieren Sie die Client-ID, das Client-Secret und den Issuer, die https-Adresse, die das Discovery-Dokument nennt. Bei Okta ist das die Org-URL, etwa https://example.okta.com, oder die Adresse eines benutzerdefinierten Autorisierungsservers.
3. Wählen Sie in den Organisationseinstellungen unter Single Sign-On Single Sign-On einrichten und dann OpenID Connect. Füllen Sie Name, Aussteller, Client-ID und Client-Geheimnis aus und wählen Sie Verbindung speichern.
4. Kopieren Sie unter Werte für Ihren Identitätsanbieter die Redirect-URI, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback mit Ihrer Verbindungs-ID, und tragen Sie sie beim Anbieter als Redirect-URI der Anwendung ein.
5. Führen Sie eine Testanmeldung durch.

Der Anbieter muss PKCE mit S256, den Response-Mode form_post und mit einem asymmetrischen Algorithmus signierte ID-Tokens unterstützen und die Scopes openid, email und profile zulassen. Sein ID-Token muss einen Claim email enthalten: Nur ein Entra-Mandant weicht auf einen anderen Claim aus. Ein Claim email_verified muss, wenn er gesendet wird, true sein. Senden Sie, wo der Anbieter es kann, einen Claim auth_time: So erfährt screenRIG, wann sich die Person authentifiziert hat.

SAML 2.0

Das passt für eine Entra-Enterprise-Anwendung, Okta, Google Workspace und jeden anderen SAML 2.0-Anbieter. Beginnen Sie beim Anbieter und geben Sie dann dessen Metadaten in screenRIG ein; screenRIG zeigt die Werte an, die der Anbieter braucht.

screenRIG verlangt, dass jede Response diese Bedingungen erfüllt:

• Die Response enthält genau eine Assertion, und sie ist nicht verschlüsselt.
• Die Assertion selbst ist mit RSA oder ECDSA und SHA-256 oder stärker signiert. SHA-1 wird abgelehnt, ebenso eine signierte Response um eine unsignierte Assertion.
• Der Issuer der Assertion ist die Entity-ID Ihres Anbieters, und ihre Audience Restriction nennt die Entity-ID von screenRIG.
• Die Anmeldung beginnt bei screenRIG. Eine Kachel im App-Portal Ihres Anbieters (IdP-initiierte Anmeldung) wird abgelehnt; Personen beginnen auf der Anmeldeseite von screenRIG.
• Die Uhren weichen höchstens 3 Minuten voneinander ab, und jede Assertion wird nur einmal verwendet.
• Die NameID ist vorhanden, im Format persistent, E-Mail-Adresse oder unspecified. Eine transiente NameID oder jedes andere Format wird abgelehnt. Die NameID ist die Kennung der Person bei screenRIG; bei Entra ist es das Objekt-ID-Attribut.
• Die E-Mail-Adresse kommt als Attribut email, mail, urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress oder http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn an oder als NameID im E-Mail-Format.

Entra ID

1. Öffnen Sie Enterprise applications, New application, Create your own application und wählen Sie Integrate any other application you don't find in the gallery.
2. Öffnen Sie Single sign-on und wählen Sie SAML. Laden Sie unter SAML Certificates das Federation Metadata XML herunter und setzen Sie Signing Option auf Sign SAML assertion oder Sign SAML response and assertion.
3. Wählen Sie in den Organisationseinstellungen unter Single Sign-On Single Sign-On einrichten und dann SAML 2.0. Füllen Sie Name aus, fügen Sie das Metadaten-XML in Metadatendokument ein und wählen Sie Verbindung speichern. Werte für Ihren Identitätsanbieter zeigt dann die Entity-ID und die Adresse des Assertion Consumer Service (ACS) an.
4. Bearbeiten Sie in Entra die Basic SAML Configuration: Der Identifier ist die Entity-ID und die Reply URL ist die ACS-Adresse.
5. Lassen Sie die Standard-Claims unverändert: Sie enthalten die Objekt-ID und die E-Mail-Adresse der Person. Prüfen Sie, dass die Personen, die Sie zuweisen, eine E-Mail-Adresse haben.
6. Weisen Sie Personen unter Users and groups zu und führen Sie dann eine Testanmeldung durch.

Personen, die sich bereits über OpenID Connect angemeldet haben, behalten ihre Konten, wenn ein Mandant zu SAML wechselt, und umgekehrt: Beide Protokolle identifizieren eine Person durch den Mandanten und die Entra-Objekt-ID. Die SAML-Response muss den Objektbezeichner-Claim enthalten, den die Standard-Claims von Entra einschließen. Ohne ihn greift screenRIG auf die NameID zurück, und ein über OpenID Connect verknüpftes Konto passt nicht mehr (subject_mismatch).

Okta

1. Wählen Sie Applications, Create App Integration, SAML 2.0. Okta fragt nach der Single sign-on URL und der Audience URI, bevor es seine Metadaten anzeigt: Geben Sie jetzt für beide eine beliebige https-Adresse ein.
2. Setzen Sie Name ID format auf Persistent und Application username auf Email und fügen Sie das Attribute Statement email mit dem Wert user.email hinzu. Lassen Sie unter Show Advanced Settings Assertion Signature auf Signed mit Signature Algorithm RSA-SHA256 und Digest Algorithm SHA256 und Assertion Encryption aus.
3. Wählen Sie Finish, öffnen Sie den Tab Sign On und kopieren Sie die Identity Provider metadata.
4. Wählen Sie in den Organisationseinstellungen unter Single Sign-On Single Sign-On einrichten und dann SAML 2.0. Füllen Sie Name aus, fügen Sie die Metadaten in Metadatendokument ein und wählen Sie Verbindung speichern. Kopieren Sie die Entity-ID und die Adresse des Assertion Consumer Service (ACS) aus Werte für Ihren Identitätsanbieter.
5. Bearbeiten Sie in Okta die SAML Settings: Die Single sign-on URL ist die ACS-Adresse und die Audience URI ist die Entity-ID.
6. Weisen Sie Personen zu und führen Sie dann eine Testanmeldung durch.

Google Workspace

1. Öffnen Sie in der Admin console Apps, Web and mobile apps, Add app und wählen Sie Add custom SAML app. Geben Sie der App einen Namen.
2. Laden Sie die Metadaten des Google Identity Provider herunter und fahren Sie fort.
3. Wählen Sie in den Organisationseinstellungen unter Single Sign-On Single Sign-On einrichten und dann SAML 2.0. Füllen Sie Name aus, fügen Sie die Metadaten in Metadatendokument ein und wählen Sie Verbindung speichern. Kopieren Sie die Entity-ID und die Adresse des Assertion Consumer Service (ACS) aus Werte für Ihren Identitätsanbieter.
4. Geben Sie in Google die ACS-Adresse und die Entity-ID ein. Setzen Sie Name ID format auf PERSISTENT und Name ID auf Basic Information, Primary email. Lassen Sie Signed response ohne Häkchen: Google signiert dann die Assertion, was screenRIG verlangt.
5. Ordnen Sie das Google-Directory-Attribut Primary email dem App-Attribut email zu.
6. Öffnen Sie in der App User access, schalten Sie den Zugriff für die Personen ein, die sich anmelden, und führen Sie dann eine Testanmeldung durch.

Ein Zertifikat rotieren

Eine Verbindung vertraut bis zu vier Signaturzertifikaten, sodass eine Rotation keine Lücke hat. Fügen Sie das neue Zertifikat neben dem alten ein (oder fügen Sie die neuen Metadaten des Anbieters ein, die beide auflisten) und speichern Sie, stellen Sie den Anbieter auf das neue Zertifikat um und entfernen Sie dann das alte.

Test sign-in

Klicken Sie in den Organisationseinstellungen auf Testanmeldung. Sie melden sich bei Ihrem Anbieter an und kehren zum Dashboard zurück, das die Adresse anzeigt, die der Anbieter gesendet hat, und ob er eine stabile Kennung gesendet hat. Ein Test meldet niemanden an. Ein fehlgeschlagener Test zeigt die Meldung zu einem der Fehlercodes an. Die Adresse muss an einer verifizierten Domain liegen.

Single Sign-on lässt sich verlangen, sobald ein erfolgreicher Test oder eine echte Anmeldung über den aktuellen Anbieter, Mandanten, die aktuelle Entity-ID und das aktuelle Protokoll der Verbindung vorliegt.

Require single sign-on

Wählen Sie nach einem erfolgreichen Test in den Organisationseinstellungen Single Sign-On verlangen, bestimmen Sie die Break-Glass-Administratoren und bestätigen Sie. Für alle an Ihren verifizierten Domains gilt:

• Die Anmeldeseite bietet nur Ihren Anbieter an. Ein Passwort oder ein Passkey wird mit sso_required abgelehnt. Passwörter und Passkeys bleiben ungenutzt am Konto und funktionieren wieder, wenn Sie die Anforderung ausschalten.
• Ein bestehendes Konto, dessen verifizierte Adresse an Ihrer Domain liegt, meldet sich beim ersten Single Sign-on am selben Konto an, gleich welche Anmeldemethoden es hat, und behält seine Projekte. Ihre Organisation verwaltet es dann: Seine E-Mail-Adresse folgt bei jeder Anmeldung Ihrem Anbieter, und die Person kann sie nicht ändern.
• Break-Glass-Administratoren. Wählen Sie bis zu zwei Organisationsadministratoren, die einen Passkey besitzen. Sie behalten die Passkey-Anmeldung für den Tag, an dem Ihr Anbieter ausfällt, und jede solche Anmeldung wird protokolliert. Die Auswahl ändern Sie später mit Break-Glass-Administratoren ändern.
• Solange die Anforderung aktiv ist, können Issuer, Mandanten-ID, Entity-ID und Protokoll der Verbindung nicht geändert und die Verbindung nicht entfernt werden. Zertifikate und das Client-Secret lassen sich rotieren.

Das Ausschalten dauert 72 Stunden. Wählen Sie Turn off requirement: Bis dahin bleibt die Anforderung in Kraft, jeder Administrator erhält eine E-Mail, und jeder Administrator kann Cancel removal wählen.

Was Personen sehen

• Die Anmeldeseite fragt zuerst nach der E-Mail-Adresse und leitet zu Ihrem Anbieter weiter. Die Antwort hängt allein von der Domain ab, sodass sie nicht zeigt, ob eine Person ein Konto hat.
• Eine Sitzung dauert 24 Stunden ab der Anmeldung bei screenRIG, und die Nutzung verlängert sie nicht. Nach 12 Stunden erneuert das Dashboard sie beim nächsten Seitenaufruf still, und nach dem Ende einer Sitzung meldet es auf dieselbe Weise wieder an. Ein stiller Start sendet keinen Anmeldehinweis, daher antwortet der Anbieter für das Konto, für das er eine Sitzung hält; ist das eine andere Person, schlägt die Erneuerung mit subject_mismatch fehl. Eine Person, deren Anbietersitzung noch besteht, gibt nichts ein; andernfalls meldet sie sich erneut an.
• Eine Aktion, die einen Passkey oder ein Passwort verlangt, etwa das Ändern der Verbindung, akzeptiert stattdessen eine Single-Sign-on-Sitzung, die 10 Minuten lang als kürzliche Anmeldung zählt. Sie zählt nur, wenn Ihr Anbieter angibt, wann sich die Person authentifiziert hat: der eigene Zeitpunkt des Anbieters (auth_time in OpenID Connect, AuthnInstant in SAML), nicht der Zeitpunkt der Anmeldung bei screenRIG. Nennt der Anbieter keinen Zeitpunkt oder einen, der älter als 10 Minuten ist, fordert screenRIG die Person auf, sich beim Anbieter erneut anzumelden: Das Dashboard schickt die Person zur erneuten Authentifizierung über den Anbieter und bringt sie dorthin zurück, wo sie war.
• Eine Person, die Ihr Anbieter deaktiviert, verliert den Zugriff innerhalb von 24 Stunden, mit der Benutzerbereitstellung sofort. Agenten und OAuth-Berechtigungen, die eine Person genehmigt hat, funktionieren weiter, bis die Person deaktiviert wird, durch die Benutzerbereitstellung oder durch Mitarbeiter von screenRIG: Weder das Verlangen von Single Sign-on noch das Deaktivieren der Person bei Ihrem Anbieter beendet sie.

Ein bestehendes Konto verknüpfen

Eine Person an Ihrer verifizierten Domain, die bereits ein screenRIG-Konto mit Passwort oder Passkey hat, wird durch ein erstes Single Sign-on (account_exists) nicht in dieses Konto angemeldet, es sei denn, Sie verlangen Single Sign-on. Die Person meldet sich wie bisher an, öffnet Profil und Anmeldung unter https://screenrig.ai/dashboard/me, wählt Single Sign-On verknüpfen und meldet sich beim Anbieter an. Von da an öffnet Single Sign-on dasselbe Konto, das seine eigenen Anmeldemethoden behält. Profil und Anmeldung bietet die Verknüpfung jeder angemeldeten Person an Ihrer Domain an, die noch nicht verknüpft hat.

Fehlerbehebung

Eine fehlgeschlagene Anmeldung führt zur Anmeldeseite zurück, mit dem Code in der Adresse (#sso_error=CODE). Ein fehlgeschlagener Test zeigt an der Verbindung die Meldung zu seinem Code an.

Verwandt

• Benutzerbereitstellung: Personen von Ihrem Anbieter aus anlegen, aktualisieren und entfernen und Gruppen Zugriff auf Projekte geben.
• Authentifizierung: wie sich Agenten anmelden und wie Zugriff genehmigt wird.
• API-Referenz: die Routen für Verbindung, Richtlinie und Anmeldung.