Personen mit SCIM bereitstellen

Was die Bereitstellung tut

• Eintritte. Weisen Sie in Ihrem Anbieter der Anwendung eine Person zu, und screenRIG legt deren Konto an und macht sie zu einem Mitglied Ihrer Organisation. Die Person meldet sich per Single Sign-on an und hat kein Passwort. Sie hat kein Projekt, bis eine Gruppe ihr eines gibt.
• Wechsel. Eine an ein Projekt gebundene Gruppe gibt ihren Mitgliedern dieses Projekt. Wenn eine Person der Gruppe beitritt oder sie verlässt, wird der Zugriff hinzugefügt oder entfernt.
• Austritte. Wenn Sie eine Person deaktivieren oder ihre Zuweisung aufheben, enden ihre Sitzungen und ihr Zugriff. 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.

Bevor Sie beginnen

• Single Sign-on ist eingerichtet, und die Organisation hat eine verifizierte Domain. Die Bereitstellung legt nur Adressen an Ihren verifizierten Domains an.
• Sie sind Administrator der Organisation.

Einschalten

1. Öffnen Sie in den Organisationseinstellungen Bereitstellung von Personen (SCIM) und wählen Sie Bereitstellung einschalten. Kopieren Sie die Basis-URL, https://api.screenrig.ai/scim/v2. Sie liegt auf dem API-Origin, nicht auf dem des Dashboards.
2. Wählen Sie unter Bereitstellungstokens Token erstellen, geben Sie bei Tokenname einen Namen ein (zum Beispiel Entra) und bestätigen Sie. Kopieren Sie das Token jetzt: srscim_ gefolgt von 43 Zeichen, nur einmal angezeigt. screenRIG speichert nur einen Hash.

Das Einschalten der Bereitstellung und das Erstellen eines Tokens verlangen Ihren Passkey oder Ihr Passwort. Stattdessen zählt eine Single-Sign-on-Sitzung 10 Minuten lang als kürzliche Anmeldung, wenn Ihr Anbieter angibt, wann sich die Person authentifiziert hat; andernfalls fordert das Dashboard die Person auf, sich beim Anbieter erneut anzumelden.

Eine Organisation hat bis zu fünf Tokens. Um eines zu rotieren, erstellen Sie ein neues Token, fügen Sie es in Ihren Anbieter ein und widerrufen Sie dann das alte; die Bereitstellung läuft weiter. Die Liste zeigt, wann jedes Token zuletzt verwendet wurde. Wenn Sie die Bereitstellung ausschalten, antwortet jede Anfrage mit 403, und der Zugriff von niemandem ändert sich.

Microsoft Entra ID

1. Öffnen Sie Ihre Enterprise-Anwendung (diejenige, über die Single Sign-on läuft), wählen Sie Provisioning und setzen Sie Provisioning Mode auf Automatic.
2. Geben Sie unter Admin Credentials die Base URL als Tenant URL und das Token als Secret Token ein. Wählen Sie Test Connection und dann Save.
3. Öffnen Sie Mappings, Provision Microsoft Entra ID Users. Ordnen Sie userName aus userPrincipalName zu (oder aus mail, wenn Ihre Benutzerprinzipalnamen nicht die Adressen sind, mit denen sich Personen anmelden), emails[type eq "work"].value aus mail, und lassen Sie active auf dem Standardwert Switch([IsSoftDeleted], , "False", "True", "True", "False"). Behalten Sie die anderen Zuordnungen bei, die Entra vorschlägt. screenRIG verwendet die geschäftliche E-Mail-Adresse, sonst die primäre E-Mail-Adresse, sonst userName; diese Adresse muss an einer verifizierten Domain liegen und die Adresse sein, die Ihr Single Sign-on sendet.
4. Lassen Sie Provision Microsoft Entra ID Groups aktiviert, um Zugriff per Gruppe zu geben.
5. Setzen Sie unter Settings Scope auf Sync only assigned users and groups und weisen Sie dann unter Users and groups die Personen und Gruppen zu.
6. Setzen Sie Provisioning Status auf On und speichern Sie. Entra führt einen ersten Zyklus aus und synchronisiert dann etwa alle 40 Minuten. Provision on demand synchronisiert eine Person oder Gruppe sofort.

Okta

