Meilleures pratiques pour la modélisation des contraintes utilisateur dans une application Web?

StackOverflow https://stackoverflow.com/questions/1623865

Question

Je construis une application Web avec un contrôle d'accès basé sur les rôles utilisant la sécurité Acegi (Spring). J'ai donc différents utilisateurs avec des rôles: ROLE_ADMIN , ROLE_USER , etc.
Cependant, je dois implémenter différentes contraintes utilisateur.

Prenons un exemple:

  

Supposons qu’il existe un site sur lequel les utilisateurs peuvent regarder des films en ligne. Il existe des utilisateurs dotés des rôles ROLE_STANDARD_USER et ROLE_VIP_USER . Les utilisateurs standard peuvent regarder 3 films par semaine et les utilisateurs vip peuvent regarder 10 films par semaine en plus d’autres privilèges. Et il y a un utilisateur du groupe d'utilisateurs standard à qui je veux donner 2 films supplémentaires par semaine. Le nombre de films autorisés peut parfois changer.
  En outre, il existe différentes catégories de films: fantastique, comédie, classique, nouveaux films, etc. Et je souhaite que certains utilisateurs, quel que soit leur rôle, n’ont accès qu’à certaines catégories. Les catégories peuvent être créées et supprimées dynamiquement.

Existe-t-il des pratiques standard pour la mise en œuvre de ce type de contraintes utilisateur?
Peut-on / devrait-il le faire en utilisant les rôles et les autorisations Spring Security?
Ou dois-je envisager d’ajouter un moteur basé sur des règles à mon application?

Merci.

Modifier:
L'exemple ci-dessus est fictif, mon projet concerne l'octroi d'un accès à distance à divers équipements de réseau (et autres) pour les étudiants. Cependant, les types de contraintes utilisateur seront probablement les mêmes.
Malheureusement, le modèle d'accès utilisateur & amp; les contraintes ne sont pas complètes et stables. Dans un proche avenir, on pourrait me demander d'implémenter diverses contraintes supplémentaires pour les utilisateurs, qui ne sont pas connues à présent.
Je voudrais donc maintenant choisir un chemin qui facilitera l’ajout ou la modification de nouvelles contraintes d’usager à l’avenir et ne nécessitera pas de refonte importante de la structure interne du modèle ou de la base de données. Si cela est possible.

Modifier 2

Actuellement, les contraintes utilisateur de base sont codées en dur (restes du système de prototypage). J'imagine que je vais d'abord essayer de le transformer en une sorte d'objet de services métier paramétré, puis de penser où je peux aller à partir de là. Je vais également envisager d’utiliser des gestionnaires de décision d’autorisation de sécurité Spring.

Merci pour toutes vos suggestions!

Était-ce utile?

La solution

Je ne m'attendrais pas à ce qu'un système de sécurité déclaratif basé sur des rôles donne le contrôle fin que vous recherchez. Vous avez déjà décrit plusieurs "règles métier". contrôles d’accès que vous souhaitez mettre en œuvre et on peut s’attendre avec le temps que ces règles deviennent plus complexes. Vous avez donc besoin d’une combinaison d’informations du sous-système de sécurité (qui est l’utilisateur de cette requête? Quels sont leurs rôles?), Mais vous la combinez ensuite par programme avec les données et les règles de l’entreprise (cet utilisateur a droit à 2 films gratuits si la date du jour est différente) est dans cette gamme).

A tout le moins, je définirais les services dans lesquels j'encapsule cette logique métier. La décision d'utiliser ou non un moteur de règles à part entière devra être étudiée plus avant.

Autres conseils

Avant de vous poser la question, Acegi (ou un moteur de règles, etc.) est le bon endroit pour le faire, je pense que vous devez le faire
analysez vos besoins avec précision et de manière exhaustive .

En tenant compte de chaque sujet ( par exemple, les limites du film pouvant être vues ), il existe un très grand nombre de moyens de le mettre en œuvre et vous devez faire des choix fonctionnels. Il ne peut y avoir d’implémentation correcte à moins que vous n’ayez déjà décidé en détail ce qui doit être fait!

Exemple de modèle adapté à vos besoins:

  • Limitez le nombre de films généraux par semaine en fonction de la somme de :
    • rôle (3 ou 10)
    • bonus par utilisateur (0 par défaut si non mentionné)
  • Mettez à jour ces chiffres si nécessaire
  • Limitez les films à une liste de catégories:
    • si une liste est spécifiée pour l'utilisateur, utilisez-la
    • sinon, utilisez la liste fournie pour le rôle

Cet exemple a de nombreuses implications, qui peuvent être correctes ou inacceptables dans votre cas.
Implications:

  • après la mise à jour d'un nombre, la limite est immédiatement modifiée.
  • il n'y a pas de mémoire des limites hebdomadaires, vous ne pouvez pas demander cela pour le passé (pour faire des statistiques par exemple)
  • ...

Si ce modèle ne répond pas à vos besoins, vous devez créer un modèle qui leur convient vraiment. Une fois que vous l’avez, pensez à la mise en œuvre.

Si vous envisagez Spring Security, c’est un moyen, à mon avis, de mettre en œuvre votre solution. Implémentez un AccessDecisionVoter pour décider de l'accès de l'utilisateur. Consultez la source de référence ici

Consultez également le [javadoc] [2] pour AccessDecisionVoter . Vous pouvez implémenter vos règles en implémentant la méthode vote . 

int vote(Authentication authentication,
         Object object,
         ConfigAttributeDefinition config)

Laissez Spring gérer l’accès (authentification et autorisation). Si la prise de décision devient compliquée, utilisez un moteur de règles. Laissez la méthode de vote appeler un moteur de règles. Cela permet une séparation claire des tâches. Laissez Spring Security gérer l'accès et laissez le moteur de règles calculer les règles.

[2]: http://static.springsource.org/spring-security/site/apidocs/org/springframework/security/vote/AccessDecisionVoter.html#vote (org.springframework.security.Authentication , java.lang.Object, org.springframework.security.ConfigAttributeDefinition)

On dirait que vous avez des besoins en matière d’authentification et d’authentification - très souvent, les personnes sont confondues et / ou jointes. Heureusement, Spring Security dessine très bien les deux. Votre utilisateur s'authentifiera par le biais de la chaîne de sécurité (qu'il s'agisse de logj, openID, SSL X509) et sera ensuite autorisé à être autorisé par les votants spécifiques de votre entreprise (dans vos AccessDecisionManagers) à déterminer s'ils ont déjà vu le numéro qui leur a été attribué. de films. Si une nouvelle logique métier doit être ajoutée ultérieurement, il vous suffit d'écrire de nouveaux électeurs / plus d'électeurs et de les injecter dans votre responsable.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top