Un inicio de sesión entre múltiples aplicaciones ASP.NET MVC Preguntas

He estado trabajando en una aplicación ASP.NET MVC 4 que usa autenticación basada en formularios. Los usuarios son validados contra un proveedor de membresía basado en una selección de proveedor en el formulario de inicio de sesión. Por ejemplo, en este momento hay dos proveedores: directorio activo 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 última 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 verifican User.Identity.IsAuthenticated y vuelven 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 aplicaciones múltiples. Cada aplicación debe existir independientemente de las demás, compartir el mismo aspecto 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 usar en las otras tampoco es un problema. Con lo que tengo problemas es decidir cómo "refactorizar" la funcionalidad de inicio de sesión de manera que agregar un nuevo proveedor de membresía y una aplicación "en el futuro" no nos obligue a volver a publicar las aplicaciones existentes. En este momento tampoco querrían una página 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 http://site1.mysites.com , iniciar sesión y hacer mi trabajo mientras el chico que está a mi lado va a http://site2.mysites.com , inicia sesión y hace su trabajo.

Tengo problemas para entender 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 llamara al servicio web pasando las credenciales de inicio de sesión. Si el inicio de sesión fue exitoso, podría obtener una lista de aplicaciones para el usuario del almacenamiento local. Agregar más aplicaciones no requeriría que republiquemos las aplicaciones existentes debido a que no hay cambios en el servicio web para esas aplicaciones.

También sigo escuchando sobre estas cosas de la API web ASP.NET. ¿Debo seguir 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 local, por lo que tener un sitio que aloje la API web podría ser una opción.

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

Parece que sus requisitos únicos dictan que, de hecho, está en el camino correcto de que necesitará un proveedor de autenticación universal externo para todas sus aplicaciones, especialmente el requisito de que un cambio en el proveedor de membresía, tal como lo establece, no puede y no debe dar lugar a un Nuevo lanzamiento 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 sobre el enfoque WCF, ya que parece que los servicios web basados ​​en SOAP están siendo reemplazados lentamente por los servicios web basados ​​en REST, como lo que se ofrece en la API web ASP.NET. El futuro de las aplicaciones es móvil, y todas las principales plataformas de desarrollo móvil tienen un fuerte soporte para los servicios web basados ​​en REST.

Si incluso tiene la más mínima duda de que eventualmente necesitará extender el soporte del proveedor de membresía a las aplicaciones móviles, entonces 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. http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/