¿Existe alguna forma de restringir el acceso a un servicio web ASMX, es decir?¿La página asmx y su WSDL?

Question

Tengo un servicio web C# .net al que necesito restringir el acceso.Ya exijo a mis consumidores que utilicen un nombre de usuario y contraseña para llamar al servicio.Pero, ¿hay alguna manera de restringir el acceso a la página asmx real y al WSDL?Necesitaría restringir el acceso al servicio web mediante nombre de usuario/contraseña y dirección IP.Si un usuario no tuviera las credenciales correctas, no quisiera que supiera qué métodos web existen en el servicio web.

¿Se puede hacer esto a través de IIS?Sé que puedo restringir las direcciones IP a través de IIS, pero ¿puedo también usar nombres de usuario/contraseñas?

¿Hay alguna otra manera de hacer esto fuera de IIS, tal vez usando C#.net?

Answer 1

Bueno, como es ASMX, tienes toda la pila de tiempo de ejecución de ASP.NET a tu disposición.

Paso #1: administrar el recurso a través de .config

Aplicar un <location> etiqueta para los recursos que desea proteger.Suponiendo que es un único archivo ASMX, simplemente puede hacer lo siguiente en su web.config:

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

Paso #2: autenticar a tus usuarios

Debes decidir cómo vas a autenticar a los usuarios.Hay varias formas de hacerlo y varios estándares de autenticación que puede aprovechar.Debe elegir el enfoque que mejor se adapte a sus necesidades.

Si está en una intranet y utiliza la autenticación de Windows, le sugiero aprovecharla porque es realmente la opción más sencilla de configurar.Sin embargo, si se accede a sus servicios a través de Internet, la autenticación de Windows no es realmente una opción y debe elegir entre un estándar web.El más simple de ellos es Autenticación básica, pero deberías solo use esto a través de SSL ya que el nombre de usuario y la contraseña no están cifrados (solo codificados en base64).El siguiente paso a partir de eso es Autenticación implícita que no requiere SSL porque el nombre de usuario y la contraseña se envían mediante un hash MD5.Para lo último que puedes elegir SSL v3 donde emite un certificado de cliente específico para cada usuario de su API.

Ahora, la opción que seleccione por seguridad dicta qué más se debe hacer.Si eliges la seguridad de Windows, es tan fácil como agregar el siguiente elemento al <system.web> elemento con el que comenzamos en el Paso 1:

<authentication mode="Windows" />

El resto de protocolos de seguridad requerirán un poco más de trabajo.ASP.NET no proporciona soporte intrínseco para Basic, Digest o SSL v3.Técnicamente, puede aprovechar IIS para realizar este tipo de autenticación por usted, pero siempre se asignará a un usuario de Windows.Si esa es una opción para usted, simplemente deje el <authentication mode="Windows" /> elemento y configurar IIS en consecuencia.Sin embargo, si esa no es una opción, ya sea porque simplemente no tiene control sobre IIS/ActiveDirectory o porque necesita autenticarse en una base de datos de usuario personalizada, entonces eso significa que necesita conectar un HttpModule personalizado para brindar soporte para estas funciones de seguridad. protocolos.

Paso #3: asegurar el recurso

El enfoque más sencillo para proteger el recurso es básicamente decir:"No permita que nadie que no se haya autenticado exitosamente de alguna manera ingrese a este recurso".Esto se hace usando la siguiente configuración de autorización:

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

Si quisieras solo permitir cierto usuarios que podrías cambiar para hacer lo siguiente:

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

Otro enfoque es definir roles (grupos) y simplemente bloquear el recurso en un rol especial al que usted asigna los usuarios que desea acceder al recurso.

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

Esto se corresponde bien con la autenticación de Windows porque puede simplemente configurar un grupo de Windows y dejar que su equipo de MIS administre qué usuarios están en ese grupo usando ActiveDirectory.Sin embargo, la característica también funciona bien para la autenticación que no es de Windows, suponiendo que la implementación de seguridad que ha utilizado expone los roles a través de su implementación IPrincipal.

Answer 2

Dos opciones: crear un sitio completamente diferente en un puerto diferente con permisos bloqueados. Esto tiene la ventaja de proporcionar cierta cantidad de & "; Seguridad a través de la oscuridad &"; (medio en broma ...) O puede agregar una nueva aplicación en su sitio (mismo puerto, ruta diferente), en un grupo de aplicaciones diferente y asignar permisos de esa manera.

En cualquier caso, su servicio web no podrá hablar con los distintos ASP.NET " things " como el objeto de la aplicación (bueno, lo será, pero no será el mismo). La implementación es solo un poco más difícil: implemente los mismos binarios, pero solo incluya un archivo de servicio web.

Answer 3

Puede autenticarse usando un HttpModule. SSL + BasicAuthentication debería producir la mejor interoperabilidad con otras cadenas de herramientas.

En el HttpModule, tiene acceso a la solicitud y puede denegar el acceso de usuarios no autenticados a solo solicitudes .asmx. E incluso entonces puede permitirles acceder al WSDL.

Answer 4

Agregue <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> a la sección <httpHandlers> del archivo web.config

Answer 5

No sé cuán práctico es esto para usted, pero podría considerar actualizar a WCF. WCF es totalmente compatible con los servicios web ASMX y le permite controlar si el WSDL está expuesto o no al definir un punto final MEX (intercambio de metadatos). Sin punto final MEX, sin WSDL.

Answer 6

Puede evitar que se muestre WSDL eliminando el protocolo de documentación del elemento en Machine.config

Actualización: Autenticación de servicios web: ¿mejores prácticas? Si sus usuarios tienen nombres de usuario / contraseñas, puede usar la autenticación básica HTTP a través de HTTPS.

También puede implementarlo de una manera ligeramente diferente. La primera llamada a su servicio web debe ser el método de autenticación. El cliente se autentica y recibe un token de autenticación. Este token debe presentarse a todos los demás métodos expuestos por su servicio web.