Provisionnez les personnes avec SCIM

Ce que fait le provisionnement

• Arrivées. Affectez une personne à l’application dans votre fournisseur et screenRIG crée son compte et fait d’elle un membre de votre organisation. Elle se connecte par authentification unique et n’a pas de mot de passe. Elle n’a aucun projet tant qu’un groupe ne lui en donne pas un.
• Mutations. Un groupe lié à un projet donne ce projet à ses membres. Rejoindre ou quitter le groupe ajoute ou retire l’accès.
• Départs. Désactiver une personne ou retirer son affectation met fin à ses sessions et à son accès. Les agents et les concessions OAuth qu’une personne a approuvés continuent de fonctionner jusqu’à ce que la personne soit désactivée, par le provisionnement des utilisateurs ou par le personnel de screenRIG : exiger l’authentification unique et désactiver la personne chez votre fournisseur n’y met pas fin.

Avant de commencer

• L’authentification unique est configurée et l’organisation a un domaine vérifié. Le provisionnement ne crée que des adresses de vos domaines vérifiés.
• Vous êtes administrateur de l’organisation.

Activez-le

1. Dans les Paramètres de l’organisation, ouvrez Provisionnement des utilisateurs (SCIM) et choisissez Activer le provisionnement. Copiez l’URL de base, https://api.screenrig.ai/scim/v2. Elle se trouve sur l’origine de l’API, pas sur celle du tableau de bord.
2. Sous Jetons de provisionnement, choisissez Créer un jeton, saisissez un Nom du jeton (Entra, par exemple) et confirmez. Copiez le jeton maintenant : srscim_ suivi de 43 caractères, affiché une seule fois. screenRIG ne conserve qu’un hachage.

Activer le provisionnement et créer un jeton demandent votre clé d’accès ou votre mot de passe. Une session d’authentification unique compte à la place comme une connexion récente pendant 10 minutes, lorsque votre fournisseur indique quand la personne s’est authentifiée; sinon, le tableau de bord demande à la personne de se reconnecter chez le fournisseur.

Une organisation détient jusqu’à cinq jetons. Pour effectuer la rotation d’un jeton, créez un nouveau jeton, collez-le dans votre fournisseur, puis révoquez l’ancien ; le provisionnement continue de fonctionner. La liste indique quand chaque jeton a été utilisé pour la dernière fois. Désactiver le provisionnement fait répondre 403 à chaque requête et ne modifie l’accès de personne.

Microsoft Entra ID

1. Ouvrez votre application d’entreprise (celle qui porte l’authentification unique), choisissez Provisioning et réglez Provisioning Mode sur Automatic.
2. Sous Admin Credentials, saisissez l’URL de base comme Tenant URL et le jeton comme Secret Token. Choisissez Test Connection, puis Save.
3. Ouvrez Mappings, Provision Microsoft Entra ID Users. Faites correspondre userName à partir de userPrincipalName (ou de mail lorsque vos noms d’utilisateur principaux ne sont pas les adresses avec lesquelles les personnes se connectent), emails[type eq "work"].value à partir de mail, et laissez active à sa valeur par défaut, Switch([IsSoftDeleted], , "False", "True", "True", "False"). Conservez les autres mappages qu’Entra propose. screenRIG utilise le courriel professionnel, sinon le courriel principal, sinon userName ; cette adresse doit appartenir à un domaine vérifié et être celle que votre authentification unique envoie.
4. Gardez Provision Microsoft Entra ID Groups activé pour donner l’accès par groupe.
5. Dans Settings, réglez Scope sur Sync only assigned users and groups, puis affectez les personnes et les groupes sous Users and groups.
6. Réglez Provisioning Status sur On et enregistrez. Entra exécute un premier cycle, puis synchronise environ toutes les 40 minutes. Provision on demand synchronise immédiatement une personne ou un groupe.

Okta

1. Ouvrez votre application screenRIG. Sous General, modifiez App Settings et réglez Provisioning sur SCIM.
2. Ouvrez Provisioning, Integration, Edit. Saisissez l’URL de base comme SCIM connector base URL et userName comme Unique identifier field for users, cochez Push New Users, Push Profile Updates et Push Groups, et réglez Authentication Mode sur HTTP Header. Dans une application SCIM personnalisée, collez le jeton dans le champ HTTP Header. Là où Okta demande un API Token (les applications de test SCIM d’Okta), saisissez Bearer, une espace et le jeton. Les deux fonctionnent. Choisissez Test Connector Configuration, puis Save.
3. Ouvrez To App, Edit, et activez Create Users, Update User Attributes et Deactivate Users. Laissez Sync Password désactivé : screenRIG ignore les mots de passe.
4. Sur Sign On, réglez Application username format sur Email.
5. Affectez les personnes et les groupes sous Assignments, et poussez les groupes que vous liez sous Push Groups.

Okta désactive une personne avec active: false et ne supprime jamais.

Groupes et projets

Les groupes provisionnés sont listés dans les Paramètres de l’organisation, sous Provisionnement des utilisateurs (SCIM), dans Groupes provisionnés, avec leur nombre de membres et les projets auxquels ils sont liés. Un groupe ne donne aucun accès tant qu’une personne qui peut approuver dans un projet ne le lie pas :

1. Dans le projet, ouvrez Accès, puis Groupes. Tout membre peut lire les liaisons ; le propriétaire du projet, les membres qui peuvent approuver et les administrateurs de l’organisation qui sont membres lient un groupe.
2. Sous Lier un groupe, choisissez un Groupe et un Rôle : Membre, une simple adhésion, ou Approbateur, qui approuve aussi les examens. Choisissez Lier le groupe. Retirer la liaison délie le groupe.

