Applications Web et logiciels
Créez un modèle d’accès qui précise qui peut consulter un dossier, quelles actions sont permises et comment chaque changement d’état s’effectue.
Comment le flux de travail s’articule
Une exigence comme « les administrateurs peuvent gérer les demandes » laisse plusieurs questions importantes sans réponse. Quelles requêtes peuvent-ils voir? Peuvent-ils modifier les informations soumises? Peut-on approuver leur propre travail? Que se passe-t-il après la fermeture de la demande? Une matrice d'autorisation liée aux transitions d'état répond à ces questions avant que le comportement du code et de l'interface ne diverge.
Utilisez des lignes pour des actions telles que la vue, créer, attribuer, modifier, approuver, exporter et supprimer. Utilisez des colonnes pour les rôles ou les relations d'enregistrement comme le demandeur, l'opérateur assigné, le gestionnaire et le vérificateur. Ajouter des conditions où l'accès dépend de la responsabilité, du département, du compte ou de l'état.
Ce format expose les conflits. Par exemple, un gestionnaire peut approuver des dossiers du ministère, mais pas une demande qu'il a présentée lui-même.
Une action peut être valide dans un état et invalide dans un autre. Un demandeur peut modifier un avant-projet mais seulement des commentaires après la soumission. L'exploitant ne peut clore une demande qu'après la présence des champs d'achèvement requis. Chaque transition doit nommer l'état actuel, l'action, l'état de l'acteur, les données requises et l'état résultant.
Cacher un bouton améliore la convivialité mais n'empêche pas une requête directe API. Le serveur doit évaluer l'identité, la relation, l'état d'enregistrement actuel et l'action demandée. Les tâches en arrière-plan et les intégrations ont besoin de leur propre identité et de permissions étroitement ciblées.
Testez l'accès au compte croisé, l'état du navigateur, la réaffectation, les archives, les données exportées et les utilisateurs révoqués. Inclure les tentatives qui devraient échouer et confirmer que le refus ne divulgue pas de détails sensibles. Les tests de permission sont plus utiles lorsqu'ils suivent les mêmes flux de travail que les tests d'acceptation normaux.
Supposons qu'un portail ait des clients, du personnel de service, des gestionnaires et des utilisateurs financiers. Une règle basée sur la page comme les gestionnaires peuvent accéder aux factures n'est pas assez précise. Les actions importantes sont le résumé de la facture, le détail de la facture ouverte, le téléchargement d'un document, l'enregistrement d'un état de paiement, l'émission d'un ajustement et les données financières d'exportation. Chaque action peut avoir une portée et une condition différentes.
Écrire les permissions en utilisant l'acteur, l'action, la portée des enregistrements, l'état et les restrictions de champ. Un employé de service peut consulter les factures pour les comptes attribués mais ne pas les exporter. Un client peut télécharger sa propre facture émise mais ne peut pas voir les notes internes. Un utilisateur financier ne peut corriger l'état de paiement que lorsque l'enregistrement n'est pas verrouillé par rapprochement.
| Rôle | Décision | Portée des enregistrements | État ou état du champ |
|---|---|---|---|
| Client | Afficher et télécharger la facture | Compte propre | Champs clients émis uniquement |
| Personnel des services | Consulter l'état de la facture | Comptes attribués | Pas d'exportation financière |
| Gestionnaire | Approuver le réglage | Comptes du Département | En attente d'approbation seulement |
| Financement | État de paiement correct | Tous les comptes autorisés | Non verrouillé par rapprochement |
Cacher un bouton est un guide d'interface utile, mais ce n'est pas une autorisation. Chaque action API ou serveur doit vérifier l'identité, le rôle ou la politique en cours, la portée des enregistrements et l'état actuel. Vérifiez à nouveau ces faits lorsque l'action se produit parce qu'un autre utilisateur peut avoir changé l'enregistrement après le chargement de la page.
Consigner les décisions corrélatives telles que l'approbation, l'octroi de l'accès, l'exportation, la réaffectation et le remplacement avec l'acteur, le temps, la version de l'enregistrement et la raison pertinente. Testez l'accès à un compte croisé, les identifiants devinés, les pages en panne, les rôles supprimés, les actions en vrac et les appels directs API. Les tests d'autorisation devraient prouver à la fois que le travail autorisé réussit et que les cas quasi manquants échouent sans révéler d'informations protégées.
Repère visuel
Un contrôle visible n'est que le premier calque; le serveur doit autoriser l'action courante contre l'enregistrement courant.
Orientation de l'interface
Afficher les actions que la personne peut raisonnablement utiliser et expliquer les états non disponibles.
Identité authentifiée
Déterminer qui fait la demande et si la session demeure valide.
Rôle ou politique
Vérifiez l'action autorisée, pas seulement l'accès à la page.
Portée des enregistrements
Confirmer les limites de locataire, de compte, de cession ou de responsabilité.
État actuel
Rejeter les actes inexistants qui ne s'appliquent plus au dossier.
Preuves de vérification
Conservez l'acteur, la décision, la version, le temps et la raison au besoin.
Questions pratiques
C'est une base utile, mais de nombreuses applications ont également besoin de responsabilité, de compte, de service ou de conditions d'état. Ces relations peuvent s'exprimer parallèlement aux rôles.
Les dénis sensibles à la sécurité ou inhabituels sont précieux à enregistrer. Les dénis attendus à volume élevé peuvent nécessiter un échantillonnage ou une surveillance structurée afin que les registres demeurent utiles et que les règles de protection des renseignements personnels soient respectées.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster construit des applications Web personnalisées avec un accès renforcé par le serveur, des règles de flux de travail et des interfaces spécifiques au rôle.
