MVVM en tête des services Web sensibles aux sinistres

Question

Je suis à la recherche de suggestions pour un défi auquel je suis actuellement confronté.

J'ai construit un STS WIF personnalisé que j'utilise pour identifier les utilisateurs qui veulent appeler certains services WCF que mon système offre. Les services WCF utilisent un gestionnaire d'autorisation personnalisé qui détermine si l'appelant a les revendications requises pour appeler un service donné.

Maintenant, je construis une application WPF. en plus de ces services WCF. J'utilise le modèle MVVM, de sorte que le modèle View appelle les services WCF protégés (qui implémentent le modèle). Le défi que je suis confronté est que je ne sais pas si l'utilisateur actuel peut invoquer avec succès les méthodes de service Web sans réellement les invoquer. Fondamentalement, ce que je veux réaliser est d'activer/désactiver certaines parties de l'interface utilisateur en fonction de la capacité à invoquer une méthode avec succès. La meilleure solution que j'ai trouvée jusqu'ici est de créer un service qui, basé sur la même logique métier que le gestionnaire de règles d'autorisation personnalisé, sera capable de déterminer si un utilisateur peut ou non appeler une méthode donnée. Maintenant, la méthode doit passer à ce service sous forme de chaîne, ou en fait deux chaînes, ServiceAddress et Method (Action), et en fonction de cette entrée, le service sera en mesure de déterminer si l'utilisateur actuel a les revendications requises pour accéder la méthode. Évidemment, pour que cela fonctionne, ce service devrait lui-même exiger un jeton émis du même STS, et avec les mêmes revendications, afin de faire son travail.

Est-ce que l'un d'entre vous a déjà fait quelque chose de similaire ou avez-vous des idées pour le faire?

Merci à l'avance,

Klaus

Answer 1

Cela dépend un peu sur ce que prétend vous besoin dans vos services.

Si vos services nécessitent le même ensemble de revendications, je vous recommande de faire un service qui ne fait rien d'autre que de vérifier les revendications, et d'appeler cela à l'avance. Cela vous permettrait de «préautoriser» l'utilisateur, en activant/désactivant à son tour les parties appropriées de l'interface utilisateur. Quand vient le temps d'appeler vos services réels, l'utilisateur peut simplement les appeler à volonté, et vous avez déjà vérifié que c'est sûr. Si les services requièrent tous des ensembles de revendications différents et qu'il n'y a pas de moyen facile de vérifier qu'ils fonctionneront à l'avance, je laisserais l'utilisateur les appeler et traiterai cela par le biais d'une gestion normale des exceptions. Cela va rendre la vie un peu plus difficile, car vous devrez laisser l'utilisateur essayer (et échouer) puis désactiver. Sinon, vous pouvez faire quelque chose comme ce que vous avez suggéré - mettre dans une forme de catalogue que vous pouvez interroger pour un utilisateur spécifique. En plus de simplement passer une adresse/méthode, il peut être plus agréable de vous permettre de simplement passer une adresse et de récupérer l'ensemble des méthodes autorisées (ou non autorisées, selon la plus petite). De cette façon, vous pouvez réduire les allers-retours uniquement pour l'authentification.

Answer 2

Une approche que j'ai prise est une classe qui fait l'inspection d'un ClaimSet pour garder les méthodes derrière le service. J'utilise des attributs pour décorer les méthodes avec des valeurs de type, de ressource et de propriété correcte. La classe d'inspection a ensuite une méthode Demand qui déclenche une exception si le ClaimSet de l'appelant ne contient pas de revendication avec ces valeurs de propriété. Ainsi, avant que tout code de méthode ne soit exécuté, la demande d'inspection de demande est appelée en premier. Si la méthode est toujours en cours d'exécution après la demande, alors l'appelant est bon. Il existe également une fonction bool dans la classe d'inspection pour répondre à la même question (l'appelant a-t-il les revendications appropriées) sans émettre d'exception.Je classe ensuite la classe d'inspection afin qu'elle soit déployée avec les clients et, tant que le client peut également obtenir le ClaimSet de l'appelant (que je fournis via une méthode GetClaimSet sur le service), il a tout ce qu'il faut pour faire les mêmes évaluations que le modèle de domaine fait. J'utilise ensuite la méthode bool de la classe d'inspection des revendications dans la méthode CanExecute des propriétés ICommand dans mes modèles de vue pour activer/désactiver les contrôles et essentiellement empêcher l'utilisateur d'obtenir des exceptions d'autorisation en ne les laissant pas faire les choses pour.

En ce qui concerne la façon dont le client sait quelles revendications sont nécessaires pour quelles méthodes, je suppose que je laisse le soin au développeur de savoir. En général sur mes projets ce n'est pas un gros problème car les méthodes ont été très crud. Donc, si la méthode consiste à ajouter un Apple, alors la revendication requise est intuitivement Type = Apple, Right = Add.

Je ne sais pas si cela aide votre situation, mais cela a plutôt bien fonctionné sur certains projets que j'ai réalisés.