1. Öffnen Sie Ihre screenRIG-Anwendung. Bearbeiten Sie unter General die App Settings und setzen Sie Provisioning auf SCIM.
2. Öffnen Sie Provisioning, Integration, Edit. Geben Sie die Basis-URL als SCIM connector base URL ein und userName als Unique identifier field for users, aktivieren Sie Push New Users, Push Profile Updates und Push Groups und setzen Sie Authentication Mode auf HTTP Header. Fügen Sie in einer benutzerdefinierten SCIM-App das Token in das Feld HTTP Header ein. Wo Okta einen API Token verlangt (die SCIM-Test-Apps von Okta), geben Sie Bearer, ein Leerzeichen und das Token ein. Beides funktioniert. Wählen Sie Test Connector Configuration und dann Save.
3. Öffnen Sie To App, Edit und aktivieren Sie Create Users, Update User Attributes und Deactivate Users. Lassen Sie Sync Password ausgeschaltet: screenRIG ignoriert Passwörter.
4. Setzen Sie unter Sign On das Application username format auf Email.
5. Weisen Sie die Personen und Gruppen unter Assignments zu und pushen Sie die Gruppen, die Sie binden, unter Push Groups.

Okta deaktiviert eine Person mit active: false und löscht nie.

Gruppen und Projekte

Bereitgestellte Gruppen sind in den Organisationseinstellungen unter Bereitstellung von Personen (SCIM) in Bereitgestellte Gruppen aufgeführt, mit ihrer Mitgliederzahl und den Projekten, denen sie zugeordnet sind. Eine Gruppe gibt keinen Zugriff, bis eine Person, die in einem Projekt genehmigen kann, sie zuordnet:

1. Öffnen Sie im Projekt Zugriff und dann Gruppen. Jedes Mitglied sieht die Zuordnungen; der Projektinhaber, Mitglieder, die genehmigen können, und Admins der Organisation, die Mitglieder sind, ordnen eine Gruppe zu.
2. Wählen Sie unter Gruppe zuordnen eine Gruppe und eine Rolle: Mitglied, eine einfache Mitgliedschaft, oder Genehmiger, der auch Reviews genehmigt. Wählen Sie Gruppe zuordnen. Zuordnung entfernen hebt die Zuordnung auf.

Eine Bindung kann das, was sie gewährt, auch auf Bildschirmordner und Bildschirme beschränken, denselben Bildschirmbereich, auf den ein Mitglied beschränkt werden kann: Wählen Sie unter Gruppe zuordnen Gesamtes Projekt oder Auf Bildschirme beschränkt (eine Genehmiger-Bindung nennt nur Ordner). Die Bildschirme einer Person im Projekt sind die Vereinigung der Bereiche ihrer Bindungen, und jede Bindung ohne Bereich gibt das gesamte Projekt; die Person genehmigt nur dort, wo ihre Genehmiger-Bindungen alle diese Bildschirme abdecken, sodass Genehmiger eines Ordners plus Mitglied des gesamten Projekts die Person zu einem einfachen Mitglied des gesamten Projekts macht. Die Bereitstellung verringert nie einen von Hand gewährten Zugriff und beschränkt eine Person nicht, solange Service-Clients, die sie erstellt hat, aktiv sind: Jede solche Ablehnung erscheint in der letzten Aktivität der Bereitstellung von Personen, und der Bereich gilt bei der nächsten Synchronisierung, sobald die Clients widerrufen sind. Der Bereich einer Bindung ist fest; um ihn zu ändern, entfernen Sie die Bindung und ordnen die Gruppe erneut zu.

• Ohne Bereiche hat eine Person in mehreren gebundenen Gruppen die höchste Rolle: Genehmiger vor Mitglied.
• Wenn eine Person einer Gruppe beitritt oder sie verlässt, wird die Mitgliedschaft hinzugefügt oder entfernt. Wenn Sie die Bindung einer Gruppe aufheben oder sie in Ihrem Anbieter löschen, wird zurückgenommen, was sie gewährt hat.
• Die Bereitstellung entfernt nur, was sie hinzugefügt hat. Eine von Hand gewährte Mitgliedschaft bleibt bestehen, und ein Mitglied, das durch eine Gruppe zum Genehmiger wurde, kehrt beim Verlassen der Gruppe zu seiner vorherigen Rolle zurück.
• Eine Organisation fasst bis zu 200 Mitglieder über alle ihre Projekte, wobei jede Person einmal zählt. Eine Person, die sie ablehnt, wird in den Bereitstellungsereignissen als Fehler erfasst, und sonst ändert sich nichts.
• Gruppen gewähren nur Projektrollen, nie die Rolle des Organisationsadministrators. Administratoren sehen Bindungen und Projektnamen, nicht Projektinhalte.

Wer bereitgestellt werden kann

