Connectez les personnes avec votre fournisseur d’identité

Ce que ça fait

• Une connexion par organisation. Un administrateur de l’organisation la configure dans les Paramètres de l’organisation du tableau de bord, sous Authentification unique.
• Vos domaines décident qui l’utilise. La page de connexion demande d’abord un courriel. Une adresse d’un de vos domaines vérifiés continue vers votre fournisseur.
• Votre fournisseur décide qui entre. Une personne dont l’adresse n’appartient à aucun compte est créée à sa première connexion, sauf si vous désactivez Create accounts at first sign-in sur la connexion. Une nouvelle personne n’a aucun projet tant qu’une invitation ou un groupe provisionné ne lui en donne pas un.
• Vos personnes sont des membres. Une personne qui se connecte par votre fournisseur est un membre de votre organisation. Seul votre fournisseur peut la retirer.
• Require single sign-on refuse les mots de passe et les clés d’accès pour vos domaines.

Avant de commencer

• Vous êtes administrateur de l’organisation.
• L’organisation a un domaine vérifié. Dans les Paramètres de l’organisation, sous Domaines vérifiés, saisissez-le dans Ajouter un domaine, choisissez Obtenir l’enregistrement DNS, publiez l’enregistrement TXT affiché, puis choisissez Vérifier example.com (votre propre domaine à sa place). Laissez l’enregistrement en place : screenRIG le vérifie chaque jour et retire un domaine dont l’enregistrement reste absent pendant 7 jours, et l’authentification unique cesse alors pour ses adresses.
• Les modifications de la connexion 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, mais seulement lorsque votre fournisseur indique quand la personne s’est authentifiée (auth_time dans OpenID Connect, AuthnInstant dans SAML). Sinon, screenRIG demande à la personne de se reconnecter chez le fournisseur avant la modification.

Votre fournisseur demande ces valeurs :

Chaque connexion a son propre URI de redirection, car l’ID de la connexion fait partie de l’adresse. Une fois la connexion enregistrée, les paramètres d’authentification unique dans les Paramètres de l’organisation affichent la valeur exacte de chacun sous Valeurs pour votre fournisseur d’identité, avec l’ID de votre connexion déjà renseigné.

Microsoft Entra ID

Le préréglage Entra connecte les personnes d’un seul locataire par OpenID Connect.

1. Dans le Microsoft Entra admin center, ouvrez App registrations et choisissez New registration. Nommez l’application et choisissez Accounts in this organizational directory only. Laissez l’URI de redirection vide : l’étape 6 l’ajoute.
2. Ouvrez Certificates & secrets, créez un secret client et copiez sa Value maintenant, et non son ID.
3. Ouvrez Token configuration, choisissez Add optional claim, choisissez le type ID et ajoutez email et, à côté, auth_time. Sans auth_time, Entra n’indique pas quand la personne s’est authentifiée, et une action sensible renvoie la personne à Entra pour se reconnecter (voir Ce que voient les personnes).
4. Sur Overview, copiez l’Application (client) ID et le Directory (tenant) ID.
5. Dans les Paramètres de l’organisation, sous Authentification unique, choisissez Configurer l’authentification unique, puis Microsoft Entra ID. Saisissez un Nom, que les personnes voient sur la page de connexion, l’Identifiant du locataire, l’Identifiant client et le Secret client, puis choisissez Enregistrer la connexion.
6. Sous Valeurs pour votre fournisseur d’identité, copiez l’URI de redirection, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback avec l’ID de votre connexion. Dans Entra, ouvrez Authentication, ajoutez la plateforme Web (et non Single-page application : l’échange du code s’exécute sur notre serveur) et saisissez la valeur.
7. Lancez un test sign-in.

screenRIG reconnaît une personne par son ID d’objet Entra, jamais par son courriel ni son nom d’utilisateur principal, que les administrateurs Entra peuvent modifier : renommer un utilisateur conserve son compte. Les jetons de tout autre locataire sont refusés. screenRIG lit l’adresse dans la revendication email et, pour un locataire Entra, se rabat sur preferred_username en l’absence de email ; la revendication facultative de l’étape 3 en fait l’adresse courriel de la personne. Entra n’envoie pas email_verified, alors screenRIG accepte l’adresse parce qu’elle appartient à un domaine que vous avez vérifié. Entra laisse chaque utilisateur du locataire se connecter, sauf si Assignment required de l’application d’entreprise est réglé sur Yes.

