Modèle d’organisation

Le modèle d’organisation dans Logto définit un ensemble cohérent de rôles et de permissions disponibles pour chaque organisation (locataire) dans votre produit SaaS. En centralisant ces définitions, vous pouvez renforcer la sécurité, permettre un onboarding évolutif et garantir une excellente expérience utilisateur dans toutes les organisations.

info:

Si vous ne développez pas une application multi-locataire ou n’avez pas besoin de rôles / permissions spécifiques à l’organisation, vous pouvez passer cette section. Les rôles et permissions globaux de Logto sont suffisants pour les applications mono-locataire ou non basées sur les organisations.

Qu’est-ce que le modèle d’organisation ?

Un modèle d’organisation est un plan qui spécifie quels rôles et permissions sont disponibles dans chaque organisation. Chaque organisation créée dans votre locataire Logto hérite automatiquement du modèle, garantissant un modèle d’autorisation cohérent dans tous les locataires.

• Pourquoi utiliser un modèle ?
  • Applique des politiques de contrôle d’accès uniformes pour chaque organisation.
  • Simplifie l’onboarding des nouveaux locataires et membres d’équipe.
  • Facilite les mises à jour et audits du contrôle d’accès basé sur les rôles (RBAC) à mesure que votre produit évolue.

Concepts clés

• Rôles d’organisation : Collections de permissions accordées aux utilisateurs ou clients M2M (machine à machine) au sein d’une organisation. Les rôles définissent « qui peut faire quoi » dans chaque organisation.
• Permissions d’organisation : Actions non-API granulaires (ex : fonctionnalités UI, logique métier) pouvant être attribuées à des rôles.
• Ressources API : Points de terminaison / services API protégés par des permissions. Les rôles d’organisation peuvent être liés à des ressources API pour un accès API à l’échelle de l’organisation.
• Mappage rôle-permission : Chaque rôle d’organisation dans le modèle peut être associé à une ou plusieurs permissions.
• Propagation du modèle : Les modifications du modèle mettent à jour les rôles et permissions disponibles dans toutes les organisations.

remarque:

Les rôles et permissions d’organisation (y compris les permissions de ressources API) sont distincts des rôles globaux et de leurs permissions. Cependant, les ressources API et leurs permissions sont définies de manière centrale et peuvent être référencées à la fois dans les contextes globaux et organisationnels.

Comparaison avec les rôles et permissions globaux

Comparaison des types de rôles

Type de rôle	Peut avoir des permissions de ressource API ?	Peut avoir des permissions d’organisation (non-API) ?
Global	Oui	Non
Organisation	Oui	Oui

Comparaison des types de permissions

Type de permission	Définie dans	Attribuable aux rôles globaux ?	Attribuable aux rôles d’organisation ?
Ressource API	Entité ressource API	Oui	Oui
Organisation	Modèle d’organisation	Non	Oui

Anatomie d’un modèle d’organisation

Un modèle d’organisation est composé de :

• Rôles : Ex : Admin, Membre, Lecteur, Facturation
• Permissions d’organisation : Ex : invite:member, manage:billing, view:analytics
• Matrice rôle-permission : Un mappage des permissions (y compris permissions d’organisation et permissions de ressources API) accordées par chaque rôle.

Aperçu visuel

Ce schéma illustre comment les rôles d’organisation, les permissions et les ressources API sont connectés dans un modèle d’organisation Logto.

Chaque organisation créée dans Logto disposera de ce même ensemble de rôles et de permissions, et les utilisateurs / clients peuvent se voir attribuer des rôles par organisation selon les besoins.

Utiliser le modèle d’organisation dans votre produit

Le modèle d’organisation de Logto est conçu pour les applications SaaS modernes et multi-locataires où :

