Najlepsza praktyka w zakresie autoryzacji na poziomie rekordów MVC/ASP.Net

Question

Czy ktoś ma jakieś sugestie dotyczące dobrej metodologii egzekwowania autoryzacji na poziomie rekordów przy zachowaniu rozdziału problemów w witrynie sieci Web ASP.Net MVC?

Z PrincipalPermission, można ozdobić metodę z:

PrincipalPermission(SecurityAction.Demand, Role = "GroupLeader") 

wymagać, aby każdy użytkownik tej strony być członkiem stałej roli „GroupLeader”.

Alternatywnie, można ozdobić metodę z:

[ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "Manage", Resource = "Group")] 

wymagać, aby każdy użytkownik tej strony wolno rodzajowo do zarządzania grupą.

Jednak żadna z nich nie odnosi się do scenariusza, w którym użytkownik może mieć uprawnienia do edycji niektórych grup, ale nie do innych. O ile mogę powiedzieć, nawet jeśli implementuję niestandardowy ClaimsAuthorizationManager, nie ma sposobu na uzyskanie dostępu do parametrów metody w celu dokonania warunkowej autoryzacji. Ponadto, obie powyższe metody po prostu rzucają SecurityException, jeśli użytkownik nie ma dostępu, zamiast pozwalać, aby metoda z wdziękiem przekierowała użytkownika na stronę wyjaśniającą, co się stało i co może zrobić, aby uzyskać niezbędną autoryzację. .

Oczywiście, zdaję sobie również sprawę, że mógłbym po prostu zakodować logikę autoryzacji w samej metodzie i odpowiednio przekierować, ale wolałbym oddzielić to, jeśli to możliwe, i zachować kod metody czysty, aby obsłużyć tylko przetwarzanie żądania, a także aby móc pracować w ramach, która może być bardziej ogólnie stosowana.

Czy istnieje "gotowy do użycia" sposób radzenia sobie z tym scenariuszem, czy też muszę zaimplementować niestandardowy IAuthorizationFilter? Myślę, że mógłbym obsłużyć zarówno autoryzację na poziomie rekordu, jak i wdzięczne przekierowanie, ale bez żadnych parametrów na poziomie metody, byłaby to w istocie ogromna instrukcja if ... else if.

Answer 1

Najprostszym sposobem poradzenia sobie z tą sytuacją jest utworzenie nieruchomości na twoich podmiotach w celu przechowywania "właściciela" lub "twórcy" jednostki. Następnie, gdy kwerendujesz obiekty, filtrujesz przez to. Na przykład:

public class Foo 
{ 
    public int Id { get; set; } 

    ... 

    public string Creator { get; set; } 
} 

wówczas:

public ActionResult FooDetails(int id) 
{ 
    var foo = db.Foos.SingleOrDefault(m => m.Id == id && m.Creator == User.Identity.Name); 
    if (foo == null) 
    { 
     return new HttpNotFoundResult(); 
    } 

    return View(foo); 
} 

To naprawdę nie jest właściwe, aby sobie z tym poradzić poprzez filtr zezwoleń, bo trzeba zaznaczyć wiersz do ustalenia uprawnień użytkownika. Następnie musisz ponownie wybrać wiersz w akcji, aby wysłać go do widoku. Musisz też wykonać akrobacje, aby uzyskać filtr, dzięki któremu dowiesz się, w jaki sposób powinien on wybrać lokalizację, abyś mógł najpierw sprawdzić uprawnienia. W akcie już wybierasz jednostkę, więc po prostu ją warunkuj w zależności od tego, czy użytkownik "jest jej właścicielem" w tym samym czasie.