La connexion par Microsoft ou Google

Deployer sait ouvrir une session par Microsoft (Entra ID) ou par Google, en plus du mot de passe. Sur le service hébergé, c’est l’exploitant qui l’a configuré. Sur une installation chez vous, c’est l’administrateur de l’installation qui déclare l’application chez le fournisseur, puis la renseigne dans Deployer, depuis un écran d’administration et sans toucher au serveur.

L'écran Connexion par fournisseur. Chaque carte dit d'où vient sa configuration.

Faites glisser pour parcourir la capture

Qui peut Administrateur de l’installation

L’écran est réservé à l’administrateur de l’installation, pas à un rôle d’espace : la connexion à Deployer n’appartient à aucun espace. Il s’ouvre depuis le menu « Administration » de l’avatar, entrée « Connexion par fournisseur ».

Ce que la connexion par fournisseur fait, et ne fait pas

• Elle ouvre une session Deployer. Elle n’agit jamais ensuite chez le fournisseur : aucun jeton Microsoft ou Google n’est conservé, Deployer ne les rappelle jamais.
• Le mot de passe reste possible. Un compte peut avoir un mot de passe, une identité de fournisseur, ou les deux ; chacun rattache ou détache la sienne depuis son profil (voir Prendre Deployer en main).
• N’importe qui, dans votre annuaire, peut créer un compte Deployer en se connectant. Un compte sans adhésion à un espace n’a accès à rien : ce sont les invitations qui ouvrent les espaces.
• Une identité n’est rattachée automatiquement à un compte existant que si le fournisseur certifie l’adresse. Sinon, la personne se connecte par mot de passe puis rattache le fournisseur depuis son profil.

Deux façons de configurer, et laquelle gagne

La règle de précédence est fixe : les variables sont le défaut, ce qui est enregistré dans l’écran l’emporte. Deux gestes ne se confondent pas : désactiver un fournisseur (interrupteur « Fournisseur actif ») l’éteint pour de bon, sans repli sur les variables ; « Revenir aux variables » supprime ce qui a été saisi et rend la main au serveur.

Les variables, pour mémoire :

AUTH_MICROSOFT_ENABLED, AUTH_MICROSOFT_CLIENT_ID, AUTH_MICROSOFT_CLIENT_SECRET,
AUTH_MICROSOFT_HOST (https://login.microsoftonline.com par défaut),
AUTH_MICROSOFT_AUTHORITY (organizations par défaut), AUTH_MICROSOFT_ALLOWED_TENANTS
AUTH_GOOGLE_ENABLED, AUTH_GOOGLE_CLIENT_ID, AUTH_GOOGLE_CLIENT_SECRET

Microsoft, pas à pas

1. Inscrire l'application dans Entra

   Dans le portail Entra de votre tenant, créez une inscription d’application. Comme URI de redirection, recopiez telle quelle l’URL de retour que l’écran affiche sur la carte Microsoft : elle dérive de l’adresse publique de votre Deployer. Sur une installation chez vous, l’inscription est celle de votre tenant, à tenant unique.

   

2. Créer le secret client

   Dans l’inscription, créez un secret client et notez sa date d’expiration : Entra en propose 6 mois par défaut, 24 au plus. Dans Deployer, renseignez l’Identifiant client (l’Application ID) et le Secret client. Un secret enregistré n’est plus affiché : laisser le champ vide le conserve.

   

3. Régler l'autorité et les tenants

   Autorité : organizations pour accepter tout annuaire d’entreprise, ou l’identifiant de votre tenant pour n’accepter que le vôtre. Les tenants autorisés restreignent, en plus, à une liste ; vide, tous passent. Le point d’entrée (« host ») ne change que pour un cloud souverain (login.microsoftonline.us, par exemple).

   

4. Faire certifier les adresses

   Pour qu’une connexion Microsoft se rattache toute seule à un compte Deployer existant, Entra doit certifier que l’adresse appartient à votre domaine. Cela demande deux réglages dans l’inscription : le claim optionnel xms_edov sur le jeton d’identité, déclaré par le manifeste ou l’API Graph (l’interface du portail ne le propose plus), et le claim email avec la portée email. Le domaine doit être vérifié dans le tenant.

5. Saisir l'échéance et activer

   Renseignez Expiration du secret avec la date notée chez Entra : Deployer ne peut pas la lire chez le fournisseur, et sans elle personne ne sera prévenu avant la coupure. Activez « Fournisseur actif », puis « Enregistrer ». Le bouton « Continuer avec Microsoft » apparaît sur l’écran de connexion.

   

Google, pas à pas

1. Créer le client OAuth

   Dans la console Google Cloud, créez un identifiant OAuth de type application Web, avec l’URL de retour affichée sur la carte Google comme URI de redirection autorisé. Google certifie les adresses sans réglage : le rattachement automatique à un compte existant fonctionne d’emblée.

   

2. Renseigner et activer

   Identifiant client, secret client, date d’expiration du secret si votre organisation en fixe une, « Fournisseur actif », « Enregistrer ». Le bouton « Continuer avec Google » apparaît sur l’écran de connexion.

   

L’échéance du secret

Un secret client Microsoft expire au plus tard après 24 mois. Le jour où il meurt, plus personne ne se connecte par Microsoft, et le symptôme (« le fournisseur n’a pas pu confirmer votre identité ») arrive loin de la cause. Deployer surveille donc l’échéance saisie dans l’écran et envoie un courriel aux administrateurs de l’installation à 30, 15, 7 et 1 jour. Deux limites, écrites en clair sur l’écran :

• Une configuration sans date d’expiration n’est pas surveillée : « Aucune date d’expiration : personne ne sera prévenu avant la coupure. »
• Un secret posé par variable d’environnement n’est pas surveillé non plus : une installation qui gère ses variables gère aussi ses échéances.

Vérifier

Ouvrez l’écran de connexion dans une fenêtre privée : les boutons des fournisseurs actifs apparaissent au-dessus du formulaire, séparés par « ou ». Connectez-vous avec un compte de votre annuaire. Les messages d’erreur de l’écran de connexion, et ce qu’ils veulent dire, sont dans Prendre Deployer en main ; le plus courant après une première configuration est « Le fournisseur n’a pas pu confirmer votre identité », qui signale une URL de retour qui ne correspond pas à celle déclarée chez le fournisseur.