Un inicio de sesión entre varias aplicaciones ASP.NET MVC Preguntas

8

He estado trabajando en una aplicación ASP.NET MVC 4 que usa autenticación basada en formularios. Los usuarios se validan frente a un proveedor de membresía según la selección del proveedor en el formulario de inicio de sesión. Por ejemplo, en este momento hay dos proveedores: Active Directory y un proveedor personalizado que llama a un servicio web externo. Si el usuario es válido, entonces actualizamos la información en nuestra tabla de usuarios locales, como la fecha de inicio de sesión, etc. Si el usuario es válido y no existe en la tabla de usuarios locales, los agregamos. Una vez hecho todo esto, configuramos una cookie y pasamos al contenido principal. Todos los controladores comprueban User.Identity.IsAuthenticated y regresan a la página de inicio de sesión si la prueba falla.

Ahora me dicen que esta aplicación va de una aplicación web única a una solución de múltiples aplicaciones. Cada aplicación debe existir independientemente de las otras, compartir la misma apariencia y usar la misma funcionalidad de inicio de sesión. Cada aplicación puede requerir que se agregue un nuevo proveedor de membresía. También agregaremos datos para limitar el acceso a las aplicaciones. Un usuario solo puede tener acceso a una de las aplicaciones, mientras que otro usuario tiene acceso a todas ellas.

Configurar el almacenamiento de datos no es un problema. Compartir el diseño de una aplicación para que se use en las otras tampoco es un problema. Con lo que estoy teniendo problemas es decidir cómo "refactorizar" la funcionalidad de inicio de sesión, de modo que agregar un nuevo proveedor de membresía y una aplicación "en el futuro" no nos obligará a volver a publicar las aplicaciones existentes. En este momento, tampoco querrían una página de inicio de inicio de sesión único para las aplicaciones. Les gustaría que los usuarios vayan directamente a una aplicación, inicien sesión y hagan lo que vinieron a hacer. Por lo tanto, puedo ir a enlace , iniciar sesión y hacer mi trabajo mientras el chico que está a mi lado va a enlace , inicia sesión y hace su trabajo.

Tengo problemas para envolver mi cabeza en torno a la mejor manera de hacer esto. Mi primer pensamiento fue un servicio web WCF para el inicio de sesión. Me gustaría que una acción del controlador llame al servicio web que pasa las credenciales de inicio de sesión. Si el inicio de sesión fue exitoso, entonces podría obtener una lista de aplicaciones para el usuario del almacenamiento local. Agregar más aplicaciones no nos obligaría a volver a publicar las aplicaciones existentes debido a que no hay cambios en el servicio web para esas aplicaciones.

También escucho sobre estas cosas de la API web de ASP.NET. ¿Debo ir esa ruta en su lugar? Es posible que desee crear un sitio en torno a la administración de la base de datos de usuarios locales, por lo que tener un sitio que aloje la API web podría ser una opción.

¿Está mal la API web para esta situación? Si no, ¿tiene ventajas sobre el servicio web WCF? ¿Existen métodos alternativos para lograr mi resultado final?

    
pregunta fkm71 29.01.2013 - 19:08

1 respuesta

1

Parece que sus requisitos exclusivos dictan que está en el camino correcto y que necesitará un proveedor de autenticación universal externo para todas sus aplicaciones, especialmente el requisito de que un cambio en Membership Provider como no puede y no debe dar lugar a una nueva versión para su aplicación.

En un proveedor de autenticación universal, puede controlar qué sitios usan qué proveedores de membresía e incluso puede subyugar responsabilidades como delegar roles y privilegios a varios usuarios después de autenticarlos.

Sin embargo, aconsejo precaución con el enfoque de WCF, ya que parece que los servicios web basados en SOAP están siendo reemplazados lentamente en importancia por los servicios web basados en REST, como lo que se ofrece en la API web de ASP.NET. El futuro de las aplicaciones es móvil, y cada plataforma de desarrollo móvil importante tiene un fuerte soporte para servicios web basados en REST.

Si tiene la menor duda de que posiblemente necesite extender el soporte del proveedor de membresía a las aplicaciones móviles, es una buena idea renunciar a WCF. Además, los servicios web basados en REST permiten una mejor integración por parte de terceros (¿quizás clientes que desean integrarse con su paquete de software?) Para comunicarse con su aplicación y recuperar información de ella.

En lo que respecta a los protocolos de autenticación para servicios web basados en REST, no parece haber una buena manera de hacerlo, pero la seguridad es bastante esencial. Hay un buen artículo sobre cómo asegurar sus solicitudes de autenticación a su aplicación de proveedor de autenticación. enlace

    
respondido por el maple_shaft 29.01.2013 - 21:53

Lea otras preguntas en las etiquetas