Zabezpieczenia ASP.NET MVC4, uwierzytelnianie i autoryzacja

Question

Pracuję nad nowym projektem asp.net mvc4 za pomocą Visual Studio 2011 beta i staram się zorientować się w całej sprawie bezpieczeństwa. Jest to wewnętrzna aplikacja intranetowa, która początkowo będzie korzystać z pojedynczego logowania, więc użytkownik nie będzie (jeszcze) monitowany o identyfikator/hasło systemu Windows. Firma ma niestandardową aplikację do przechowywania ról dla różnych aplikacji i będzie dostępna za pośrednictwem wywołania procedury przechowywanej. To zajmie identyfikator logowania użytkownika i zwróci pewien rodzaj kolekcji zawierającej role, np. "MyApp.Data", "MyApp.User," MyApp.Admin ". Więc co to się nazywa - czy jest to niestandardowy dostawca członkostwa, niestandardowy dostawca ról czy coś innego?

Czytałem już na wszystkie tajniki autoryzacji, uwierzytelniania, członkostwa, ról itp. i nie widzę obecnie drzewa dla drzew. Czytałem, że istniejące obiekty ASP.NET Security zostały wypróbowane i przetestowane, i o ile nie są to bardzo skomplikowane wymagania, wystarczą wbudowane, więc cieszę się z tego, co już tam jest.

Więc jeśli użytkownik jest już zalogowany w sieci, oznacza to, że jest on uwierzytelniony - czy jest prawidłowy? muszę tylko wdrożyć autoryzację Czy konieczne jest udekorowanie każdego kontrolera lub działania za pomocą atrybutu autoryzacji? Jeśli tak, to w jaki sposób część "ABC" z [Authorize (Roles = "ABC")] jest ustawiona, jeśli pobieram role z aplikacji do przechowywania niestandardowej roli?

Czytałem kilka artykułów i blogach w tym ten jeden z Jon Galloway ale zgubiłem ku końcowi:

Customizing Authentication and Authorization The Right Way

Tyle pytań ... jeśli ktoś zna dobry opis tego, jak wysoki poziom wszystko to wisi razem, to jestem uszy :)

Answer 1

Ok, w przypadku braku odpowiedzi, która daje wysoki poziom widoku, jak wszystko to wisi razem Myślałem, że będę Bazgroły dół moje wyniki do tej pory:

• firma wykorzystuje Active Directory do szczegółów logowania sklep użytkownika, tak jak to jest wykorzystywane do członkostwa nie muszę dostawcę niestandardowych członkostwa. Gdy użytkownik jest zalogowany do sieci firmowej, zostaje uwierzytelniony. Dodanie globalnego filtru autoryzacji zapewnia, że ​​każdy użytkownik uzyskujący dostęp do systemu będzie musiał zostać uwierzytelniony.Najświeższe informacje z Rick Anderson na MSDN:

  http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

Więc w Global.asax Dodałbym:

public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{ 
    filters.Add(new HandleErrorAttribute()); 
    filters.Add(new System.Web.Mvc.AuthorizeAttribute()); //new 
} 

• Po uwierzytelnieniu użytkownika I wtedy trzeba zajmij się autoryzacją. Firma ma istniejący globalny magazyn danych dla ról, do których nie będę mieć dostępu do aktualizacji, tylko dostęp do odczytu, dzięki czemu mogę odzyskać role dla danego użytkownika za pośrednictwem zapisanego wywołania proc. Może potrwać od kilku dni do kilku tygodni, aby dział pomocy technicznej utworzył role po wysłaniu żądania, dlatego z tego powodu początkowo utworzone zostaną dwie standardowe role: Użytkownik i Administrator, a kolejne role będą przechowywane w naszej bazie danych aplikacji .

• Wraz z tymi dwiema standardowymi rolami wymagane są kolejne role, takie jak Superużytkownik itp. Te role będą miały różne prawa w zależności od reguł biznesowych itp. I będą musiały być przechowywane w naszej bazie danych aplikacji. W tym scenariuszu będę musiał utworzyć niestandardowego dostawcę ról, dodać odpowiednie tabele ról asp.net do mojej bazy danych aplikacji i podłączyć go do pliku web.config. Oto strona ms zatytułowany zarządzający autoryzacji Korzystanie Role że jestem zbieranie bitów z:

  http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx

