Je travaille sur une grande application Web Java EE avec fonctionnalité CRM et nous recherchons une approche de sécurité/bibliothèque/solution/n'importe quoi. La sécurité basée sur les rôles de base ne fonctionnera pas puisque le contrôle d'accès doit être basé sur le rôle et la hiérarchie, mais doit être facultativement personnalisable par document. Étant donné que des informations confidentielles et propriétaires seront stockées, il est nécessaire que la sécurité fonctionne correctement.Comment gérer un grand nombre d'autorisations?
Exemple: Pour utiliser magasin, étagère harceleurs stockeurs peuvent créer des rapports que les autres stockeurs peuvent lire que si ils sont dans le même département. Maintenant, leur chef de service peut lire/écrire/mettre à jour/supprimer tous les rapports écrits par les stockeurs et rédiger des rapports que tous les autres directeurs de département peuvent lire mais pas voir les rapports des directeurs de magasin, etc, que les directeurs de district peuvent r/w/u/d etc. Maintenant, les complications: les gens à des niveaux plus élevés peuvent rendre les choses visibles aux personnes à des niveaux inférieurs, soit aux utilisateurs (département écrit des documents à plusieurs stockers spécifiques) aux utilisateurs ou à tout le monde (magasinier écrit un mémo à tout le magasin). permutation que vous pouvez imaginer. En outre, les individus peuvent créer des rapports que leurs pairs ne peuvent pas voir ou ils peuvent choisir d'accorder l'accès pour stocker des stockeurs dans d'autres districts, etc.
Nous envisageons une liste de contrôle d'accès avec une autorisation par entité, mais nous sommes préoccupés par le grand nombre d'enregistrements qui créerait. Même si seulement un rapport était lisible par tout le monde dans un département de 30 et chaque personne au-dessus d'eux [dans la chaîne de commandement], créer un seul rapport nécessiterait ~ 40 enregistrements! Avec 1 rapport par semaine par utilisateur qui est de 2000 autorisations par utilisateur et par an. 1 500 utilisateurs signifient plus de 3 000 000 autorisations par an.
Il semblerait qu'une approche basée sur un moteur de règles serait bien, mais je n'ai vu aucun blog ou article mentionnant cette approche, donc nous hésitons à cette approche. Nous envisageons aussi un hybride ACL/rule home-brass où vous pourriez accorder la permission à un ID de département avec un discriminateur de "manager" ou "stockers" etc pour sous-sélectionner, mais vous êtes inquiet de vérifier toutes les permissions possibles (vous pourriez obtenir la permission spécifique d'un autre utilisateur, vous avez la permission en tant que membre de votre département, vous pourriez avoir la permission en tant que membre d'un magasin, ou d'un district) ressemble à un cauchemar fastidieux sujet aux erreurs.
Quelle est la meilleure approche pour notre application?
printemps ACL est certainement une considération. Cependant, nous aimerions distribuer l'application et nous comprenons que nous devrions alors créer un nouveau contexte de sécurité sur le serveur principal pour chaque appel. Nous ne voulons pas la sécurité sur le front-end afin que nous puissions réutiliser la sécurité pour les frontaux alternatifs (potentiellement une application iPad) par exemple. Cela semble laid et indésirable, mais certainement faisable. – ArtB