ConnXL Docs

Administrer

Contrôle d'accès

Chaque environnement a sa propre porte pour les UTILISATEURS FINAUX — distincte de qui peut se connecter à ce tableau de bord. Le contrôle d'accès décide si quelqu'un peut même ouvrir le complément, et quelles fonctions il est autorisé à appeler.

8 min de lecture

Ce n'est pas le même public que Membres et rôles. Cette page couvre les personnes qui se connectent à ce tableau de bord pour configurer ConnXL. Cette page couvre les personnes qui ouvrent votre complément dans Excel et tapent =NAMESPACE.MODULE.FN(…) — vos utilisateurs finaux, qui ne toucheront peut-être jamais au tableau de bord.

Le contrôle d'accès se configure par environnement (un complément Development et son homologue Production peuvent avoir des règles entièrement différentes), dans la zone Access de l'environnement, dans le tableau de bord, répartie en six onglets : Sign-in, Visibility, Audience, Permissions, Network et Activity.

Connectez un fournisseur de connexion

Rien sur cette page n'a d'effet tant qu'au moins un fournisseur d'identité n'est pas connecté et activé. Ajoutez-en un ou plusieurs depuis l'onglet Sign-in :

  • entra — Microsoft Entra ID (Azure AD). Une connexion par environnement.
  • google — Google Workspace. Une connexion par environnement.
  • microsoft-personal — un compte PERSONNEL Microsoft (outlook.com / hotmail.com / live.com). Entra ne couvre que les annuaires professionnels ou scolaires. Une connexion par environnement.
  • oidc — un fournisseur OpenID Connect générique (Okta, Auth0, ou tout IdP conforme au standard). Illimité — connectez-en autant que nécessaire, côte à côte.

Chaque fournisseur est activé ou désactivé indépendamment. Les champs affichés dépendent du type — voir Configurer les fournisseurs d’identité pour savoir où trouver chaque valeur :

