Ouvrir une session pour votre équipe avec SSO

Ce que vous allez créer

À la fin de ce tutoriel, vous disposerez de :

une connexion SAML entre votre serveur Control Center et un fournisseur d’identité (nous prenons Okta comme exemple),
un utilisateur provisionné automatiquement à sa première connexion et
une politique d’adhésion aux espaces de travail que vous avez choisie délibérément.

Vous aurez besoin d’un serveur que vous administrez (le propriétaire du serveur — l’exploitant de l’installation) et d’une application IdP que vous pouvez configurer. Prévoyez 20 minutes.

1. Ouvrir les paramètres d’authentification unique

Connectez-vous à Control Center, puis allez à Paramètres → Serveur → Authentification unique. L’écran permet de basculer entre SAML et OpenID Connect, en plus d’une carte Provisionnement des utilisateurs (SCIM). Restez sur SAML.

Tout sur cet écran s’applique à l’échelle du serveur : un seul IdP authentifie les personnes de tous les espaces de travail, de sorte que seul le propriétaire du serveur peut le modifier.

2. Coller les métadonnées de l’IdP

Dans Okta, ouvrez l’onglet Sign On de votre application et copiez le XML des métadonnées (ou téléchargez-le et collez le contenu du fichier). De retour dans Control Center, collez-le dans XML de métadonnées de l’IdP et appuyez sur Tester la connexion.

Le toast indique le point de terminaison de connexion de l’IdP — preuve que les métadonnées ont été analysées, que le certificat a été lu et que le serveur peut construire une demande de connexion à partir de celles-ci (le test exerce tout, sauf l’aller-retour dans le navigateur). S’il échoue, le XML n’était pas un EntityDescriptor complet (l’onglet SAML d’Okta l’appelle « Metadata URL » ; ouvrez l’URL et copiez ce qu’elle sert). Le même bouton sous OpenID Connect vérifie plutôt le document de découverte de votre émetteur. Pour aussi détecter un certificat arrivant à expiration et voir si l’IdP reconnaît Control Center, utilisez le vérificateur de l’étape 6.

3. Enregistrer Control Center chez l’IdP

Appuyez sur Copier les métadonnées SP et remettez-les à la personne qui configure le côté Okta (ou lisez-lui les deux valeurs qu’elle demande) :

URL ACS : https://<your-server>/saml/acs
ID d’entité : https://<your-server>/saml

Ces URL découlent de l’origine que joignent les navigateurs de vos utilisateurs. Si le serveur tourne derrière un tunnel ou un proxy inverse, assurez-vous que l’origine est stable (Paramètres → Serveur → Connexion et état → Partager ce serveur indique l’URL publique) — ou fixez l’ID d’entité explicitement dans le champ ID d’entité du SP.

4. Choisir ce qu’accorde une connexion

Deux politiques déterminent ce que fait une première connexion :

Ajouter les utilisateurs à tous les espaces à la première connexion — laissez cette option active pour un déploiement à une seule équipe, où l’authentification unique équivaut à une marque de confiance. Désactivez-la lorsque plusieurs équipes ou clients partagent le serveur : chaque nouvel arrivant doit alors recevoir une invitation explicite à un espace de travail, ce qui constitue le réglage par défaut plus sûr.
Provisionner les utilisateurs inconnus à la première connexion — actif par défaut ; désactivez-le pour refuser toute personne dont le compte n’existe pas déjà.

Vous pouvez aussi associer un attribut contenant les noms de groupes (celui d’Okta est généralement groups) et traduire les groupes en rôles au moyen de la table d’association — par exemple {"platform-leads": "admin"}. L’authentification unique ne peut jamais accorder le rôle propriétaire.

5. Activer et effectuer une connexion

Activez Utiliser SAML pour la connexion, appuyez sur Enregistrer la connexion, puis ouvrez une fenêtre de navigation privée à l’adresse https://<your-server>/saml/login. Connectez-vous à Okta et vous revenez au client web — connecté, avec votre compte créé et son adhésion accordée selon la politique que vous avez choisie.

Le même point d’entrée apparaît sur l’écran de connexion web (Se connecter avec SAML) dès que vous saisissez l’adresse du serveur — le formulaire s’adapte à ce que le serveur offre (OpenID Connect affiche Se connecter avec OpenID Connect). Le bouton ouvre la connexion dans un nouvel onglet ; une fois l’aller-retour terminé, l’onglet en attente récupère la session automatiquement. L’écran de configuration du serveur de l’application de bureau fait de même : saisissez l’URL du serveur, un bouton Se connecter avec SAML apparaît, ouvre votre navigateur et l’application se connecte une fois l’aller-retour terminé.

6. Vérifier depuis cette page

Avant de déployer l’authentification unique, ou lorsqu’une connexion échoue, vérifiez les éléments ici. Le vérificateur s’exécute entièrement dans votre navigateur : il lit les métadonnées que vous collez dans cet onglet et applique les mêmes règles que le serveur. Si vous lui fournissez l’adresse de votre serveur, il demande aussi à ce serveur si la connexion SAML est activée.

Il détecte ce que Tester la connexion dans l’application ne peut pas voir : un certificat de signature arrivant bientôt à expiration, un IdP qui exige des requêtes signées et, grâce à la connexion d’essai, si l’IdP reconnaît Control Center du tout.

Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.

Prochaines étapes

Confiez aussi le contrôle du cycle de vie à votre IdP : provisionner et déprovisionner des utilisateurs avec SCIM.
Votre IdP parle OpenID Connect plutôt que SAML ? Connecter un fournisseur OpenID Connect.
Curieux de savoir ce que vérifie réellement l’aller-retour dans le navigateur ? Comment fonctionne l’authentification unique.