2012-01-26 12 views
14

después de buscar y leer varias soluciones sobre cómo administrar la autenticación de modo mixto en aplicaciones ASP.NET, todavía no tengo una solución adecuada para mi problema.Aumento de la autenticación de Windows en la aplicación ASP.NET MVC 3

Tengo que implementar una aplicación de intranet para un grupo de diferentes grupos de usuarios. Hasta ahora he utilizado la autentificación de Windows que fue muy simple de implementar. Mis problemas surgen cuando se trata de autorizar grupos de usuarios para funcionalidades de aplicaciones especiales.

El uso de [Authorize(Users = "DOMAIN\\USER")] funciona muy bien, pero debido a que no tengo acceso a la administración del directorio activo, me es imposible configurar la gestión de roles de la manera que la necesito para mi aplicación.

Lo que me gustaría hacer es definir roles personalizados y membresías además de las que están definidas dentro del directorio activo (¿es posible tal extensión? Por ejemplo, implementando un propio proveedor de membresía?).

¿Cuál cree que es la mejor solución para mi problema. ¿Realmente tengo que implementar una autenticación compleja de modo mixto con autenticación de formularios además de la autenticación de Windows?

tecnologías utilizadas:

  • MS SQL Server 2008
  • MS VS 2010
  • ASP.NET MVC 3 - Razor Ver motor
  • Extensiones Telerik para ASP.NET MVC
  • IIS 7 en Windows Server 2008

E DIT (solución final gracias a la ayuda de dougajmcdonald):

Después de dirigirme a utilizar una aplicación personalizada IPrincipal he encontrado algunas soluciones here y here. Poniendo todo junto llegué a la siguiente solución:

1.Create una implementación personalizada principales:

public class MyPrincipal: WindowsPrincipal 
{ 
    List<string> _roles; 

    public MyPrincipal(WindowsIdentity identity) : base(identity) { 
     // fill roles with a sample string just to test if it works 
     _roles = new List<string>{"someTestRole"}; 
     // TODO: Get roles for the identity out of a custom DB table 
    } 

    public override bool IsInRole(string role) 
    { 
     if (base.IsInRole(role) || _roles.Contains(role)) 
     { 
      return true; 
     } 
     else 
     { 
      return false; 
     } 
    } 
} 

2.Integrate mi aplicación principal de costumbre en la aplicación mediante la extensión del archivo "Global.asax.cs" :

protected void Application_AuthenticateRequest(object sender, EventArgs e) 
    { 
     if (Request.IsAuthenticated) 
     { 
      WindowsIdentity wi = (WindowsIdentity)HttpContext.Current.User.Identity; 
      MyPrincipal mp = new MyPrincipal(wi); 
      HttpContext.Current.User = mp; 
     } 
    } 

3. Utilizar mis papeles personalizados de autorización en mi solicitud

public class HomeController : Controller 
{ 
    [Authorize(Roles= "someTestRole")] 
    public ActionResult Index() 
    { 
     ViewBag.Message = "Welcome to ASP.NET MVC!"; 

     return View(); 
    } 
} 

Funciona! ¡sí!

Respuesta

8

no estoy seguro si esto todavía se aplica en MVC, pero en Webforms Una forma de hacer esto sería de la siguiente manera:

  1. Crear una nueva aplicación IPrincipal quizás extendiéndose WindowsPrincipal
  2. En esta clase, dele una colección de roles (sus propios roles personalizados)
  3. Rellene esos roles, quizás obteniéndolos del DB.
  4. Omitir IsInRole para que sea verdadero si el rol proporcionado es VERDADERO desde la llamada base (WindowsAuthentication/Role) O desde su propia colección de roles personalizados.

De esta manera todavía puede enganchar en Principal.IsInRole ("MyRole") y también la anotación principal [PrincipalPermission()].

Espero que ayude.

EDITAR en respuesta a la q de:

incorporar las principales en la autorización necesaria para desarrollar su propio método para OnAuthenticate en el Global.asax para el tipo de autenticación, por lo que supongo para usted, algo como esto:

void WindowsAuthentication_OnAuthenticate(object sender, WindowsAuthenticationEventArgs e) 
{ 
    // ensure we have a name and made it through authentication 
    if (e.Identity != null && e.Identity.IsAuthenticated) 
    { 
     //create your principal, pass in the identity so you know what permissions are tied to 
     MyCustomePrincipal opPrincipal = new MyCustomePrincipal(e.Identity);    
     //assign your principal to the HttpContext.Current.User, or perhaps Thread.Current 
     HttpContext.Current.User = opPrincipal;  
    } 
} 

creo Autorizar entró en una fecha posterior a la PrincipalPermission, pero no estoy muy seguro de cuándo/porqué de las diferencias temo :(- lo siento

!
+0

lo daré una prueba, gracias por la respuesta rápida :) –

+0

¡¡¡muchas gracias !!! ¡Tu respuesta fue muy útil! :-) –

+0

No hay problema, me alegro de que haya ayudado. ¡Tuve que hacer algo muy similar muy recientemente! En mi situación, no quería usar los roles de Windows Active Directory (ya que nuestros administradores no quieren administrar las cosas de esa manera) pero quería asegurar que PODRÍAMOS usarlos si así lo decidieran, de ahí la decisión de vincularse con el IPrincipal lado de las cosas en lugar de simplemente crear una cuenta de usuario como una clase interna para nuestra aplicación y cumplir roles en contra de ella. – dougajmcdonald

Cuestiones relacionadas