Existe-t-il un moyen de restreindre l'accès à un service Web ASMX, c'est-à-dire la page asmx et son WSDL?

Bien, puisque c'est ASMX vous avez l'ensemble de l'ASP.NET exécution de la pile à votre disposition.

Étape #1 - la gestion de la ressource à travers .config

Appliquer un <location> balise pour les ressources que vous souhaitez sécuriser. En supposant que c'est un seul fichier ASMX vous pouvez simplement faire ce qui suit dans votre site web.config:

<location path="MyWebService.asmx">
    <system.web>
        <!-- resource specific options will go here -->
    </system.web>
</location>

Étape #2 - authentification de vos utilisateurs

Vous devez décider comment vous allez enfin pour authentifier les utilisateurs. Il y a plusieurs façons de le faire et de plusieurs normes d'authentification vous pourriez tirer parti. Vous devez choisir l'approche qui est la bonne pour vous.

Si vous êtes sur un intranet et utilisez l'authentification Windows je vous suggère fortement de tirer parti de ce parce que c'est vraiment l'option la plus simple pour obtenir le programme d'installation. Toutefois, si vos services sont accessibles sur internet puis Windows authenticatio n'est pas vraiment une option, et vous devez choisir à partir d'un standard du web. Le plus simple est L'Authentification De Basemais vous devriez seulement utiliser ce protocole SSL depuis le nom d'utilisateur/mot de passe ne sont pas cryptés (seulement encodées en base64). La prochaine étape est L'authentification Digest qui ne nécessite pas de SSL, car le nom d'utilisateur/mot de passe sont envoyés à l'aide d'un hachage MD5. Pour l'ultime vous pouvez aller avec SSL v3 où vous avez un problème spécifique certificat du client pour chaque utilisateur de votre API.

Maintenant, l'option que vous sélectionnez pour la sécurité dicte ce qu'il reste à faire. Si vous choisissez de sécurité de Windows, c'est aussi facile que d'ajouter l'élément suivant de la <system.web> élément, nous avons commencé avec dans l'Étape #1:

<authentication mode="Windows" />

Le reste de l'protocoles de sécurité vont exiger un peu plus de travail. ASP.NET ne pas fournir intrinsèque de soutien pour Basic, Digest ou SSL v3. Techniquement, vous pouvez tirer parti de IIS pour faire ce type d'authentification pour vous, mais il va toujours à la carte pour un utilisateur de Windows. Si c'est une option pour vous, puis il suffit de laisser le <authentication mode="Windows" /> élément et configurer IIS en conséquence. Si, toutefois, ce n'est pas une option, soit parce que vous n'avez aucun contrôle sur IIS/ActiveDirectory ou vous devez vous authentifier à l'encontre d'un utilisateur personnalisée de base de données, alors cela signifie que vous devez connecter un HttpModule personnalisé pour fournir le support pour les protocoles de sécurité.

Étape #3 - la sécurisation de la ressource

L'approche la plus simple à la sécurisation de la ressource est-à-dire: "ne laissez pas une personne qui n'a pas été authentifié en quelque sorte dans cette ressource". Ceci est fait en utilisant la suite de l'autorisation de configuration:

<authorization>
    <deny users="?" />
</authorization>

Si vous vouliez seulement permettre certains utilisateurs la possibilité de modifier à faire ce qui suit:

<authorization>
    <deny users="*" />
    <allow users="jdoe, msmith" />
</authorization>

Une autre approche consiste à définir les rôles (groupes) et il suffit de verrouiller la ressource à un rôle spécial qui vous mettez les utilisateurs que vous souhaitez accéder à la ressource.

<authorization>
    <deny users="*" />
    <allow roles="My Service Users" />
</authorization>

Il correspond bien à l'authentification Windows parce que vous pouvez juste l'installation d'un groupe de Fenêtres et de laisser votre MIS de l'équipe de gérer les utilisateurs qui sont dans ce groupe en utilisant ActiveDirectory. Toutefois, la fonctionnalité fonctionne également très bien pour les non-authentification Windows en supposant que la mise en œuvre de sécurité que vous avez utilisé expose les rôles par l'intermédiaire de son IPrincipal mise en œuvre.

Deux options: Créer un site entièrement différent sur un port différent verrouillé autorisations. Cela a l'avantage de fournir une certaine quantité de "sécurité par l'obscurité" (la moitié de plaisanter...) Ou vous pouvez ajouter une nouvelle Demande au titre de votre site(même port, chemin différent), sur une autre application de la piscine et attribuer des autorisations de cette façon.

Dans les deux cas, votre service web ne va pas être en mesure de parler avec les différents ASP.NET des "choses" comme l'objet de l'application (bien que ce sera, mais ce ne sera pas le même). Le déploiement est seulement un peu plus difficile: déployer les fichiers binaires, mais seulement inclure un fichier de service web.

Je ne sais pas comment pratique c'est pour vous, mais vous pourriez envisager de passer à la WCF. WCF est entièrement compatible avec les services web ASMX, et vous permet de contrôler si oui ou non le WSDL est exposée par la définition d'un MEX (échange de métadonnées) d'extrémité. Aucun MEX point de terminaison, pas de WSDL.