asp.net - net - roles en asp
Aplicación ASP.NET para autenticarse en Active Directory o SQL a través de Autenticación de Windows o Autenticación de formularios (3)
Estoy en el proceso de escribir una aplicación que necesitará múltiples formas de autenticación.
La aplicación deberá admitir la autenticación en Active Directory, pero podrá realizar una conmutación por error a un proveedor de membresía SQL si el usuario no está en Active Directory. Podemos gestionar el error en el proveedor de SQL en el código basado en el nombre de usuario proporcionado porque el nombre de usuario tendrá un formato diferente al nombre de usuario de Active Directory.
¿Esto es posible? Lo que quiero decir es, ¿puedo usar la membresía y usar ActiveDirectoryMembershipProvider y SqlMembershipProvider juntos o tendré que transferir el mío?
Otra complejidad añadida adicional es que me gustaría autenticar automáticamente a mis usuarios internos basados en la Autenticación de Windows de nuevo en AD, pero uso la Autenticación de Formularios para los usuarios que no están en nuestra red interna, o los usuarios que usan el Proveedor de SQL.
Es muy probable que estos sean servidores separados, uno interno y el otro externo, por lo que tengo que planificar mucho para averiguar la replicación de datos y cómo autenticaré a los usuarios de AD si acceden al servidor externo, etc.
Me pregunto qué pensamientos hay por ahí cuando comienzo por este camino. ¿Es posible que lo que yo quiero hacer sea posible sin que yo también lo haga, o hay alguna forma de combinarlos?
Gracias por la respuesta.
La razón por la que pregunté originalmente fue porque pude hacer funcionar esta herramienta específica hace aproximadamente 7 años usando IIS para autenticar y luego devolver las credenciales a una aplicación web de Lotus Domino Server. Si el usuario no fue autenticado a través de la Autenticación / ISS de Windows, Domino manejaría la autenticación. Esto era lo que quería hacer aquí, pero realmente no podía pensar en una forma de hacerlo funcionar en IIS.
En cuanto al resto de su respuesta, creo que están en el camino que tendré que tomar. He pensado en esto y lo he pensado mucho en mi cabeza. La aplicación será algo diferente en los dos servidores de todos modos ya que de todos modos habrá acceso limitado a los datos en el servidor externo. El hecho de que tanto va a ser diferente ya puedo tratarlos como dos aplicaciones, negando así la necesidad de usar dos tipos de autenticación en la misma aplicación de todos modos.
Estoy jugando con la idea de escribir mi propia ventana de autenticación / inicio de sesión para el servidor externo, y si el usuario intenta iniciar sesión con sus credenciales de AD en el servidor externo, seré capaz de detectarlo y redirigirlo a la red interna. servidor. Si no están en la red local o VPN en, simplemente no tendrán acceso. Esta parte todavía tiene un proceso de pensamiento por recorrer, así que no estoy seguro.
Como una idea adicional, ¿hay alguna forma de extraer lo suficiente de AD en una base de datos SQL para permitirme autenticar usuarios en la base de datos SQL desde el servidor externo usando sus credenciales de AD, sin crear ningún problema de seguridad? Espero que esté escribiendo claramente lo que estoy pensando ...
¡Gracias de nuevo!
Tim
Hasta donde yo sé, las aplicaciones web están configuradas para usar Autenticación de Windows o Autenticación de formularios, pero no ambas. Por lo tanto, no creo que sea posible autenticar automáticamente a los usuarios internos mientras que otros requieren ingresar un nombre de usuario / contraseña.
Puede autenticarse en Active Directory o en una tienda de usuario de SQL a través de la autenticación Forms utilizando un proveedor personalizado. Sin embargo, los usuarios de AD aún tendrían que ingresar su nombre de usuario y contraseña. Aunque nunca he combinado estos dos métodos, he utilizado la autenticación Forms para autenticar contra ambas fuentes en un momento u otro.
Dicho esto, creo que es posible que desee considerar la reducción de la "flexibilidad" de su sistema. Si tiene un servidor externo y uno interno, podría simplemente cambiar la configuración del proveedor en cada copia de la aplicación para ir contra una fuente diferente. Luego, puede configurar el interno para usar la autenticación de Windows (automática) y la externa para usar la autenticación de formularios.
En mi humilde opinión, creo que los usuarios internos no deberían usar el servidor externo para acceder a la aplicación. Si lo son, deberían tener una cuenta de usuario almacenada en SQL, completamente separada de su cuenta AD. Básicamente, cuando alguien accede a la aplicación externamente, actúa como un usuario externo, independientemente de su ubicación física.
Bueno, es posible usar ActiveDirectoryMembershipProvider y SqlMembershipProvider, pero esto requiere que diseñe su página de inicio de sesión con su propio código en lugar de los controles de inicio de sesión.
Acerca de la autenticación de mezcla (Windows y Formularios), por lo que sé, solo IIS 7 lo hace fácil y limpio. Mire esta publicación para más detalles,
Esta es la forma en que he manejado una situación similar basada en esta información :
- Configurado la aplicación para usar la autenticación Forms.
- Establezca el LoginUrl en una página llamada WinLogin.aspx.
- En WinLogin.aspx, use Request.ServerVariables ["LOGON_USER"] para obtener el nombre de usuario y luego llame a FormsAuthentication.RedirectFromLoginPage (authorizedUserName, false) para iniciar sesión. Supongo que también puede verificar Active Directory como este punto.
- Cree una página html que redirija a una página llamada Login.aspx
- Login.aspx es su nombre de usuario / contraseña estándar de inicio de sesión.
- En IIS, habilite la Autenticación integrada y Anónimo en todo el sitio, pero niegue el acceso anónimo a WinLogin.aspx.
- En IIS, establezca sus errores 401 en la página creada en el paso 3.
Lo que básicamente sucede es que cuando un usuario no autorizado ingresa al sitio, se lo redirecciona a WinLogin.aspx. Como anonymous está desactivado, la seguridad integrada realiza un control. Si eso pasa, se puede ejecutar su código personalizado en WinLogin. Si la verificación de seguridad integrada falla, se produce un error 401. Su página 401 personalizada redirige a Login.aspx donde el usuario puede iniciar sesión usando su nombre de usuario y contraseña con el proveedor de SQL.