• Eine Adresse an einer verifizierten Domain ohne Konto legt eines an, ohne Passwort.
• Eine Person, die kein Passwort und keinen Passkey hat, von Ihrer Organisation verwaltet wird oder zu einer Organisation gehört, die Single Sign-on verlangt, wird übernommen und meldet sich per Single Sign-on an.
• Eine Person, die bereits eine eigene Anmeldung hat und Mitglied eines Projekts Ihrer Organisation ist, wird nur für den Zugriff verknüpft, es sei denn, Ihre Organisation verlangt Single Sign-on. Die Bereitstellung verwaltet ihren Zugriff auf Ihre Projekte und nie ihren Namen, ihre E-Mail-Adresse oder ihre Anmeldung.
• Alle anderen werden mit einem Fehler abgelehnt, der den Grund nennt: ein Konto mit eigener Anmeldung, das kein Mitglied Ihrer Projekte ist, eine Person, die eine andere Organisation verwaltet, und Mitarbeitende von screenRIG. Laden Sie eine solche Person zuerst in eines Ihrer Projekte ein, dann verknüpft die Bereitstellung sie für den Zugriff.

Deaktivierung und DELETE

active: false, gesendet per PUT oder PATCH, und DELETE beenden beide den Zugriff einer Person. active: true macht eine Deaktivierung rückgängig, wie die Tabellen angeben.

Eine Person, die von jemand anderem als Ihrer Bereitstellung deaktiviert wurde, etwa durch Mitarbeiter von screenRIG, bleibt deaktiviert: active: true schlägt mit 400 mutability fehl. Ein Projekt, das einer Person gehört, wird nie übertragen: Eine verknüpfte Person behält ihren Zugriff darauf, und das Projekt einer verwalteten Person wartet mit dem Rest ihres Kontos bis zur Reaktivierung. Übertragen Sie das Eigentum daran vor der Deaktivierung des Inhabers, wenn andere es weiter verwalten müssen. Der letzte Administrator der Organisation kann als verwaltete Person nicht deaktiviert werden; die Anfrage schlägt mit 400 mutability fehl, fügen Sie daher zuerst einen weiteren Administrator hinzu.

Referenz

Basis-URL https://api.screenrig.ai/scim/v2. Das Token steht in Authorization: Bearer srscim_TOKEN; ein Token allein wird ebenfalls akzeptiert. Anfragen und Antworten sind application/scim+json; application/json wird akzeptiert.

Filter bestehen aus einem bis vier Termen der Form attribute eq value, verbunden durch and. Ein Wert ist eine Zeichenfolge in Anführungszeichen oder true oder false für active. Benutzer lassen sich nach userName (ohne Beachtung der Groß-/Kleinschreibung), externalId (exakt), id, emails oder emails.value, displayName und active filtern. Gruppen lassen sich nach displayName, externalId, id und members oder members.value filtern. Alles andere ergibt 400 invalidFilter.

PATCH liest Operationen so, wie Entra und Okta sie senden, mit oder ohne ?aadOptscim062020. Operationsnamen beachten die Groß-/Kleinschreibung nicht, und boolesche Werte sind true, false, "True" oder "False". Eine Operation darf path weglassen oder Schlüssel mit Punkten wie {"name.givenName": "Ada"} verwenden. Zu den Pfaden gehören emails[type eq "work"].value, members (hinzufügen, ersetzen und mit einem Wertearray entfernen) und members[value eq "<id>"] (entfernen). Attribute, die screenRIG nicht verwendet, werden akzeptiert und ignoriert.

Limits. Eine Organisation darf mit all ihren Tokens zusammen 600 Anfragen pro Minute senden, nicht pro Adresse, weil Entra und Okta Quelladressen gemeinsam nutzen. Über dem Limit lautet die Antwort 429 mit Retry-After. Fehlgeschlagene Authentifizierungen sind auf 30 pro 10 Minuten für jede Adresse begrenzt.

Fehler verwenden die SCIM-Fehlerstruktur mit scimType, etwa invalidFilter, uniqueness oder mutability:

{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "status": "409", "scimType": "uniqueness", "detail": "…" }

Die Benutzerbereitstellung in den Organisationseinstellungen listet die letzten 500 Anfragen auf, 30 Tage lang aufbewahrt, Fehler samt Grund eingeschlossen. Schauen Sie zuerst dort nach, wenn etwas nicht ankommt.

Fehlerbehebung

Verwandt

• Single Sign-on: Entra ID, Okta, Google Workspace oder einen anderen Anbieter verbinden und Single Sign-on verlangen.
• Authentifizierung: wie sich Agenten anmelden und wie Zugriff genehmigt wird.
• API-Referenz: die Routen /scim/v2 und die Bereitstellungsrouten.