¿Cómo se permiten múltiples métodos de autenticación en ASP.NET?

Question

Estoy construyendo una nueva aplicación ASP.NET MVC (en C#) y uno de los requisitos es crear una nueva base de datos de miembros. Para esto, necesitaríamos roles para administrar los diferentes tipos de miembros y perfiles para administrar los metadatos adicionales adjuntos a cada miembro. Hasta ahora todo va bien, solo use MembershipProvider, RoleProvider y ProfileProvider estándar proporcionados como parte de .NET Framework.

Sin embargo, la trampa es que me gustaría permitir diferentes métodos de autenticación. Me gustaría que las cuentas y las credenciales de inicio de sesión tengan una relación de uno a varios (una cuenta puede tener un número de credenciales de inicio de sesión adjunto). Un usuario, por ejemplo, podría tener una cuenta de OpenID y ActiveDirectory adjunta a su cuenta.

Sin embargo, después de experimentar con algunas maneras, optamos por la ruta MembershipProvider (explica cómo se logró como respuesta a continuación).

Mi pregunta es, ¿cómo han hecho esto antes las personas y cómo la gente sugiere que lo aborde? Parece ser algo que se logra en una gran cantidad de sitios, sin embargo, una búsqueda aquí no arroja nada sólido para jugar.

EDIT: Después de buscar un buen período de horas durante la noche y esta mañana, todavía no estoy convencido de que matar a un único MembershipProvider hubiera sido la opción más fácil. ¿Tener múltiples MembershipProviders da el mismo efecto?

BOUNTY EDIT: Sin respuestas, asumo que no existe una solución más óptima que la que publiqué como respuesta. ¿Es este realmente el caso? Estoy ofreciendo una recompensa para tratar de ver si alguien tiene más ideas sobre esto y si hay mejores alternativas.

BOUNTY ACCEPT EDIT: Creo que WIF es la respuesta aceptada a continuación, para una versión .NET 4 y tal vez otras versiones, ya que probablemente funcione con 3.5. Aparte de eso, tal vez un MembershipProvider asesinado o adaptado aún puede ser relevante.

Answer 1

En mi opinión, el "camino real" de hacer esto es utilizar federación con WIF (Windows Identity Foundation, anteriormente marco de Ginebra).

La idea es que separe la autenticación de autorización. La autenticación se realiza mediante el denominado STS (Servicio de token de seguridad) y gestiona todos los mecanismos de inicio de sesión posibles que desee. Cuando un usuario ha sido autenticado, el STS emite un token que contiene un conjunto de declaraciones y la identidad del usuario. Este token se envía al sitio web (denominado parte confiante de esta jerga) y el sitio web determina a qué partes del sitio tiene acceso el usuario en función de los reclamos en el token. WIF proporciona tanto miembros como proveedores de funciones que extraen información del token.

Puede leer sobre cómo crear un claims aware website here.

Uno de los pros de este enfoque es la separación de preocupaciones entre autenticación y autorización. No necesita ninguna membresía compleja y rolproviders en su sitio web. Además, el STS se puede reutilizar para autenticar usuarios a otras aplicaciones que pueda tener sin tener que registrarse más de una vez (logrando el inicio de sesión único)

El inconveniente es que tendrá que dedicar un tiempo a estudiar estos conceptos y codificando su STS. Eso sí, no es difícil codificar un STS con WIF, pero tampoco es una tarea 100% trivial.

Si he logrado hacerle cosquillas a su interés, le recomiendo que empiece leyendo this whitepaper.

Saludos cordiales,

Klaus

Answer 2

Una idea que hemos seguido es crear un proveedor de Membresía/Rol/Perfil personalizado. Personalizamos los métodos de inicio de sesión/autenticación de manera significativa y tenemos una tabla adicional de inicios de sesión. Esta tabla básicamente contenida:

LoginID (Auto-Incremental ID, PK) 
UserID (FK) 
LoginSystemID (FK) 
...blah blah 

Dentro de lo anterior, el LoginSystemID era un enlace a una tabla de consulta externa que ayudó al sistema para determinar qué servicio de autenticación a utilizar (por ejemplo, estándar, AD, OpenID, FacebookConnect - etc) .

El problema que encontramos es que el campo Nombre de usuario en MembershipProvider no podía estar vacío y mientras que en nuestro esquema todos tenían un UserID (era su nombre de cuenta), no tenían un nombre de usuario único. Tuvimos que solucionar esto generando un GUID y usándolo. Esto, por supuesto, está oculto para el usuario y, en su lugar, se puede mostrar un atributo DisplayName de nuestra tabla Usuarios.

Todo esto se realizó a través de FormsAuthenication (las comprobaciones de AD se realizaron mediante comprobaciones de LDAP). Sin embargo, se agregó una capa adicional (un formulario web) con la configuración apropiada dentro de IIS que proporcionó un medio para la Autenticación automática de Windows: redirigimos hasta allí en la instancia que creemos que el usuario probablemente sea interno (en función de la dirección IP).

Answer 3

Use material de marco estándar.Ver http://blogs.teamb.com/craigstuntz/2009/09/09/38390/

Usted puede tener un número ilimitado de métodos de autenticación conectado a una cuenta, la magia está en el FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); comunicado