Okta et autres fournisseurs OpenID Connect

Cela convient à Okta, Auth0, Keycloak et à tout fournisseur dont le document de découverte se trouve à /.well-known/openid-configuration.

1. Chez le fournisseur, créez une application web qui utilise le flux de code d’autorisation. Dans Okta, choisissez Applications, Create App Integration, OIDC, Web Application. Le fournisseur peut demander un URI de redirection avant que screenRIG ne vous en ait fourni un : saisissez dès maintenant n’importe quelle adresse https et remplacez-la à l’étape 4. Affectez les personnes ou les groupes qui peuvent se connecter.
2. Copiez l’ID client, le secret client et l’émetteur, l’adresse https que nomme le document de découverte. Pour Okta, c’est l’URL de l’organisation, par exemple https://example.okta.com, ou l’adresse d’un serveur d’autorisation personnalisé.
3. Dans les Paramètres de l’organisation, sous Authentification unique, choisissez Configurer l’authentification unique, puis OpenID Connect. Saisissez un Nom, l’Émetteur, l’Identifiant client et le Secret client, puis choisissez Enregistrer la connexion.
4. Sous Valeurs pour votre fournisseur d’identité, copiez l’URI de redirection, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback avec l’ID de votre connexion, et saisissez-le comme URI de redirection de l’application chez le fournisseur.
5. Lancez un test sign-in.

Le fournisseur doit prendre en charge PKCE avec S256, le mode de réponse form_post et des jetons d’ID signés avec un algorithme asymétrique, et doit autoriser les portées openid, email et profile. Son jeton d’ID doit porter une revendication email : seul un locataire Entra se rabat sur une autre revendication. Une revendication email_verified, lorsqu’elle est envoyée, doit valoir true. Envoyez une revendication auth_time là où le fournisseur le peut : c’est ainsi que screenRIG apprend quand la personne s’est authentifiée.

SAML 2.0

Cela convient à une application d’entreprise Entra, à Okta, à Google Workspace et à tout autre fournisseur SAML 2.0. Commencez chez le fournisseur, puis saisissez ses métadonnées dans screenRIG, qui affiche les valeurs dont le fournisseur a besoin.

screenRIG exige que chaque réponse remplisse ces conditions :

• La réponse porte exactement une assertion, et celle-ci n’est pas chiffrée.
• L’assertion elle-même est signée avec RSA ou ECDSA et SHA-256 ou plus fort. SHA-1 est refusé, tout comme une réponse signée entourant une assertion non signée.
• L’émetteur de l’assertion est l’ID d’entité de votre fournisseur, et sa restriction d’audience désigne l’ID d’entité de screenRIG.
• La connexion commence chez screenRIG. Une vignette dans le portail d’applications de votre fournisseur (connexion lancée par le fournisseur d’identité) est refusée ; les personnes commencent à la page de connexion de screenRIG.
• Les horloges diffèrent d’au plus 3 minutes, et chaque assertion n’est utilisée qu’une fois.
• Le NameID est présent, au format persistant, adresse courriel ou non spécifié. Un NameID transitoire, ou tout autre format, est refusé. Le NameID est l’identifiant de la personne chez screenRIG ; pour Entra, c’est l’attribut d’ID d’objet.
• Le courriel arrive sous la forme de l’attribut email, mail, urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress ou http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, ou d’un NameID au format courriel.

Entra ID

1. Ouvrez Enterprise applications, New application, Create your own application, et choisissez Integrate any other application you don't find in the gallery.
2. Ouvrez Single sign-on et choisissez SAML. Sous SAML Certificates, téléchargez le Federation Metadata XML et réglez Signing Option sur Sign SAML assertion ou Sign SAML response and assertion.
3. Dans les Paramètres de l’organisation, sous Authentification unique, choisissez Configurer l’authentification unique, puis SAML 2.0. Saisissez un Nom, collez le XML des métadonnées dans Document de métadonnées, puis choisissez Enregistrer la connexion. Valeurs pour votre fournisseur d’identité affiche alors l’Identifiant d’entité et l’Adresse du service consommateur d’assertions (ACS).
4. Dans Entra, modifiez Basic SAML Configuration : l’Identifier est l’ID d’entité et la Reply URL est l’adresse ACS.
5. Laissez les revendications par défaut : elles portent l’ID d’objet et l’adresse courriel de la personne. Vérifiez que les personnes que vous affectez ont une adresse courriel.
6. Affectez les personnes sous Users and groups, puis lancez un test sign-in.

