La implementación de múltiples bases de datos, sistema de autenticación de múltiples proveedores

Question

Hemos comenzado a construir una aplicación asp.net mvc. Aplicación consistirá en una base de datos principal con los usuarios, proyectos, mesas comunes, etc ... y muchas bases de datos (todos con la misma estructura) con los datos relevantes para un proyecto en particular. El uso puede tener algunas funciones globales (almacenados en una base de datos principal) y algunas funciones específicas del proyecto (almacenada en una base de datos del proyecto) y cada usuario puede ser relacionado con muchos proyectos.

Mi objetivo es construir un sistema de autenticación que apoyará clásica nombre de usuario / autenticación de contraseña y también una autenticación OpenID (estamos utilizando DotNetOpenAuth para este propósito) y el sistema de autorización que soportará el sistema de papeles, que he descrito anteriormente.

Pero me encuentro con varias pregunta: 1.) Creo que deberíamos apoyar ambos (nombre de usuario / contraseña y Ppenid) opciones de autenticación para un solo usuario, por lo que ese nombre de usuario / contraseña que los usuarios no se necesita crear una cuenta adicional cuando deciden que van a utilizar un OpenID y creo que debemos apoyar varias de OpenID para un solo usuario, como también lo hace (si algún proveedor está abajo).

.

2) Creo que la mejor base de datos para esto sería:

table Users (UserId (PK), LastActivityDate)
table UsernameLogins (UserId (PK,FK), Username, Password, IsApproved, IsLockedOut, LastLoginDate, LastLockedOutDate, etc...)
table OpenIdLogins(OpenIdUrl (PK), UserId(FK),LastLoginDate)
table Profiles(UserId(PK,FK), DisplayName(Unique), Email (Unique), FirstName, LastName, Address, Country, etc...)
table Roles(RoleName (PK), RoleType(1=GlobalRole,2=ProjectRole).
table UserRoles(UserId(FK,PK), RoleName(PK)).

3.) ¿Debo crear mis propios proveedores (MembershipProvider, ProfileProvider, RoleProvider)? Sus parece que MembershipProvider no es tan apropiado para una autenticación OpenID (y, por supuesto, sólo puedo apoyar sólo métodos básicos (getUser, ValidateUser))? Debería aplicar MembershipProvider sólo para los inicios de sesión de usuario / contraseña? Creo que ProfileProvider y RoleProvider no sería tan difícil de poner en práctica? ¿Debo usar FormsAuthentication y utilizar mis propios "servicios"?

También estamos utilizando NHibernate y la primavera de DI.

Se apreciará Cualquier consejo.

Gracias!

Answer 1

  

1). Creo que debemos apoyar ambos (nombre de usuario / contraseña y Ppenid)   opciones de autenticación para un solo   usuario, de modo que los usuarios de nombre de usuario / contraseña   no tendrá que crear más   tener en cuenta cuando se decide que   utilizará un OpenID y creo que nos   debe soportar varios de OpenID para una   de usuario único como lo hace (si algunos   proveedor es hacia abajo).

Esto parece razonable. Me gusta cómo se está diseñando en el que los usuarios tengan múltiples OpenID. Stackoverflow limita a sólo dos usuarios, pero los usuarios tienen a menudo más que eso y puede que desee unirse a todos ellos. Creo nombre de usuario / contraseña es una buena opción si su público objetivo lo exige OpenID. StackOverflow es un gran ejemplo de lo sencillo de inicio de sesión puede ser cuando su pura OpenID. Puede hacer menos ocupado de inicio de sesión para no ofrecer nombre de usuario / contraseña. Pero, de nuevo, proporcionando tanto como opciones parece más ya que les da opción centrada en el cliente. Una versión futura de DNOA ofrecerá una versión integrada del selector InfoCard en su sistema de OpenID por lo que incluso se puede aceptar InfoCards directamente, sino que tienen que ver y sentir como un OpenID para que su sistema no requerirá ningún cambio.

  .

2) Creo que la mejor base de datos para esto sería: <snipped/>

Eso se parece a un esquema razonable. Como usted ha descubierto, que separa las tablas credenciales le da la mayor flexibilidad.

  

3.) ¿Debo crear mis propios proveedores (MembershipProvider, ProfileProvider, RoleProvider)?

MembershipProvider ciertamente no cabe OpenID muy bien. Si sólo estaban apoyando OpenID diría que tirar hacia fuera y no molesto a la implementación de su propia. El RoleProvider funciona perfectamente con OpenID así que es un arquero. He oído de otros que ProfileProvider necesita un MembershipProvider con el fin de funcionar. No sé si eso es cierto. Pero ProfileProvider requiere que se utilice el esquema de base de ASP.NET SQL membresía, que creo que es pobre si usted puede escribir su propio esquema dB, lo que usted ha hecho. Y si usted está escribiendo su propia db, el almacenamiento de datos adicionales acerca de sus usuarios deben ser trivial por lo que no es necesario el proveedor de perfil.

Si vas con tanto nombre de usuario + contraseña y OpenID, y luego tener un MembershipProvider que implemente mismo probablemente sería posible, pero en mi experiencia, la mayoría de MembershipProviders que incluyen cualquier código de OpenID son kludgey e incluso tienen agujeros de seguridad. Así que yo todavía evitar la MembershipProvider si OpenID tiene ningún lugar en su sistema.

Answer 2

Me pregunto ... es el soporte para múltiples OpenID tan importante. Parece que esto es más el papel del proveedor de OpenID. Por ejemplo, yo uso ClaimID y consigo lo que esencialmente equivale a "identificar reenvío" (en el sentido de reenvío de correo electrónico) para que pueda volver a enlazar a diferentes identidades. Ahora bien, no volver a enlazar los proveedores con frecuencia, pero un proveedor podría hacer esto (es decir, cuando uno se redirige a su página de inicio de sesión que podría pedirle que la identidad que le gusta en última instancia, a la fecha). Así que la pregunta es ... ¿es realmente el trabajo para implementar aplicaciones?