Jaką rolę odgrywa „Pula aplikacji” dla puli aplikacji?

Mówiąc o bezpieczeństwie IIS 7.5, AFAIK:

Tożsamość puli aplikacji decyduje o tym, komu będzie działać moja aplikacja internetowa.

Metoda uwierzytelniania decyduje o tym, komu są uwierzytelniani klienci.

Mam skonfigurowany folder wirtualny w następujący sposób:

• Korzystam z uwierzytelniania anonimowego, oczekując, że wszyscy klienci powinni zostać uwierzytelnieni jako IUSR .
• Daję IUSR pełną kontrolę nad folderem.
• Moja tożsamość puli aplikacji jest ustawiona jako konto XXX, które nie ma żadnych uprawnień do tego folderu. (Celowo to ustawiłem)

Ale okazuje się, że nie mogę przeglądać plików w tym folderze. Po udzieleniu uprawnienia konta XXX dostępu do tego folderu wszystko idzie dobrze.

Jaką rolę odgrywa tożsamość puli aplikacji w anonimowym uwierzytelnianiu? Zupełnie nieoczekiwane jest to, że muszę udzielić konta App Pool Identity uprawnień dostępu do folderu. Myślałem, że wystarczy anonimowe uwierzytelnianie?

Dzięki.

Wiele przeciążonych warunków tutaj i zmiana między IIS 7 a 7.5.

Tożsamość puli aplikacji a konto puli aplikacji

Zacznijmy od tożsamości puli aplikacji (małe litery I, czyli konto w puli aplikacji ):

Mówię, że konto w puli aplikacji to konto używane do uruchamiania puli aplikacji oraz tożsamość, którą przyjmuje pula aplikacji, gdy nie podszywa się pod nikogo innego.

Niezależnie od tego, jaką tożsamość podasz puli aplikacji, będzie ona musiała być w stanie odczytać pliki w folderze zawartości : w szczególności {ale nie tylko} dowolne pliki web.config (które są częścią konfiguracji IIS i kontrolować, co App Pool będzie działać).

Jeśli nie może uzyskać dostępu do folderu, zakłada, że ​​może tam być ważny (zmieniający grę) plik web.config, i wyświetli błąd. Więc App Pool konta potrzebuje Czytaj dostęp do wszystkich folderów treści.

ApplicationPoolIdentity

Po co odróżniać konto puli aplikacji (tożsamość puli aplikacji) od tożsamości puli aplikacji? Ponieważ aplikacja ApplicationPoolIdentity używana przez specjalne stolice to nowy typ konta - konto usługi zarządzanej - wprowadzone i ustawione jako domyślne w IIS 7.5 / Windows 2008 R2, a także dostępne z Windows 2008 SP2 (ale nie domyślne).

Zobacz Tożsamości pul aplikacji na IIS.Net

Podczas tworzenia witryny w R2 za pomocą GUI:

• zostanie utworzona pula aplikacji do obsługi tej witryny, oraz
• typ konta to ApplicationPoolIdentity, zamiast usługi sieciowej (domyślnie 2008), usługi lokalnej lub systemu lokalnego.

W RTM 2008 domyślnym kontem puli aplikacji była usługa sieciowa oraz unikalny identyfikator / unikatowy zestaw puli aplikacji; nowa R2 / SP2 AppPoolIdentity typ konta jest Network-Service- jak konta (czyli jest komputer podczas podłączania off-box), ale zapobiega personifikacji innej puli aplikacji w tym samym oknie.

Powrót do pierwotnego pytania:

• Konto puli aplikacji określa , jak działa Twoja aplikacja, gdy nie podszywa się pod nikogo innego

• Metoda uwierzytelniania opisuje sposób uwierzytelnienia klientów (w celu podszywania się pod nich)

• Do kont użytkowników anonimowych określa, kim masz zamiar uruchomić jak podczas podszywanie się pod użytkownika o wniosku, który nie jest uwierzytelniony - IUSR jest taki łatwy.

Nawiasem mówiąc, w IIS 7.5 można ustawić Anonimowe konto użytkownika jako Tożsamość puli aplikacji (właściwości metody Anonimowego uwierzytelnienia), co może uprościć izolowanie i zabezpieczanie zawartości dla danej witryny.

Ustaw uprawnienia za pomocą IIS AppPool \ YourSiteName dla formatu nazwy. (zobacz także ten post )

Widzisz dwie rzeczy, które są często mylone w ASP.NET:

1. „tożsamość użytkownika” - Uwierzytelnianie konta użytkownika nie ma nic wspólnego z kontem lub tożsamością, która faktycznie działa zarówno w IIS, jak i ASP.NET. Anonimowe uwierzytelnianie umożliwia każdemu użytkownikowi dostęp do dowolnej treści publicznej bez podawania nazwy użytkownika i hasła do przeglądarki klienta. Anonimowe konto IUSR, które jest domyślnie uwierzytelniane w IIS, po prostu stosuje dostęp do treści publicznej witryny. Nie wpływa na procesy ani zasoby używane przez bazowe usługi IIs lub usługi ASP.NET.
2. „tożsamość aplikacji” - jest to rzeczywiste konto „WindowsIdentity” na serwerze, które faktycznie działa za IIS i ASP.NET, czyli kontem tożsamości puli aplikacji przypisanym do puli przez IIs i przekazanym ASP.NET. Twój proces ASP.NET domyślnie działa na tym koncie tożsamości puli aplikacji (zwanym kontem wirtualnym w IIs wersji 7.5+).

