2010-04-21 6 views
1

J'ai hérité d'une application Web classique à trois niveaux avec ASP.net 2.0 pour l'interface utilisateur, les services Web .Net (ASMX) au niveau intermédiaire et SQL Server 2005 pour la base de données. Il s'agit actuellement d'une application intranet dont les seuls utilisateurs sont des employés de l'entreprise. Actuellement, l'application utilise l'authentification Active Directory (AD). Sur l'écran de connexion, l'utilisateur reçoit une boîte de dialogue de nom d'utilisateur/mot de passe.Sécurisation d'un service Web

Le niveau intermédiaire fait un simple appel à l'AD pour vérifier le nom d'utilisateur/mot de passe. Si c'est le cas, un guid sessionId est généré et renvoyé à l'interface utilisateur. Cette sessionId est ensuite transmise à chaque appel ultérieur de l'interface utilisateur au sein de la session. Toutes les méthodes du niveau intermédiaire vérifient d'abord la validité de l'identificateur de session par rapport à une table de session simple dans SQL Server, avant de traiter la demande.

Je dois maintenant rendre le niveau intermédiaire des services Web disponible pour une nouvelle interface utilisateur qui sera disponible sur Internet. Je n'ai pas besoin de m'inquiéter de l'authentification car cela sera géré par la nouvelle interface utilisateur. Cependant, je ne veux pas laisser les services web complètement ouverts sans aucune sécurité. Je veux juste être sûr que le système appelant les services a la permission de le faire. Je ne veux pas imposer à la nouvelle interface utilisateur le maintien des sessionIds actuellement utilisés.

Des vues sur la meilleure façon de sécuriser les services lors de l'appel de la nouvelle interface utilisateur? Je suppose que je pourrais utiliser les certificats x509, mais je l'ai fait auparavant, donc je ne suis pas au courant des inconvénients (performance?) Ou comment faire pour l'implémentation.

La nouvelle interface utilisateur a été développée utilisée .Net 3.5. Nous pouvons installer .Net 3.5 sur le niveau intermédiaire donc je suppose que nous pourrions bénéficier de l'utilisation de WCF?

Répondre

0

Je ne crois pas que ce soit un problème qui convient à la cryptographie. Il serait préférable de limiter l'accès à votre service Web en utilisant une restriction IP. Si ces données sont transférées sur une connexion non sécurisée comme l'Internet ouvert, alors pourrait utiliser ssl pour vérifier le client et le serveur ainsi que garder les données transmises en toute sécurité. Vous pouvez également utiliser un VPN qui est probablement le plus facile à implémenter.

Je suis préoccupé par votre table de session. Je crois que cela introduit un délai pour la révocation des comptes d'utilisateurs. Si cette session n'a pas de date d'expiration, il est impossible de révoquer un compte d'utilisateur. Après qu'un utilisateur a ouvert une session, comment les expulser? Une solution consiste à avoir le répertoire actif de la requête de service Web ASMX pour chaque requête, si votre serveur AD n'est pas soumis à une charge importante, alors cela devrait être bon. Gardez à l'esprit que AD est une base de données très efférente dans son propre droit.