2010-10-28 10 views
1

Il s'agit d'une question de conception fondamentale concernant la couche de service dans mon application, qui constitue la principale fonctionnalité de l'application. Presque tous les appels distants atteignent un service tôt ou tard.Mon niveau de service doit-il fonctionner pour n'importe quel utilisateur ou se limiter à l'utilisateur actuellement authentifié?

Maintenant, je me demande si

  • chaque méthode de service doit avoir un argument de l'utilisateur, pour lequel doit être effectué l'opération
  • ou si le service doit toujours interroger la mise en œuvre de la sécurité, qui l'utilisateur est actuellement connecté dans, et opérer sur cet utilisateur

Ceci est fondamentalement une décision de flexibilité vs sécurité, je suppose .. Que feriez-vous?

+0

est-ce une application web? pouvez-vous créer des sessions? ou doit être apatride? – fabrizioM

+0

Il s'agit d'une application Web qui, en fonction de l'accès distant, prend en charge les sessions (client Flex) ou non (client REST). Pourquoi? – Tom

Répondre

0

Il y a aussi un aspect DoS à considérer.

Une approche consiste à offrir (en fonction de votre contexte) une instance publique/un point d'entrée aux services, sur une configuration bien limitée; et une instance moins restreinte à un environnement sécurisé interne. Dans la même veine, si vous identifiez l'origine du trafic, vous pouvez (ou devriez) être en mesure de fournir une meilleure qualité de service aux personnes de confiance. Donc, je garderais peut-être le système central (les services que vous écrivez) assez ouvert/flexible, et gérerais d'autres choses liées à la sécurité ailleurs (probablement dans la plate-forme sous-jacente). Ce n'est pas parce que vous écrivez un ensemble de services que vous pouvez seulement exposer ceux-ci dans un endroit et tous en même temps (aux mêmes clients).

+0

Ma conception a maintenant une couche de service interne flexible, qui est bien testée en termes de logique et de sécurité. Cette couche de service est exposée via différentes interfaces externes, telles que REST, SOAP/AMF, etc. – Tom

0

Je pense que vous devriez décider quelles méthodes auront besoin d'un argument utilisateur et qui auront besoin d'un utilisateur connecté. Vous obtiendrez les types de méthode suivants comme résultat pour ceci:

1.) Type1: La méthode est préférable d'avoir un argument utilisateur.

2.) Type2: La méthode est préférable de ne pas avoir un argument utilisateur.

3.) Type3: Combinaison de 1.) et 2.)

La solution de 1.) et 2.) est simple, parce qu'ils sont des cas insignifiants.

La solution de 3.) est de surcharger la méthode pour avoir une version de 1.) type et une autre version de 2.) type.

0

J'essaie de considérer la sécurité comme un aspect. L'argument utilisateur est également requis pour d'autres choses que l'authentification. Mais, je pense que le contrôle devrait atteindre les méthodes plus importantes de la couche de service seulement si l'utilisateur a été authentifié par un autre filtre. Vous ne pouvez pas avoir toutes les méthodes dans la couche de service interroger le module de sécurité avant de continuer.