Vue d’ensemble de l’authentification et de l’autorisation
Traduction
Cette page est une traduction de la version anglaise, qui fait foi.
Ce document fournit une vue d’ensemble des principes d’authentification et d’autorisation dans Balyze.
Il évite volontairement les détails d’implémentation et se concentre sur les périmètres de sécurité et les responsabilités associées.
Authentification
Balyze utilise un mécanisme d’authentification standard par email et mot de passe.
Au stade ALPHA actuel :
- l’authentification est requise pour toute interaction avec le domaine
- chaque utilisateur opère dans un périmètre de données strictement isolé
- les préoccupations liées à l’authentification sont traitées indépendamment des règles métier
L’identité de l’utilisateur est établie avant toute logique métier ou règle d’autorisation.
Principes d’autorisation
L’autorisation dans Balyze repose sur une séparation claire des responsabilités :
- l’authentification confirme l’identité de l’utilisateur
- l’autorisation définit ce que l’utilisateur est autorisé à consulter ou modifier
Les règles d’autorisation sont appliquées de manière explicite et cohérente.
Accès basé sur la propriété
Toutes les entités métier appartiennent à un utilisateur.
De manière générale :
- un utilisateur ne peut accéder qu’à ses propres données
- la propriété est appliquée via des policies
- les règles de propriété sont indépendantes de la logique métier
Ce modèle empêche par défaut toute fuite de données entre utilisateurs.
Rôles et accès étendus
Balyze prend en charge un contrôle d’accès basé sur les rôles.
À ce stade :
- les utilisateurs standards agissent en tant que candidats
- un accès administrateur existe à des fins de maintenance et de supervision
- les administrateurs peuvent contourner les contraintes de propriété lorsque nécessaire
Les accès étendus sont explicites et volontairement limités.
Stratégie d’application des règles
Les règles de sécurité sont appliquées à plusieurs niveaux :
- les middlewares garantissent l’accès authentifié
- les policies appliquent la propriété et les permissions
- les services métier appliquent les règles métier
Les préoccupations de sécurité ne sont pas intégrées directement dans la logique du domaine.
Éléments hors périmètre
Les aspects suivants sont volontairement reportés :
- workflows de vérification d’email
- granularité avancée des permissions
- fournisseurs d’identité externes
- journalisation et analytics de sécurité
Ces sujets seront réévalués au fur et à mesure de la maturation du produit.
Principes directeurs
- refus par défaut
- règles d’accès explicites
- aucune confiance implicite entre les couches
- la clarté avant la flexibilité