Objaśnienie: Po pierwsze, „uwierzytelnianie” w programie ASP.NET to po prostu zdarzenie zwykle konfigurowane w pliku web.config, które loguje dane konto użytkownika, które zostaje przekazane jako token użytkownika przez IIs do ASP.NET jako zwykły obiekt HttpContext ... tj. bieżąca sesja lub kontekst bieżącego użytkownika. W rzeczywistości nie zmienia WindowsIdentity, która uruchamia proces ASP.NET, po prostu przekazuje do niego token identyfikatora użytkownika. Korzystając z HttpContext, twój kod może używać tego identyfikatora lub nazwy do przechowywania praw do bazy danych w różnych sekcjach witryny. Ale nie wpłynie to na dostęp do pliku przez ASP.NET, ponieważ nie wpływa ani nie zmienia tożsamości rzeczywistego konta „procesu” aplikacji, które działa ASP.NET w IIs.

Nie dzieje się tak, dopóki nie wykonasz „Personifikacji”, która mówi ASP.NET, aby podszywał się pod token przekazywany mu przez IIs, a następnie uruchamiał się pod tym kontem. Możesz ustawić personifikację w swoim pliku web.config. Gdy aktywujesz personifikację w ASP.NET, WindowsIdentity zmienia się w procesie roboczym na dowolne uwierzytelnione konto przekazywane do ASP.NET z IIS, a następnie możesz uzyskiwać dostęp do plików, oczywiście na podstawie praw przypisanych do tego konta użytkownika. Ważne jest, aby pamiętać, że kiedy to nastąpi, jego tymczasowe i ASP.NET może powrócić do domyślnej tożsamości procesu, która jest w aktualnych wersjach IIs ponownie konta tożsamości puli aplikacji przypisanego do danej puli aplikacji.

Gdy usługi IIs po prostu używają zwykłego anonimowego konta użytkownika bez jawnego uwierzytelnienia ustawionego w programie ASP.NET, usługi IIs domyślnie uruchamiają konto tożsamości puli aplikacji przypisanej do witryny i przekazują je do programu ASP.NET oraz uruchomionego procesu roboczego. To konto tożsamości puli aplikacji przetwarza wszystkie żądania dotyczące usług IIS i uruchamia ASP.NET dla tej witryny.

Gdy II zaczyna się w tej konfiguracji i użytkownik ma do niego dostęp, w rzeczywistości domyślnie uwierzytelnia się za kulisami anonimowe konto IUSR, które określa dostęp do stron internetowych i innych podstawowych zasobów. Ale to konto NIE jest przekazywane do ASP.NET. I nie wpływa to na uruchamianie Tożsamości puli aplikacji IIS i na której ASP.NET działa.

Jeśli ustawisz Personifikowanie na „prawda”, powiedzmy na swój web.config, ORAZ używasz domyślnego anonimowego konta IUSR w IIs do publicznego dostępu, ORAZ ustawisz jawnie na true właściwość anonymousAuthentication w web.config (zamiast korzystania z systemu Windows lub inne konto logowania), II wyrzucą tożsamość puli aplikacji, a II i ASP.NET będą teraz uruchamiać swoje procesy aplikacji jako anonimowe uwierzytelnione i personifikowane konto IUSR.

Gdy to zrobisz, ASP.NET i jego procesy będą teraz działały na koncie IUSR .... tzn. Proces aplikacji ASP.NET uruchomi swoje konto WindowsIdentity jako konto IUSR. Możesz teraz zastosować dostęp do odczytu / zapisu do tego anonimowego konta IUSR i do folderów, do których konto ma mieć dostęp. (Uwaga: należy jednak dodać domyślne konto procesu, konto puli aplikacji dla puli, a także prawa do tych folderów. Zgodnie z zaleceniami Microsoftu)

Powodzenia!

W grze występują dwa konteksty uwierzytelnienia. Proces serwera WWW (który obsługuje żądania sieciowe) działa jako użytkownik tożsamości puli aplikacji. Gdy nadejdzie żądanie dotyczące wirtualnego hosta, pula aplikacji podszywa się pod użytkownika wymienionego w „Anonimowych poświadczeniach uwierzytelniania” określonej witryny - domyślnie IUSR.

Wszelkie skrypty uruchamiane z Twojej witryny będą działać jako IUSR, ale logowanie i niektóre inne funkcje będą działać jako użytkownik puli aplikacji (domyślnie usługa sieciowa - chociaż ostatnio została zmieniona, aby używać specjalnego użytkownika puli aplikacji wirtualnych). Tożsamość puli aplikacji (usługa sieciowa) musi być w stanie wyświetlić listę plików w katalogu, ponieważ pewne kontrole są wykonywane na stosie żądań przed przekazaniem kontroli do skryptu.

Dobrą praktyką jest uruchamianie jednej witryny na pulę i ustawianie tożsamości puli aplikacji na tego samego użytkownika, co na użytkownika anonimowego w witrynie. Możliwe jest wyrwanie się z kontekstu użytkownika anonimowego (IUSR) i podniesienie uprawnień do uprawnień samej tożsamości puli aplikacji.