• Z tego co czytałem do tej pory tylko tabele potrzebne do dostawcy rolę niestandardową są Role i UsersInRoles .

  tworzenie ról Tabela ( RoleName Tekst (255) NOT NULL, ApplicationName tekstowych (255) NOT NULL, CONSTRAINT PKRoles PRIMARY KEY (RoleName, ApplicationName) )

  TWORZENIE UsersInRoles Tabela ( Nazwa użytkownika Tekst (255) NOT NULL, RoleName tekst (255) NOT NULL, ApplicationName tekst (255) NOT NULL, CONSTRAINT PKUsersInRoles PRIMARY KEY (Nazwa użytkownika, RoleName, ApplicationName) )

• Po tym wszystkim jest to konfiguracja muszę dowiedzieć się, jak łączyć standardowe 2 role (użytkownika i admin) z globalnego magazynu danych z niestandardowych ról przechowywanych w mojej aplikacji bazy danych, a jeśli mogę użyć (na przykład) [ Autoryzuj (Role = "Administrator, Superuser")] na kontrolerze/akcji lub jeśli potrzebuję podklasy AuthoriseAttribute i rób coś bardziej sprytnego.

• Właśnie zdałem sobie sprawę, że ponieważ używam AD do uwierzytelniania, potrzebuję sposobu dodania/wstrzyknięcia kolekcji ról, których jest członkiem bieżącego użytkownika. Więc chociaż nie potrzebuję żadnej niestandardowej funkcjonalności dostawcy członkostwa, nadal muszę wchodzić w interakcję z httpContext.User, aby zaktualizować swoją kolekcję ról.

Answer 2

Jeśli twoja autoryzacja jest już obsługiwana przez system Windows (zgaduję przez Active Directory), to szukam mechanizmu autoryzacji, który dopasowuje role do użytkowników. Jedną z opcji jest załadowanie ról użytkowników do bieżącej sesji po pomyślnym zakończeniu. Następnie należy utworzyć atrybut niestandardowy autoryzacji że sprawdzi, czy bieżąca sesja posiada niezbędne funkcje, że pracujesz z

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited=true, AllowMultiple=true)] 
public class CustomAuthorizationAttribute : AuthorizeAttribute 
{ 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    {   
     IPrincipal user = httpContext.User; 
     if (!user.Identity.IsAuthenticated) 
     { 
      return false; 
     } 

    //check your users against a database and return true or false 
     return base.AuthorizeCore(httpContext); 
    } 
} 

następnie można użyć atrybutu jak to

[CustomAuthorization] 
public ActionResult SomeAction() 
{ 
    return View(); 
} 

UPDATE

AuthorizeCore to metoda, która będzie używana w celu sprawdzenia, czy dany użytkownik powinien mieć dostęp do odpowiedniej metody działania. W ramach tej metody możesz sprawdzić właściwość httpContext.User.Identity.Name w swojej bazie danych lub miejscu, gdzie przechowywane są twoje role. Jeśli używasz uwierzytelniania systemu Windows za pośrednictwem usługi Active Directory, HttpContext.User.Identity powinno być instancją WindowsIdentity

Answer 3

Twój RolePrincipal, zaktualizowany w porozumieniu ze swoim RoleProvider, powinno być wszystko, co jest potrzebne, aby pobrać listę ról związanych z uwierzytelnionego użytkownika. Pamiętaj, że RolePrincipal będzie już zawierać odpowiednie WindowsIdentity.

Nie potrzebujesz niestandardowego atrybutu Authorize. RolePrincipal/RoleProvider pobierze potrzebne role i będzie działać ze standardowym atrybutem Authorize.

To, co wydaje się nieco dziwne, polega na tym, że chcesz, aby role były specyficzne dla Twojej aplikacji, ale mówisz, że chcesz również, aby role, które są powiązane z użytkownikami systemu Windows, również były przechowywane w oddzielnym magazynie korporacyjnym. Jak powiedziałeś, chcesz je połączyć. Nie wydaje mi się to właściwe. Albo chcesz zarządzać rolami na poziomie firmy dla swojej aplikacji, albo chcesz zarządzać nimi na poziomie lokalnym. Zasadniczo nie zrobiłbyś obu.

Ale jeśli tak naprawdę jest to, co chcesz zrobić, to brzmi to tak, jakby Twój RoleProvider musiał wykonać wywołanie usługi (np. WCF) lub wywołanie AD, aby uzyskać dodatkowe informacje. Być może nazwy "grup", do których należy użytkownik systemu Windows, mogą służyć jako "role". Odfiltrujesz tylko te grupy, o które troszczy się twoja aplikacja, i połączysz je z rolami znalezionymi w lokalnych bazach danych ról.

Po zebraniu wszystkich tych informacji należy się upewnić, że rola Menedżer zarządzający zapisuje informacje o rolach w pliku cookie. Nie ma sensu przechodzić przez ten hullabaloo przy każdym żądaniu użytkownika.