Une liaison peut aussi limiter ce qu’elle donne à des dossiers d’écrans et à des écrans, le même périmètre d’écrans auquel un membre peut être limité : dans Lier un groupe, choisissez Tout le projet ou Limité à des écrans (une liaison Approbateur ne nomme que des dossiers). Les écrans d’une personne dans le projet sont l’union des périmètres de ses liaisons, et toute liaison sans périmètre donne le projet entier; la personne n’approuve que là où ses liaisons Approbateur couvrent tous ces écrans, de sorte qu’Approbateur d’un dossier plus Membre du projet entier fait d’elle un simple membre du projet entier. Le provisionnement ne réduit jamais un accès accordé à la main et ne limite pas une personne tant que des clients de service qu’elle a créés sont actifs : chaque refus de ce genre apparaît dans l’activité récente du Provisionnement des utilisateurs, et le périmètre s’applique à la synchronisation suivante une fois les clients révoqués. Le périmètre d’une liaison est fixe; pour le changer, retirez la liaison et liez de nouveau le groupe.

• Sans périmètre, une personne dans plusieurs groupes liés détient le rôle le plus élevé, Approbateur plutôt que Membre.
• Rejoindre ou quitter un groupe ajoute ou retire l’adhésion. Dissocier un groupe, ou le supprimer chez votre fournisseur, retire ce qu’il avait accordé.
• Le provisionnement ne retire que ce qu’il a ajouté. Une adhésion accordée à la main reste, et un membre qu’un groupe a élevé au rôle d’Approbateur retrouve son rôle d’origine quand il le quitte.
• Une organisation compte jusqu’à 200 membres, tous projets confondus, chaque personne comptant une seule fois. Une personne qu’elle refuse est consignée comme un échec dans les événements de provisionnement et rien d’autre ne change.
• Les groupes n’accordent que des rôles de projet, jamais celui d’administrateur de l’organisation. Les administrateurs voient les liaisons et les noms de projet, pas le contenu des projets.

Qui peut être provisionné

• Une adresse d’un domaine vérifié sans compte en crée un, sans mot de passe.
• Une personne qui n’a ni mot de passe ni clé d’accès, que votre organisation gère, ou qui relève d’une organisation exigeant l’authentification unique, est prise en charge et se connecte par authentification unique.
• Une personne qui a déjà sa propre connexion et qui est membre d’un des projets de votre organisation est associée pour l’accès seulement, sauf si votre organisation exige l’authentification unique. Le provisionnement gère son accès à vos projets, jamais son nom, son courriel ni sa connexion.
• Toute autre personne est refusée avec une erreur qui en nomme la raison : un compte avec sa propre connexion qui n’est pas membre de vos projets, une personne qu’une autre organisation gère, et le personnel de screenRIG. Invitez d’abord une telle personne à l’un de vos projets, et le provisionnement l’associe alors pour l’accès.

Désactivation et DELETE

active: false, envoyé par PUT ou PATCH, et DELETE mettent tous deux fin à l’accès d’une personne. active: true annule une désactivation, comme l’indiquent les tableaux.

Une personne désactivée par quelqu’un d’autre que votre provisionnement, comme le personnel de screenRIG, reste désactivée : active: true échoue avec 400 mutability. Un projet appartenant à une personne n’est jamais transféré : une personne associée conserve son accès à ce projet, et le projet d’une personne gérée attend avec le reste de son compte jusqu’à la réactivation. Transférez-en la propriété avant de désactiver le propriétaire si d’autres personnes doivent continuer à le gérer. Le dernier administrateur de l’organisation ne peut pas être désactivé en tant que personne gérée ; la requête échoue avec 400 mutability, alors ajoutez d’abord un autre administrateur.

Référence

URL de base https://api.screenrig.ai/scim/v2. Le jeton se place dans Authorization: Bearer srscim_TOKEN, et un jeton seul est aussi accepté. Les requêtes et les réponses sont en application/scim+json ; application/json est accepté.

Les filtres comptent de un à quatre termes attribute eq value reliés par and. Une valeur est une chaîne entre guillemets, ou true ou false pour active. Les utilisateurs se filtrent sur userName (insensible à la casse), externalId (exact), id, emails ou emails.value, displayName et active. Les groupes se filtrent sur displayName, externalId, id et members ou members.value. Tout le reste donne 400 invalidFilter.

PATCH lit les opérations telles qu’Entra et Okta les envoient, avec ou sans ?aadOptscim062020. Les noms d’opération sont insensibles à la casse, et les booléens sont true, false, "True" ou "False". Une opération peut omettre path ou utiliser des clés à points telles que {"name.givenName": "Ada"}. Les chemins comprennent emails[type eq "work"].value, members (ajouter, remplacer et retirer avec un tableau de valeurs) et members[value eq "<id>"] (retirer). Les attributs que screenRIG n’utilise pas sont acceptés et ignorés.

Limites. Une organisation peut envoyer 600 requêtes par minute pour l’ensemble de ses jetons, et non par adresse, parce qu’Entra et Okta partagent leurs adresses sources. Au-delà de la limite, la réponse est 429 avec Retry-After. Les échecs d’authentification sont limités à 30 par 10 minutes pour chaque adresse.

Les erreurs utilisent l’enveloppe SCIM avec scimType, par exemple invalidFilter, uniqueness ou mutability :

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

Le provisionnement des utilisateurs, dans les Paramètres de l’organisation, liste les 500 dernières requêtes, conservées 30 jours, échecs inclus avec leur motif. Regardez-y d’abord lorsque quelque chose n’arrive pas.

Dépannage

Lié

• Authentification unique : connectez Entra ID, Okta, Google Workspace ou un autre fournisseur, et exigez-la.
• Authentification : comment les agents se connectent et comment l’accès est approuvé.
• Référence API : les routes /scim/v2 et de provisionnement.