Structure d’accès

La structure d’accès sert à modéliser un accès hiérarchique dans un environnement pour les utilisateurs internes et les utilisateurs externes.

Une structure d’accès peut représenter des clients, des départements, des responsabilités, des rôles ou des regroupements métier d’accès similaires. Les utilisateurs sont assignés à un nœud de la structure via des adhésions, et l’accès effectif est résolu lors de la connexion.

Structure d’accès et nœuds

Chaque structure d’accès contient une seule hiérarchie de nœuds avec exactement un nœud racine.

Un nœud contient :

  • Un nom
  • Éventuellement des claims décrivant l’accès représenté par le nœud
  • Éventuellement des nœuds enfants en dessous dans la hiérarchie

La hiérarchie peut être utilisée pour modéliser un accès tel que :

  • Client → Département → Rôle
  • Organisation → Équipe → Responsabilité
  • Partenaire → Région → Fonction

Exemple : structure d’accès Acme Corp

L’exemple suivant modélise l’accès pour le client Acme Corp avec un département financier et un rôle d’approbateur :

Acme Corp (customer=acme)
  Finance (department=finance)
    Approver (role=approver)

Dans les paramètres de la structure d’accès, le nœud supérieur est Acme Corp avec le claim customer=acme. Le nœud enfant Finance ajoute le claim department=finance, et le nœud enfant Approver ajoute le claim role=approver.

Paramètres de structure d’accès avec les nœuds Acme Corp, Finance et Approver

Lorsqu’un utilisateur est assigné au nœud Approver via une adhésion, FoxIDs résout la hiérarchie de Approver jusqu’à Acme Corp.

Dans les transformations de claims, les valeurs résolues sont disponibles comme claims d’accès _local:.

Input claims dans une transformation de claims avec les claims locaux de structure d’accès et les claims transmis à l’application

Si Forward access structure claims to applications est activé, les claims d’accès sont également transmis aux transformations de claims et aux applications. Dans ce cas, les claims customer=acme, department=finance et role=approver.

Adhésions

Les utilisateurs sont connectés à une structure d’accès via des adhésions. Un utilisateur peut être connecté à plusieurs structures d’accès via plusieurs adhésions et plusieurs nœuds dans chaque structure.

Une adhésion :

  • S’applique aux utilisateurs internes comme aux utilisateurs externes
  • Référence un nœud dans une structure d’accès
  • Peut éventuellement inclure une date de validité de début et de fin

Les adhésions sont gérées dans le FoxIDs Control Client :

  • Sur la page Internal Users pour les utilisateurs internes
  • Sur la page External Users pour les utilisateurs externes
  • Sur la page Access Structures pour une gestion des adhésions centrée sur l’utilisateur

Accès résolu lors de la connexion

Lors de la connexion, FoxIDs résout les adhésions de l’utilisateur et parcourt la hiérarchie de nœuds depuis le nœud assigné jusqu’au nœud racine.

Le résultat résolu inclut :

  • Les chemins de nœuds effectifs
  • Les claims effectifs issus de la hiérarchie
  • Les claims qualifiés par chemin

Ces valeurs sont mises à disposition avant l’exécution des transformations de claims normales, ce qui signifie qu’elles peuvent être utilisées directement dans les flux existants de transformation de claims et d’autorisation.

Claims locaux

La résolution de structure d’accès émet des types de claims locaux fixes.

Les claims locaux suivants sont disponibles dans les transformations de claims :

  • _local:access_node
  • _local:access_claim
  • _local:access_path_claim

Cela évite les types de claims dynamiques tout en conservant le contexte hiérarchique dans les valeurs des claims.

Transmettre les claims aux applications

Chaque structure d’accès inclut le paramètre Forward access structure claims to applications, activé par défaut.

S’il est activé, les claims d’accès résolus sont transmis aux applications.

S’il est désactivé, l’accès résolu reste disponible localement dans les transformations de claims, mais les claims d’accès résolus ne sont pas transmis aux applications.

Cas d’utilisation typiques

  • Modéliser un accès propre à un client pour les utilisateurs internes et externes
  • Assigner des utilisateurs à des départements et à des rôles via des adhésions
  • Résoudre des responsabilités d’approbateur ou de lecteur à partir d’une hiérarchie
  • Transmettre les claims d’accès résolus aux applications si nécessaire
Votre confidentialité

Votre confidentialité

Nous utilisons des cookies pour améliorer votre expérience sur nos sites. Cliquez sur « Accepter tous les cookies » pour accepter l'utilisation des cookies. Pour refuser les cookies non essentiels, cliquez sur « Cookies nécessaires uniquement ».

Consultez notre politique de confidentialité pour en savoir plus