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

Question

J'ai un service Web C# .net auquel je dois restreindre l'accès.J'exige déjà que mes consommateurs utilisent un nom d'utilisateur et un mot de passe pour appeler le service.Mais existe-t-il un moyen de restreindre l’accès à la page asmx réelle et au WSDL ?Je devrais restreindre l'accès au service Web par nom d'utilisateur/mot de passe et adresse IP.Si un utilisateur ne dispose pas des informations d'identification correctes, je ne voudrais pas qu'il sache quelles méthodes Web existent dans le service Web.

Cela peut-il être fait via IIS ?Je sais que je peux restreindre les adresses IP via IIS, mais puis-je également utiliser des noms d'utilisateur/mots de passe ?

Existe-t-il un autre moyen de procéder en dehors d'IIS, peut-être en utilisant C#.net ?

Answer 1

Eh bien, puisqu'il s'agit d'ASMX, vous disposez de toute la pile d'exécution ASP.NET.

Étape n°1 : gérer la ressource via .config

Appliquer un <location> balise pour les ressources que vous souhaitez sécuriser.En supposant qu'il s'agisse d'un seul fichier ASMX, vous pouvez simplement effectuer les opérations suivantes dans votre web.config :

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

Étape n°2 : authentifier vos utilisateurs

Vous devez décider comment vous allez réellement authentifier les utilisateurs.Il existe plusieurs façons de procéder et plusieurs normes d'authentification que vous pouvez exploiter.Vous devez choisir l’approche qui vous convient.

Si vous êtes sur un intranet et utilisez l'authentification Windows, je vous suggère fortement d'en tirer parti car c'est vraiment l'option la plus simple à configurer.Cependant, si vos services sont accessibles via Internet, l'authentification Windows n'est pas vraiment une option et vous devez choisir parmi une norme Web.Le plus simple d'entre eux est Authentification de base, mais tu devrais seulement utilisez-le via SSL car le nom d'utilisateur/mot de passe ne sont pas cryptés (uniquement encodés en base64).La prochaine étape à partir de là est Authentification Digest qui ne nécessite pas SSL car le nom d'utilisateur/mot de passe est envoyé à l'aide d'un hachage MD5.Pour le nec plus ultra, vous pouvez choisir SSLv3 où vous délivrez un certificat client spécifique à chaque utilisateur de votre API.

Désormais, l’option que vous sélectionnez pour la sécurité dicte ce qui doit être fait d’autre.Si vous choisissez la sécurité Windows, c'est aussi simple que d'ajouter l'élément suivant au <system.web> élément avec lequel nous avons commencé à l'étape 1 :

<authentication mode="Windows" />

Le reste des protocoles de sécurité va nécessiter un peu plus de travail.ASP.NET ne fournit pas de prise en charge intrinsèque pour Basic, Digest ou SSL v3.Techniquement, vous pouvez utiliser IIS pour effectuer ce type d'authentification à votre place, mais cela sera toujours mappé à un utilisateur Windows.Si c'est une option pour vous, laissez simplement le <authentication mode="Windows" /> élément et configurez IIS en conséquence.Si, toutefois, ce n'est pas une option, soit parce que vous n'avez tout simplement aucun contrôle sur IIS/ActiveDirectory, soit parce que vous devez vous authentifier auprès d'une base de données utilisateur personnalisée, cela signifie que vous devez connecter un HttpModule personnalisé pour prendre en charge ces sécurités. protocoles.

Étape n°3 – sécuriser la ressource

L’approche la plus simple pour sécuriser la ressource consiste essentiellement à dire :"ne laissez personne qui ne s'est pas authentifié avec succès d'une manière ou d'une autre accéder à cette ressource".Cela se fait à l'aide de la configuration d'autorisation suivante :

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

Si vous vouliez autoriser uniquement certain utilisateurs, vous pouvez modifier ce qui suit à la place :

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

Une autre approche consiste à définir des rôles (groupes) et à simplement verrouiller la ressource sur un rôle spécial dans lequel vous attribuez aux utilisateurs auxquels vous souhaitez accéder à la ressource.

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

Cela correspond bien à l'authentification Windows car vous pouvez simplement configurer un groupe Windows et laisser votre équipe MIS gérer les utilisateurs de ce groupe à l'aide d'ActiveDirectory.Cependant, la fonctionnalité fonctionne également très bien pour l'authentification non Windows, en supposant que l'implémentation de sécurité que vous avez utilisée expose les rôles via son implémentation IPrincipal.

Answer 2

Deux options: Créer un site entièrement différent sur un port différent avec des autorisations verrouillées. Cela présente l’avantage de fournir un peu de & Sécurité; grâce à l’obscurité & "; (moitié plaisante ...) ou vous pouvez ajouter une nouvelle application sur votre site (même port, chemin différent), sur un pool d'applications différent et attribuer les autorisations de cette façon.

Dans les deux cas, votre service Web ne pourra pas dialoguer avec les différentes choses ASP.NET & "; &"; comme l'objet de l'application (enfin ce sera le cas, mais ce ne sera pas le même). Le déploiement n’est que légèrement plus difficile: déployez les mêmes fichiers binaires, mais n’incluez que le fichier de service Web.

Answer 3

Vous pouvez vous authentifier à l'aide d'un HttpModule. SSL + BasicAuthentication devrait permettre une meilleure interopérabilité avec d'autres chaînes d'outils.

Dans le HttpModule, vous avez accès à la demande et pouvez refuser aux utilisateurs non authentifiés l'accès uniquement aux demandes .asmx. Et même alors, vous pourriez les laisser accéder au WSDL.

Answer 4

Ajouter <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> à la section <httpHandlers> du fichier web.config

Answer 5

Je ne sais pas si c'est pratique 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 l’exposition du WSDL en définissant un point de terminaison MEX (échange de métadonnées). Pas de terminal MEX, pas de WSDL.

Answer 6

Vous pouvez empêcher l'affichage de WSDL en supprimant le protocole de documentation de l'élément dans Machine.config

Mise à jour: Authentification des services Web: meilleures pratiques? Si vos utilisateurs ont des noms d'utilisateur / mots de passe, vous pouvez utiliser l'authentification HTTP de base via HTTPS.

Vous pouvez également le mettre en œuvre de manière légèrement différente. Le premier appel à votre service Web devrait être la méthode d'authentification. Le client s'authentifie et reçoit un jeton d'authentification. Ce jeton doit être présenté à toutes les autres méthodes exposées par votre service Web.