Rozszerzanie uwierzytelniania systemu Windows w aplikacji ASP.NET MVC 3

Question

po wielu poszukiwaniach i przeglądaniu kilku rozwiązań dotyczących zarządzania uwierzytelnianiem w trybie mieszanym w aplikacjach ASP.NET nadal nie mam odpowiedniego rozwiązania dla mojego problemu.

Muszę zaimplementować aplikację intranetową dla kilku różnych grup użytkowników. Do tej pory korzystałem z uwierzytelniania systemu Windows, które było bardzo proste w implementacji. Moje problemy pojawiają się, gdy chodzi o autoryzowanie grup użytkowników dla specjalnych funkcji aplikacji.

Korzystanie z działa świetnie, ale z tego powodu nie mam dostępu do zarządzania katalogiem aktywnym, niemożliwe jest skonfigurowanie zarządzania rolą w sposób, w jaki jest to potrzebne dla mojej aplikacji.

Co chcę zrobić, to zdefiniować niestandardowe role i członkostwa oprócz tych, które są zdefiniowane w aktywnym katalogu (czy takie rozszerzenie jest możliwe? Np. Poprzez wdrożenie własnego programu dostarczania członkostwa?).

Co według Ciebie jest najlepszym rozwiązaniem dla mojego problemu. Czy naprawdę muszę wdrożyć złożone uwierzytelnianie w trybie mieszanym z uwierzytelnianiem formularzy oprócz uwierzytelniania systemu Windows?

Używane technologie:

• MS SQL Server 2008
• MS VS 2010
• ASP.NET MVC 3 - Razor Zobacz silnika
• Telerik Rozszerzenia dla ASP.NET MVC
• IIS 7 w systemie Windows Server 2008:

E DIT (roztwór końcowe dzięki pomocy dougajmcdonald):

Po wskazaniu mi użyć niestandardowego wdrożenia IPrincipal Znalazłem kilka rozwiązań here i here. Wprowadzenie wszystko razem doszedłem do następującego rozwiązania:

1.Create implementacja zwyczaj główny:

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 mój zwyczaj wdrożenie główny do aplikacji poprzez rozszerzenie „Global.asax.cs” plik :

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.Use moich własnych ról zezwolenia w mojej aplikacji

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

     return View(); 
    } 
} 

Działa !!! Tak!

Answer 1

Nie jestem pewien, czy to nadal obowiązuje w MVC, ale w WebForms jeden sposób, aby to zrobić będzie w następujący sposób:

1. Utwórz nową implementację IPrincipal może rozciągający WindowsPrincipal
2. W tej klasie, nadaj mu zestaw ról (własne niestandardowe role).
3. Zapełnij te role, prawdopodobnie pobierając je z DB.
4. Zastąp wartość IsInRole, aby zwrócić wartość true, jeśli rola podana jest ZASADNA true od wywołania podstawowego (WindowsAuthentication/Role) LUB z własnej kolekcji niestandardowych ról.

W ten sposób nadal można podłączyć do Principal.IsInRole ("MyRole"), a także do głównej adnotacji [PrincipalPermission()].

Mam nadzieję, że to pomaga.

EDIT w odpowiedzi na q:

Aby zintegrować kapitał do zezwolenia trzeba napisać własną metodę OnAuthenticate w global.asax dla danego typu uwierzytelniania, więc myślę, że dla ciebie, coś takiego:

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;  
    } 
} 

wierzę autoryzacji wszedł w późniejszym terminie do PrincipalPermission, ale nie jestem zbyt pewny co do tego, kiedy/dlaczego różnic obawiam :(- przepraszam

!