Aller au contenu principal

Configurer le modèle d'organisation

Nous allons passer en revue le processus de configuration de la fonctionnalité de modèle d'organisation via Logto Console

Tout d'abord, accédez à Console > Modèle d'organisation. Vous verrez que le modèle d'organisation comprend deux parties : Rôles d’organisation et Permissions d’organisation. Un modèle d'organisation définit des politiques de contrôle d'accès partagées (permissions et rôles) pour plusieurs organisations.

Configurer via Logto Console

Créer une permission d’organisation

Les Permissions d’organisation sont une partie clé du modèle d'organisation. Ces permissions sont conçues spécifiquement pour les organisations au sein de votre produit. Voici comment les gérer :

  • Trouver l'onglet des permissions d’organisation : Allez à l'onglet "Permissions d’organisation" pour voir vos permissions existantes.
  • Ajouter, supprimer et modifier : Vous pouvez facilement ajouter de nouvelles permissions d’organisation, supprimer celles dont vous n'avez pas besoin et modifier les permissions existantes selon vos besoins.

Créer un rôle d’organisation

Logto prend en charge deux types de Rôles d’organisation, c'est la même chose que le RBAC au niveau utilisateur/système :

  • Utilisateur : Rôles qui sont attribués aux utilisateurs.
  • Machine à machine : Rôles qui sont attribués aux applications machine à machine.

Logto vous permet de définir des rôles d’organisation de diverses manières pour s'adapter à la structure de votre système :

Rôles d’organisation uniquement avec permissions d’organisation

  • Quand l'utiliser : Vous avez des points de terminaison utilisateur/système séparés et des points de terminaison d’organisation.
  • Explication : C'est l'approche la plus simple si l'architecture technique de votre produit et la conception de l'API séparent clairement les ressources au niveau utilisateur/système des ressources d’organisation. Vos rôles d’organisation n'incluront que les permissions que vous définissez pour l’organisation.

Rôles d’organisation uniquement avec permissions API

  • Quand l'utiliser : Le contrôle d'accès au niveau utilisateur/système et au niveau organisationnel est géré par les mêmes points de terminaison.
  • Explication : Choisissez ceci si vous souhaitez gérer toutes les permissions via des ressources API unifiées.

Permissions API mixtes et permissions d’organisation dans les rôles d’organisation

  • Quand l'utiliser : Vous avez des points de terminaison séparés définis pour votre produit pour le niveau utilisateur/système et le niveau organisationnel, mais certains rôles d'utilisateur nécessitent un mélange de permissions au niveau utilisateur et au niveau organisationnel.
  • Explication : Cela offre le plus de flexibilité, mais peut aussi être le plus complexe à gérer.

Configurer via Logto Management API

Tout ce que vous pouvez faire dans Console peut également être fait via Management API, y compris : Gérer le modèle d'organisation pour créer, supprimer ou modifier les permissions et rôles d’organisation.

Pour une liste complète des capacités, veuillez vous référer à notre référence API

Avec Logto Management API, vous pouvez créer des expériences d’organisation personnalisées, comme permettre aux administrateurs d’organisation de s'auto-servir et de créer des organisations. Consultez cette section pour activer plus de fonctionnalités et de gestion au niveau organisationnel.

Gérer le changement de permission des membres

Similaire à API RBAC, les permissions des membres peuvent être modifiées pendant une session -- par exemple, ils peuvent se voir attribuer de nouveaux rôles ou voir les permissions de rôle existantes modifiées.

Que se passe-t-il lorsqu'un changement de permission des membres se produit ? Il y a deux cas.

Aucune nouvelle permission introduite dans le système

Les jetons d’accès d’organisation actuels (alias jeton d’organisation) resteront valides jusqu'à leur expiration, même après que les permissions d’organisation d'un utilisateur aient été modifiées. Cependant, les nouvelles permissions seront reflétées dans les jetons d’organisation ultérieurs, et toutes les permissions révoquées seront omises.

remarque

Les jetons d’organisation ont un temps d'expiration fixe qui ne peut pas être modifié, contrairement aux jetons d’accès génériques.

Appelez périodiquement les points de terminaison Logto Management API ou établissez une connexion de longue durée (par exemple en utilisant WebSocket) pour récupérer dynamiquement les permissions d’organisation de l'utilisateur. Lors de la détection de changements, effacez le jeton d’organisation existant et les nouveaux jetons émis refléteront automatiquement les changements de portée de permission d’organisation.

curl \
-X GET https://[tenant_id].logto.app/api/organizations/{id}/users/{userId}/scopes \
-H "Authorization: Bearer $ORGANIZATION_TOKEN"

Lorsque des changements de permission sont détectés, effacez d'abord le jeton d’organisation du stockage, puis appelez la méthode SDK getOrganizationToken(organizationId) pour en acquérir un nouveau. Le nouveau jeton d’organisation émis devrait refléter les changements de permission.

Nouvelle permission introduite dans le système et attribuée à un membre

Cela se produit lorsque de nouvelles permissions sont introduites dans votre modèle d'organisation. Dans ce cas, vous devrez d'abord inclure les nouvelles portées de permission introduites lors de l'initialisation du client Logto. Par exemple :

new LogtoClient({
appId: 'your-app-id',
redirectUrl: 'your-redirect-url',
scopes: [
'urn:logto:scope:organizations',
// ... vos autres portées de permission d’organisation existantes,
'new-organization-permission-scope',
],
});

Deuxièmement, chacune de vos applications clientes doit redemander le consentement ou reconnecter les utilisateurs afin de recevoir le changement de permission. Ensuite, la nouvelle portée de permission sera reflétée dans les nouveaux jetons d’organisation.

Exemple de code pour redemander le consentement :

signIn({ redirectUrl: 'your-redirect-url', prompt: 'consent' });