• Chaque organisation doit disposer des mêmes options de rôles et de permissions pour l’onboarding, la collaboration et la gestion.
• Vous souhaitez éviter de définir manuellement les rôles / permissions pour chaque nouvelle organisation.
• Un RBAC cohérent est essentiel pour la conformité, la sécurité et la confiance des clients.
• Vous devez faire évoluer le contrôle d’accès à mesure que votre produit change, sans perturber les organisations existantes.

Exemples d’utilisation

• Produits SaaS proposant des espaces de travail, équipes ou entreprises (chacun étant un locataire).
• Plateformes avec des rôles admin / membre / lecteur granulaires par organisation.
• Produits avec des permissions API et non-API.

Bonnes pratiques & gestion des versions

• Gardez les rôles et permissions orientés métier : Utilisez des noms clairs correspondant à des actions réelles (pas seulement des points de terminaison techniques).
• Évitez la prolifération des rôles / permissions : Commencez simplement ; ajoutez de nouveaux rôles / permissions uniquement lorsque votre produit en a réellement besoin.
• Communiquez les changements : Informez les utilisateurs / administrateurs si les options de rôles ou de permissions dans leurs organisations vont changer.
• Faites évoluer le modèle : À mesure que votre produit évolue, vous pouvez mettre à jour le modèle à tout moment. Toutes les organisations auront automatiquement accès aux nouveaux rôles / permissions.
• Gestion des versions (optionnel) : Pour les changements majeurs, envisagez de versionner votre modèle et de communiquer les plans de migration à vos clients.

Gérer votre modèle d’organisation

Vous pouvez gérer le modèle d’organisation depuis le Console → Modèle d’organisation ou via le Management API de Logto.

• Créer des rôles : Ajoutez des rôles utilisateur et des rôles M2M à votre modèle. Chaque rôle est disponible pour toutes les organisations de votre locataire Logto.
• Créer des permissions : Définissez des permissions pour les ressources API et pour les actions non-API (dans l’application).
• Modifier la matrice rôle-permission : Attribuez des permissions aux rôles via la Console Logto ou le Management API.
• Mettre à jour ou supprimer des rôles / permissions : Les modifications du modèle sont automatiquement appliquées à toutes les organisations. (Les utilisateurs / clients conservent leurs attributions de rôles ; seul l’ensemble des permissions change.)

Pour des guides pas à pas sur la gestion des rôles et permissions d’organisation, voir Contrôle d’accès basé sur les rôles.

FAQ

Dois-je utiliser les permissions d’organisation ?

Non, les permissions d’organisation sont optionnelles. Vous pouvez utiliser le modèle d’organisation uniquement pour définir des rôles et des permissions de ressources API si vous le souhaitez.

Que se passe-t-il si je modifie le modèle d’organisation ?

Les modifications des rôles ou des permissions sont immédiatement répercutées dans toutes les organisations. Les utilisateurs et clients conservent leurs attributions de rôles ; seuls les droits associés à ces rôles peuvent changer.

Puis-je personnaliser les rôles ou permissions par organisation ?

Pas directement. Les modèles d’organisation imposent un modèle cohérent dans tous les locataires. (Vous pouvez toujours attribuer des rôles différents à des utilisateurs / clients différents dans chaque organisation.)

Comment annuler ou migrer des changements ?

Mettez à jour manuellement le modèle pour restaurer les anciens rôles / permissions. Pour des migrations complexes, envisagez des stratégies de gestion des versions.

Que se passe-t-il si je supprime un rôle ou une permission ?

Les utilisateurs / clients avec ce rôle perdent l’accès aux permissions qui y étaient liées. La suppression d’une permission la retire de tous les rôles qui l’avaient.

Y a-t-il des limitations ?

La personnalisation se fait au niveau du modèle, pas par organisation. Contactez-nous si vous avez besoin d’exceptions avancées par locataire.

Pour aller plus loin

Protéger les permissions d’organisation (non-API)

Protéger les ressources API au niveau organisation

Personnalisation des revendications de jeton