Les personnes déjà connectées par OpenID Connect gardent leur compte quand un locataire passe à SAML, et inversement : les deux protocoles identifient une personne par le locataire et l’ID d’objet Entra. La réponse SAML doit porter la revendication d’identifiant d’objet, que les revendications par défaut d’Entra incluent. Sans elle, screenRIG se rabat sur le NameID, et un compte associé par OpenID Connect ne correspond plus (subject_mismatch).

Okta

1. Choisissez Applications, Create App Integration, SAML 2.0. Okta demande la Single sign-on URL et l’Audience URI avant d’afficher ses métadonnées : saisissez dès maintenant n’importe quelle adresse https pour les deux.
2. Réglez Name ID format sur Persistent et Application username sur Email, et ajoutez l’attribute statement email avec la valeur user.email. Sous Show Advanced Settings, laissez Assertion Signature sur Signed avec Signature Algorithm RSA-SHA256 et Digest Algorithm SHA256, et Assertion Encryption désactivé.
3. Choisissez Finish, ouvrez l’onglet Sign On et copiez les métadonnées du fournisseur d’identité (Identity Provider metadata).
4. Dans les Paramètres de l’organisation, sous Authentification unique, choisissez Configurer l’authentification unique, puis SAML 2.0. Saisissez un Nom, collez les métadonnées dans Document de métadonnées, puis choisissez Enregistrer la connexion. Copiez l’Identifiant d’entité et l’Adresse du service consommateur d’assertions (ACS) depuis Valeurs pour votre fournisseur d’identité.
5. Dans Okta, modifiez SAML Settings : la Single sign-on URL est l’adresse ACS et l’Audience URI est l’ID d’entité.
6. Affectez les personnes, puis lancez un test sign-in.

Google Workspace

1. Dans l’Admin console, ouvrez Apps, Web and mobile apps, Add app, et choisissez Add custom SAML app. Nommez-la.
2. Téléchargez les métadonnées de Google Identity Provider et continuez.
3. Dans les Paramètres de l’organisation, sous Authentification unique, choisissez Configurer l’authentification unique, puis SAML 2.0. Saisissez un Nom, collez les métadonnées dans Document de métadonnées, puis choisissez Enregistrer la connexion. Copiez l’Identifiant d’entité et l’Adresse du service consommateur d’assertions (ACS) depuis Valeurs pour votre fournisseur d’identité.
4. Dans Google, saisissez l’adresse ACS et l’ID d’entité. Réglez Name ID format sur PERSISTENT et Name ID sur Basic Information, Primary email. Laissez Signed response décoché : Google signe alors l’assertion, ce que screenRIG exige.
5. Faites correspondre l’attribut Google Directory Primary email à l’attribut d’application email.
6. Ouvrez le User access de l’application et activez-le pour les personnes qui se connectent, puis lancez un test sign-in.

Rotation d’un certificat

Une connexion accepte jusqu’à quatre certificats de signature, de sorte que la rotation se fait sans interruption. Collez le nouveau certificat à côté de l’ancien (ou collez les nouvelles métadonnées du fournisseur, qui énumèrent les deux) et enregistrez, faites passer le fournisseur au nouveau certificat, puis retirez l’ancien.

Test sign-in

Appuyez sur Connexion de test dans les Paramètres de l’organisation. Vous vous connectez chez votre fournisseur et revenez au tableau de bord, qui affiche l’adresse que le fournisseur a envoyée et indique s’il a envoyé un identifiant stable. Un test ne connecte personne. Un test échoué affiche le message de l’un des codes d’erreur. L’adresse doit appartenir à un domaine vérifié.

C’est un test réussi, ou une véritable ouverture de session, avec le fournisseur, le locataire, l’ID d’entité et le protocole actuels de la connexion qui vous permet d’exiger l’authentification unique.

Require single sign-on

