Contrôler l’accès avec des règles d’accès conditionnel

La fonction SSO est activée sur les plans Advanced et Ultimate, et est autrement disponible en tant qu’option.

Huwise permet de gérer l’accès à votre espace de travail via une solution d’authentification unique (SSO), et prend actuellement en charge les protocoles OpenID Connect et SAML 2.0.

Les règles d’accès conditionnel vous permettent de décider, lors de l’identification, si un utilisateur SSO peut accéder à votre espace de travail, se voit refuser l’accès ou est mis en file d’attente pour approbation par l’administrateur du portail. Chaque règle examine les attributs d’identité de l’utilisateur (claims pour OIDC, attributs d’assertion pour SAML) et déclenche une action lorsque ses conditions sont remplies. Cela vous donne un contrôle précis basé sur les attributs sur qui peut accéder à votre place de marché de données.

Lorsqu’un utilisateur se connecte via un fournisseur d’identité qui a des règles d’accès configurées, Huwise évalue les règles dans un ordre précis pour déterminer le résultat. Comprendre cet ordre est essentiel pour construire des règles qui se comportent comme vous l’attendez.

Voici ce qui se passe à chaque connexion :

1. Huwise récupère toutes les règles actives pour le fournisseur d’identité, triées par priorité (numéro le plus bas en premier).

2. Pour chaque règle, Huwise vérifie si les attributs d’identité de l’utilisateur correspondent aux conditions de la règle. Si la règle utilise une logique AND, toutes les conditions doivent être réunies. Si elle utilise une logique OR, n’importe quelle condition satisfaisante suffit.

3. La première règle qui correspond détermine le résultat. Huwise cesse l’évaluation et applique immédiatement l’action de cette règle.

4. Si aucune règle ne correspond, la règle générale s’applique. La règle générale est une action par défaut qui couvre tous les utilisateurs qui ne correspondent à aucune règle spécifique.

Il existe trois résultats possibles :

Considérez cela comme un videur qui vérifie une liste d’invités : chaque règle est vérifiée dans l’ordre, et la première correspondance décide si la personne peut entrer, se voit refuser l’entrée, ou doit attendre l’approbation d’un responsable. Si personne sur la liste ne correspond, la politique générale (la règle catch-all) s’applique.

La règle catch-all est l’action par défaut qui s’applique lorsque aucune de vos règles spécifiques ne correspond aux attributs d’un utilisateur. Elle agit comme un filet de sécurité.

Un motif courant consiste à définir le catch-all sur Rejeter puis à créer des règles spécifiques qui Approuvent les utilisateurs que vous souhaitez laisser passer. Cela garantit que seuls les utilisateurs correspondant à vos critères peuvent accéder à l’espace de travail. Le motif inverse, catch-all défini sur Approuver avec des règles spécifiques Rejeter, fonctionne bien lorsque vous voulez bloquer quelques groupes connus tout en laissant tout le monde passer.

Chaque règle définit un ensemble de conditions et une action à effectuer lorsque ces conditions sont remplies.

1. Cliquez sur Ajouter une règle.

2. Remplissez les détails de la règle.
   
   Description (optionnel) : Une note lisible pour expliquer le but de cette règle (par exemple, « Autoriser les membres de l’équipe data » ou « Bloquer les sous-traitants externes »).

   Action: Sélectionnez Approuver, Rejeter, ou Demander l’approbation.

   Logique des conditions: Choisissez comment combiner plusieurs conditions :

   • AND: Toutes les conditions doivent être réunies pour déclencher la règle.

   • OR: N’importe quelle condition satisfaisante suffit à déclencher la règle.

3. Ajoutez une ou plusieurs conditions (voir la section suivante).

4. Cliquez sur Enregistrer.

Chaque règle doit comporter au moins une condition. Une règle sans conditions ne peut correspondre à personne et n’a aucun effet.

Notez que les priorités doivent être uniques pour l’ensemble des règles du même fournisseur d’identité. Les numéros de priorité les plus bas sont évalués en premier. Vous pouvez réorganiser les règles pour ajuster leur priorité.

Chaque règle a un bascule active. Lorsqu’une règle est inactive, Huwise l’ignore lors de l’évaluation — comme si la règle n’existait pas. Cela vous permet de désactiver temporairement une règle sans la supprimer.

Comme les règles sont évaluées par ordre de priorité (numéro le plus bas en premier), l’ordre compte. Une règle de priorité 1 est vérifiée avant une règle de priorité 2. La première règle qui correspond gagne, et toutes les règles suivantes sont ignorées.