FieldTypeDescription
displayNameOptional
stringL'étiquette affichée sur le bouton de connexion (par défaut, le nom du type de fournisseur).
tenantIdEntra
stringL'ID de votre tenant Entra. Inutile — et masqué — lorsque le fournisseur est réglé pour accepter n'importe quelle organisation Microsoft (voir ci-dessous).
clientIdRequired
stringL'ID de l'application (client) enregistrée auprès du fournisseur.
resourceUriEntra
stringL'Application ID URI que l'agent présente comme audience du jeton.
issuerUrlOIDC
URLL'URL de base de l'émetteur OIDC (p. ex. https://votre-tenant.okta.com).
scopesOptional
string[]Des scopes OAuth supplémentaires à demander au-delà de ceux du fournisseur par défaut.
clientSecretRequired
secret://…Une référence au secret client OAuth. En écriture seule — une fois enregistré, le tableau de bord montre seulement qu'un secret est défini, jamais sa valeur.

Il n'y a pas d'interrupteur séparé « exiger la connexion » — la connexion est appliquée automatiquement dès qu'un des fournisseurs ci-dessus est activé.

Entra : une organisation, ou n'importe quelle organisation

Un fournisseur Entra pose une question de plus : qui peut se connecter.

  • Uniquement mon organisation (par défaut) — uniquement les personnes du tenant indiqué dans tenantId. Toute personne venant d'un autre annuaire Microsoft est refusée avant même que la moindre règle de cette page soit consultée.
  • N'importe quelle organisation Microsoft — des personnes d'autres entreprises peuvent aussi se connecter, sous réserve de vos réglages Audience et Permissions ci-dessous. tenantId disparaît, car il n'y a plus d'annuaire unique à épingler.

La seconde option vise un complément que vous partagez avec des partenaires, des clients ou des prestataires vivant dans leurs propres tenants Microsoft. Cela ne signifie pas « ouvert à tous » : chaque appelant doit toujours satisfaire les règles Audience et Permissions ci-dessous, donc un environnement privé n'admet toujours que les personnes que vous avez invitées ou les domaines que vous avez autorisés.

N'importe quelle organisation exige deux changements dans votre propre inscription d'application Azure

Ni l'un ni l'autre ne peut être fait par ConnXL à votre place, et les deux font échouer la connexion s'ils sont oubliés :

  1. Votre inscription d'application doit être multi-tenant — « Comptes dans n'importe quel annuaire organisationnel » dans Azure. Si elle est mono-tenant, Microsoft refuse elle-même les connexions externes sur sa propre page de connexion, avant que la requête n'atteigne votre agent.
  2. Elle doit également demander la revendication facultative xms_edov sur le jeton d'accès — Azure → votre inscription d'application → Configuration du jetonAjouter une revendication facultativeAccèsxms_edov. (Le portail peut signaler que la revendication n'est pas reconnue ; cet avertissement est sans conséquence.) C'est ainsi que Microsoft nous indique qu'une adresse e-mail appartient réellement à la personne qui se connecte. Sans tenant à épingler, c'est la seule chose qui sépare votre liste d'autorisations de quelqu'un qui aurait créé son propre annuaire et y aurait saisi l'adresse d'un de vos utilisateurs — nous refusons donc toute connexion arrivant sans elle, plutôt que de faire confiance à l'adresse.

Aucun fournisseur activé signifie aucune barrière du tout

Tant qu'aucun fournisseur n'est activé, la connexion ne peut pas être exigée — quiconque peut atteindre l'hôte de l'agent peut appeler chaque fonction, quoi que disent Visibility ou Audience ci-dessous. Une bannière sur chaque onglet Access vous le rappelle jusqu'à ce que ce soit résolu.

Choisissez Public ou Privé

L'onglet Visibility est l'interrupteur principal, et c'est le même réglage defaultAccess auquel l'onglet Permissions se rabat pour quiconque n'a aucune autorisation explicite :

  • Privé (par défaut) — seul le public que vous définissez ci-dessous peut entrer.
  • Public — quiconque peut se connecter avec un fournisseur connecté peut ouvrir le complément et appeler ses fonctions, sous réserve de ce que Permissions refuse.

Basculer en Public expose chaque fonction de chaque espace de noms à quiconque dans le fournisseur d'identité de votre organisation, donc le tableau de bord vous demande de confirmer le changement avant qu'il ne prenne effet.

Définissez le public

L'onglet Audience est l'endroit où sont définis les appelants autorisés d'un environnement Privé (les Groups comptent aussi dans les environnements Publics, puisque les autorisations de Permissions les ciblent). Trois mécanismes, plus une liste de blocage qui s'applique dans les deux cas :

FieldTypeDescription
MembersOptional
Invitez des utilisateurs finaux individuels par email. Un membre est invited jusqu'à sa première connexion, puis active ; vous pouvez revoke l'accès (réinviter plus tard) ou supprimer un membre définitivement.
Allowed domainsOptional
Toute personne ayant un email sur un domaine donné peut entrer — p. ex. ajoutez acme.com pour laisser passer toute l'entreprise sans inviter chaque personne.
GroupsOptional
Un ensemble nommé de principaux — des emails individuels, des domaines entiers, ou une revendication de groupe du fournisseur d'identité issue du jeton connecté — pour qu'une seule autorisation Permissions couvre toute une équipe d'un coup.
Denied domainsOptional
Une liste de blocage qui s'applique À LA FOIS dans les environnements Publics et Privés — un refus l'emporte toujours sur une autorisation correspondante, partout dans ce système.

Accordez l'accès aux fonctions et aux ressources

L'onglet Permissions est l'endroit où vous passez de « qui peut entrer » à « ce qu'il peut appeler » :

  • La grille groupe × espace de noms — chaque groupe géré en ligne, chaque espace de noms Excel (le MODULE dans MODULE.FN) où vivent vos fonctions en colonne. Cliquez sur une cellule pour la faire passer par Inherit → Allow → Deny → Inherit. Inherit signifie que le groupe n'a aucune autorisation explicite sur cet espace de noms, donc il se rabat sur le réglage Visibility ci-dessus.
  • Autorisations individuelles — autorisez ou refusez un email ou domaine précis contre * (toutes les fonctions), un espace de noms entier (MODULE.*), ou une fonction exacte — pour les cas qu'un groupe ne couvre pas.
  • Autorisations par fonction — ouvrez la page de détail de n'importe quelle fonction pour trouver une carte dédiée qui autorise ou refuse des groupes, emails ou domaines précis pour cette seule fonction, en écrasant la règle plus large de l'espace de noms.

Un refus l'emporte toujours sur une autorisation correspondante, à tous les niveaux — un groupe autorisé sur tout un espace de noms peut quand même se voir refuser une fonction précise à l'intérieur.

Restreignez par réseau

L'onglet Network ajoute des règles basées sur l'IP par-dessus tout ce qui précède : une plage CIDR IPv4 (ou une adresse seule, traitée comme /32), un effet d'autorisation ou de refus, et une portée (*, un espace de noms, ou une fonction). L'agent vérifie l'IP de la requête de l'appelant contre ces règles au moment de l'exécution — à l'intérieur de votre propre réseau, au plus près des données. Les plages IPv6 ne sont pas encore prises en charge.

Consultez le journal d'activité

L'onglet Activity est un journal d'audit en ajout seul pour l'environnement : chaque connexion, appel refusé, changement d'autorisation et révocation, filtrable par type d'événement.

L'acteur n'est jamais un email en clair

Les entrées d'Activity identifient l'appelant par un hash, pas par son adresse email — le journal est sûr à parcourir et à partager par défaut, tout en vous permettant encore de corréler des événements à la même personne au fil du temps.

Sur cette page