Choisissez Exiger l’authentification unique dans les Paramètres de l’organisation après un test réussi, désignez les administrateurs d’urgence et confirmez. Pour toutes les personnes de vos domaines vérifiés :

• La page de connexion n’offre que votre fournisseur. Un mot de passe ou une clé d’accès est refusé avec sso_required. Les mots de passe et les clés d’accès restent sur le compte, inutilisés, et fonctionnent de nouveau si vous désactivez l’exigence.
• Un compte existant dont l’adresse vérifiée appartient à votre domaine se connecte au même compte à sa première authentification unique, quelles que soient les méthodes de connexion qu’il détient, et conserve ses projets. Votre organisation le gère alors : son courriel suit votre fournisseur à chaque connexion et la personne ne peut pas le modifier.
• Administrateurs d’urgence. Choisissez jusqu’à deux administrateurs de l’organisation qui détiennent une clé d’accès. Ils conservent la connexion par clé d’accès pour le jour où votre fournisseur est hors service, et chacune de ces connexions est consignée. Modifier les administrateurs d’urgence change ce choix par la suite.
• Tant que l’exigence est activée, l’émetteur, l’ID du locataire, l’ID d’entité et le protocole de la connexion ne peuvent pas changer et la connexion ne peut pas être retirée. Les certificats et le secret client peuvent faire l’objet d’une rotation.

La désactivation prend 72 heures. Choisissez Turn off requirement : l’exigence reste en vigueur jusque-là, chaque administrateur reçoit un courriel, et n’importe quel administrateur peut choisir Cancel removal.

Ce que voient les personnes

• La page de connexion demande d’abord le courriel et continue vers votre fournisseur. La réponse dépend du domaine seul, elle n’indique donc pas si une personne a un compte.
• Une session dure 24 heures à partir de la connexion à screenRIG, et l’utilisation ne la prolonge pas. Après 12 heures, le tableau de bord la renouvelle en silence à la page suivante, et il se reconnecte de la même façon une fois la session terminée. Un démarrage silencieux n’envoie aucun indice de connexion, si bien que le fournisseur répond pour le compte dont il détient une session ; s’il s’agit d’une autre personne, le renouvellement échoue avec subject_mismatch. Une personne dont la session chez le fournisseur est active ne tape rien ; sinon, elle se reconnecte.
• Une action qui demande une clé d’accès ou un mot de passe, comme la modification de la connexion, accepte à la place une session d’authentification unique, qui compte comme une connexion récente pendant 10 minutes. Elle ne compte que si votre fournisseur indique quand la personne s’est authentifiée : l’heure propre au fournisseur (auth_time dans OpenID Connect, AuthnInstant dans SAML), et non l’heure de la connexion à screenRIG. Lorsque le fournisseur n’indique aucune heure, ou en indique une de plus de 10 minutes, screenRIG demande à la personne de se reconnecter chez le fournisseur : le tableau de bord fait passer la personne par le fournisseur pour une nouvelle authentification et la ramène là où elle était.
• Une personne que votre fournisseur désactive perd l’accès en 24 heures, et immédiatement avec le provisionnement des utilisateurs. 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.

Associer un compte existant

Une personne de votre domaine vérifié qui a déjà un compte screenRIG avec un mot de passe ou une clé d’accès n’est pas connectée à ce compte par une première authentification unique (account_exists), sauf si vous exigez l’authentification unique. Elle se connecte comme avant, ouvre Profil et connexion à https://screenrig.ai/dashboard/me, choisit Lier l’authentification unique et se connecte chez le fournisseur. Dès lors, l’authentification unique ouvre le même compte, qui conserve ses propres méthodes de connexion. Profil et connexion propose cette association à toute personne connectée de votre domaine qui ne l’a pas encore faite.

Dépannage

Une ouverture de session échouée revient à la page de connexion avec le code dans l’adresse (#sso_error=CODE). Un test échoué affiche sur la connexion le message correspondant à son code.

Lié

• Provisionnement des utilisateurs : créez, mettez à jour et retirez des personnes depuis votre fournisseur, et donnez aux groupes l’accès aux projets.
• Authentification : comment les agents se connectent et comment l’accès est approuvé.
• Référence API : les routes de la connexion, de la politique et de l’ouverture de session.