Pour changer l’ordre d’évaluation, ajustez les numéros de priorité de vos règles. Chaque priorité doit être unique pour l’ensemble des règles du même fournisseur d’identité.

Notez que l’enregistrement applique toutes vos modifications en une fois. Huwise remplace toutes les règles existantes par l’état actuel du formulaire. Vérifiez toutes les règles et leurs priorités avant d’enregistrer.

Votre espace de travail peut avoir des limites quant au nombre maximal de règles par fournisseur d’identité (10) et au nombre maximal de conditions par règle (5). Si vous atteignez une limite, vous verrez une erreur lors de l’enregistrement.

Chaque condition vérifie un seul attribut d’identité par rapport à une valeur ou à une liste de valeurs. Une condition comporte trois parties :

• Attribut: Le nom de l’attribut d’identité à vérifier. Il doit correspondre exactement au nom de l’attribut tel qu’envoyé par le fournisseur d’identité.

  • Pour les fournisseurs OIDC : utilisez des noms de claims tels que email, groups, role, ou department.

  • Pour les fournisseurs SAML : utilisez des noms d’attribut d’assertion tels que mail, memberOf, ou des noms basés sur l’OID comme urn:oid:2.5.4.10.

  • Pour les attributs imbriqués, vous pouvez utiliser une notation de chemin (par exemple, address.country pour accéder au champ country à l’intérieur d’un objet address).

• Opérateur: Comment comparer l’attribut à la valeur. Consultez le tableau de référence complet ci-dessous.

• Valeur — Ce à quoi comparer. Selon l’opérateur, il s’agit soit de :

  • Une valeur texte (pour est égale à / n’est pas égale à)

  • Une liste d’accès (pour est dans la liste / n’est pas dans la liste / est l’un des)

  • Rien (pour est présent / n’est pas présent)

Les noms d’attributs sont sensibles à la casse. Si votre fournisseur d’identité envoie Department (avec majuscule) mais que vous entrez department (minuscules), la condition ne correspondra pas. Consultez la documentation de votre fournisseur ou testez d’abord avec l’opérateur is present pour confirmer que le nom de l’attribut est correct.

Certains attributs d’identité peuvent contenir plusieurs valeurs. Par exemple, une réclamation groups peut contenir [\"engineering\", \"data-team\", \"all-staff\"]. L’opérateur choisi détermine comment Huwise gère ces listes :

• is in list vérifie si toute la valeur de l’attribut (en tant que chaîne unique) apparaît dans la liste d’accès. C’est idéal pour les attributs à valeur unique, comme email ou department.

• is any of vérifie si au moins un élément d’un attribut multi-valeur apparaît dans la liste d’accès. C’est le bon choix pour les attributs comme groups, roles, ou toute réclamation qui retourne un tableau de valeurs.

Utiliser des listes d’accès dans les conditions

Trois des sept opérateurs (is in list, is not in list, et is any of) comparent l’attribut de l’utilisateur à une liste d’accès plutôt qu’à une seule valeur texte. Les listes d’accès sont des collections de valeurs gérées séparément. Par exemple, vous pouvez créer une liste d’accès de numéros SIRET autorisés ou de codes de département approuvés.

Vous devez créer des listes d’accès avant de pouvoir les référencer dans les conditions. Voir cet article pour plus d’informations.

L’action déclenchée par une règle qui correspond (ou par la catch-all) influence directement ce que voit l’utilisateur après s’être connecté via le fournisseur d’identité.

L’utilisateur est connecté à l’espace de travail normalement. Il ne voit aucun écran ou message supplémentaire, le flux de connexion se poursuit comme si aucune règle d’accès n’existait.

L’utilisateur voit une page d’accès refusé après s’être authentifié auprès de son fournisseur d’identité. La page indique qu’il n’a pas la permission d’accéder à l’espace de travail. Il ne peut pas continuer.

Lorsque l’approbation est requise

L’utilisateur voit une page « approbation en attente » indiquant que sa demande d’accès a été soumise. Une notification est envoyée aux administrateurs du portail de l’espace de travail. L’utilisateur ne peut pas accéder à l’espace de travail tant qu’un administrateur du portail n’a pas approuvé sa demande.

Une fois qu’un administrateur du portail approuve la demande, l’utilisateur peut se connecter normalement lors de sa prochaine tentative.