Portail client : définir et tester les droits d’accès

Définissez les droits d’un portail client : séparation des entreprises, accès aux documents, invitations et tests pour limiter les erreurs de partage.

Un client consulte une facture dans son espace. Un autre collaborateur de la même société doit pouvoir la télécharger, mais ne doit pas inviter de nouveaux utilisateurs. Le chargé de compte peut suivre les dossiers des clients qui lui sont affectés. Ces différences doivent apparaître dans les règles du portail avant son ouverture.

Pour une PME, une matrice d’accès courte et compréhensible permet de faire valider ces règles par les personnes concernées. Elle sert ensuite à construire les contrôles et les tests, puis à expliquer les droits accordés au support.

Distinguer l’identité, le rôle et le périmètre

La connexion établit qui utilise le portail. L’autorisation détermine ce que cette personne peut faire sur une ressource donnée. Un utilisateur correctement connecté peut donc recevoir un refus lorsqu’il demande le document d’une autre entreprise.

Le rôle décrit un ensemble d’actions, comme consulter les factures ou administrer les membres. Le périmètre précise les entreprises, agences ou dossiers sur lesquels ces actions sont permises. Un même rôle peut s’appliquer à des périmètres différents.

Prenons un exemple fictif : une société possède deux agences, chacune avec son responsable. La direction souhaite voir les factures des deux agences, tandis que chaque responsable ne voit que les siennes. Un rôle « responsable » sans rattachement à l’agence laisserait cette règle incomplète.

Construire une matrice qui tient compte des documents

Inventoriez les ressources réellement partagées : demandes, factures, pièces jointes et coordonnées. Définissez les actions sur chacune. Le droit de consulter un dossier n’implique pas forcément celui de voir une note interne ou de supprimer un document.

Ce tableau demande des précisions opérationnelles. Qui attribue un chargé de compte ? Que se passe-t-il lorsqu’il change d’équipe ? L’assistance peut-elle accéder temporairement à un dossier pour résoudre un incident ? Notez le responsable de chaque attribution et la durée des accès exceptionnels.

Les recommandations d’OWASP sur l’autorisation prévoient notamment un refus par défaut et une vérification des permissions à chaque requête. Le développeur doit donc appliquer les règles côté serveur, y compris quand l’interface masque déjà le bouton correspondant.

Protéger les accès directs aux fichiers

Un document peut être accessible depuis plusieurs endroits : une liste, un email de notification ou une URL copiée. Vérifiez chacun de ces chemins. Le portail ne doit pas considérer qu’une personne est autorisée simplement parce qu’elle possède l’adresse du fichier.

Si le système utilise des liens temporaires, précisez leur durée et leurs possibilités de partage. Une URL signée peut rester utilisable jusqu’à son expiration selon l’architecture retenue. La suppression d’un utilisateur dans le portail ne garantit donc pas, à elle seule, que tous les liens déjà émis cessent de fonctionner immédiatement.

Examinez aussi les exports. Un écran correctement filtré peut encore être accompagné d’un export trop large. Le fichier produit, les pièces jointes et la recherche doivent respecter le même périmètre métier que la consultation ordinaire.

Encadrer les invitations et les changements d’entreprise

Une invitation doit correspondre à une entreprise précise et à un rôle autorisé. Définissez qui peut l’envoyer, quand elle expire et ce qui arrive si elle a déjà été utilisée. Une adresse email partagée entre plusieurs collaborateurs complique l’identification des actions ; privilégiez des comptes individuels lorsque le suivi exige de savoir qui a agi.

Prévoyez le départ d’un utilisateur dès la conception. L’administrateur doit pouvoir retirer son rattachement sans effacer l’historique métier de ses actions. La désactivation doit aussi être prise en compte par les sessions déjà ouvertes selon le mécanisme de contrôle choisi.

Un utilisateur peut travailler pour plusieurs entités. Dans ce cas, affichez clairement le contexte actif et vérifiez l’entreprise associée à chaque opération. Le changement de contexte ne doit pas réutiliser par erreur les données précédemment affichées ou un formulaire destiné à un autre client.

Tester les refus avec deux entreprises distinctes

Préparez deux sociétés fictives et plusieurs profils. Exécutez les opérations permises, puis tentez les opérations interdites en utilisant les mêmes chemins techniques. Modifier l’identifiant d’un dossier dans une requête est un cas de test utile, même si l’interface ne permet pas de sélectionner ce dossier.

Vérifiez notamment ces situations : un lecteur tente d’inviter quelqu’un ; un utilisateur demande le fichier d’une autre société ; un ancien membre conserve un onglet ouvert ; un export est lancé après un changement de rôle. Pour chaque refus attendu, confirmez qu’aucune donnée interdite n’apparaît et qu’aucune modification n’est réalisée.

Ces cas doivent rejoindre les critères d’acceptation du logiciel. Répétez-les lors d’une évolution des rôles ou de l’ajout d’un nouveau type de document. Les droits d’un portail ne se vérifient pas uniquement au premier lancement.

Donner au support des moyens adaptés

Le support a besoin d’expliquer un refus sans obtenir systématiquement des droits d’administrateur. Un journal peut indiquer l’utilisateur concerné, le type d’action et son résultat, avec une conservation définie et un accès restreint. Évitez d’y recopier le contenu des documents ou les secrets de connexion.

Documentez les interventions exceptionnelles et leur retrait. Ajoutez la matrice des droits, les comptes de test et les procédures de désactivation au dossier de transfert pour la maintenance. La prochaine équipe pourra ainsi vérifier les règles existantes avant de modifier le portail.