¿Cómo implemento Principal e Identidad personalizados en ASP.NET MVC?

Question

Quiero almacenar información adicional en el usuario autenticado para que pueda tenerlo fácilmente accesible (como User.Identity.Id, por ejemplo), en lugar de solo el nombre, ya que estoy planeando tener ese no exclusivo.

Hasta ahora, he llegado a la conclusión de que debería buscar implementar un Principal o una Identidad personalizada, pero no estoy seguro de cómo hacerlo. He estado buscando documentación y tutoriales sobre el tema, pero he encontrado cosas relacionadas en diferentes lugares y lo he encontrado un poco confuso.

He visto cómo agregar información personalizada a la cookie de autenticación en la propiedad de datos del usuario, pero me gustaría tener el beneficio de la inyección de dependencia para pruebas de unidades, que puedo tener con el principal y la identidad.

¿Cuáles son los exactas pasos que necesito tener en cuenta si quiero aplicar mi propio director o de identidad?

¿Cuál sería la manera más sencilla que podría hacer en este escenario (simplemente agregue la ID y mantenga todos los valores predeterminados en su lugar)? Los "valores predeterminados" incluirían los proveedores predeterminados (membresía, roles, etc.).

He visto el other question, pero agradecería las respuestas que no dejan ningún agujero en el medio, como los roles magic strings en el evento AuthenticateRequest en los ejemplos. En su lugar, necesito saber cómo agregar los roles del proveedor SqlRoleProvider predeterminado al usuario actual: cuándo y dónde hacerlo, y si necesito hacer algo más para conectar mis nuevas clases con los otros proveedores predeterminados.

Sería increíble poder acceder a una aplicación de ejemplo ASP.NET MVC 2 (de la plantilla visual studio 2010, por ejemplo), hacer las ediciones y hacer que funcione.

---

EDIT: He editado la pregunta a un mejor espectáculo que estoy bastante perdido aquí, así que no se puede conformar con respuestas muy alto nivel.

P.S .: Me parece que tiene más sentido tener el ID en la Identidad en lugar del principal, aunque he dicho de alguna manera esto antes.

Answer 1

Esta pregunta ha sido formulada y respondida antes: ASP.NET MVC - Set custom IIdentity or IPrincipal

Pero para resumir ...

cajón una clase principal de medida con los properites adicionales que desee almacenar:

Public Class CustomPrincipal 
    Inherits System.Security.Principal.GenericPrincipal 

    Private _eyeColor As String 
    Public ReadOnly Property EyeColor As String 
     Get 
      Return _eyeColor 
     End Get 
    End Property 

    Public Sub New(id As System.Security.Principal.IIdentity, roles As String(), eyeColor As String) 
     MyBase.New(id, roles) 
     _eyeColor = eyeColor    
    End Sub 

End Class 

Modifique global.asax Global.Application_AuthenticateRequest para usar su principal personalizado:

Protected Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As System.EventArgs) 
    ... 
    Dim roles() As String = {"examplerole"}   
    Context.User = new CustomPrincipal(Context.User.Identity, roles, "green") 
End Sub 

Luego, en su código en otros lugares cuando se quiere hacer referencia a una de estas propiedades hacen esto:

CType(My.User.CurrentPrincipal, CustomPrincipal).EyeColor 

Answer 2

No se puede realmente esperar que alguien le puede enseñar todo lo que no sabe acerca de .NET en algunos párrafosPuede leer un buen ejemplo en MSDN http://msdn.microsoft.com/en-us/library/system.security.principal.genericprincipal.aspx y profundizar en la clase y sus derivadas en Reflector: no hay nada espectacularmente especial al respecto.

Las funciones son solo una cadena de nombres para su propio uso, en su aplicación/servidor.

Habiendo dicho eso, realmente no tiene que apuntar a la derivada GenericPrincipal exacta en absoluto. Salida

HttpContext.Current.Items 

Es una tabla hash para el uso libre sólo para la solicitud que está reparando - lo que significa que en un momento dado puede no decir:

HttpContext.Current.Items["TokenUser"] = new MyThinUser(anything,I,want,there); 

y luego everythere otra parte del código acaba de hacer:

var user = HttpContext.Current.Items["TokenUser"] as MyThinUser; 

y listo.

Almacene en su nueva clase todo lo que necesita/desea pasar del código de autenticación a todas las demás funciones. Deja la propiedad del usuario intacta (para que puedas echarle un vistazo y no tener que preocuparte de que hayas cambiado algo). Wihr que puede simplificar o complicar su sistema a voluntad, pero mantiene su independencia total.

Por ejemplo, si tiene su propia autenticación y solo algunos niveles de acceso en lugar de roles enumerados, puede llevar un buen número de nivel de acceso antiguo (los roles enumerados como cadenas son muy ineficientes de todos modos).

Tenga en cuenta que las muestras autogeneradas en VS generalmente están orientadas a un escenario particular. Por lo tanto, si ve proveedores de SQL para administración de usuarios que no significan que realmente tiene que usarlos, puede simplemente llamar a su propio sproc para obtener lo que necesita de su propia tabla en SQL.