Webdevelopment op Windows .NET Server 2003

Door Michiel van Otegem
25 juni 2003

Met de komst van het .NET Framework vorig jaar is het leven van webdevelopers dramatisch veranderd. De komst van Windows .NET Server 2003 doet daar nog een schepje bovenop met ondersteuning van .NET Framework versie 1.1, en de nieuwe versie van Internet Information Server. We brengen de belangrijkste veranderingen voor webdevelopers in kaart.

Sinds de komst van het .NET Framework is webdevelopment uitgebreid met ASP.NET. ASP.NET combineert het gemak van scripttechnieken zoals ASP en PHP, met een intuïtief programmeermodel dat veel lijkt op het model dat Visual Basic en Delphi ontwikkelaars al jaren gewend zijn voor desktop applicaties. Daarbij is ASP.NET ongekend stabiel, helemaal voor Microsoft begrippen. Dit alles heeft ervoor gezorgd dat het .NET Framework vooral onder ASP ontwikkelaars zeer positief ontvangen is, en dus ook in die hoek de meeste aanhang heeft. Dit wordt verder gestimuleerd door de actieve participatie van het ASP.NET team in de internationale community, en de uitgebreide website www.asp.net die het team heeft opgezet. Een probleem blijft echter de ondersteuning van ASP.NET bij hosting providers. Er zijn wel enkele hosting providers die zich gewaagd hebben aan ASP.NET ondersteuning op Windows 2000, maar de meeste wachten toch op de komst van Windows .NET Server 2003. Een belangrijke reden daarvoor is dat alle ASP.NET applicaties op Windows 2000 in principe onder dezelfde gebruiker uitgevoerd worden (de ASPNET gebruiker), waardoor de verschillende websites op beveiligingsniveau niet van elkaar gescheiden zijn. Dat betekent bij shared hosting dat website A via code toegang zou kunnen krijgen tot de bestanden van website B.
Een bijkomend probleem is dat onder versie 1.0 van het .NET Framework de rechten van ASP.NET applicaties en componenten alleen ingesteld kunnen worden op basis van de gebruiker en een Access Control List (ACL). Desktop applicaties onder het .NET Framework kunnen verder beperkt worden op basis van Code Access Security, maar dat kan in versie 1.0 nog niet met ASP.NET. Al deze problemen moeten met Windows .NET Server 2003 tot het verleden behoren, waardoor .NET nu ook helemaal klaar is voor shared hosting.

Veranderingen aan de server

Windows .NET Server 2003 is in een aantal opzichten behoorlijk anders dan Windows 2000 Server. De meest voor de hand liggende wijziging is de standaard ondersteuning van het .NET Framework (behalve in de 64-bit versie). Op Windows 2000 en XP is het .NET Framework niet standaard beschikbaar, en dien je het dus apart te installeren. Verder is Internet Information Server (IIS) standaard niet geïnstalleerd, in tegenstelling tot de serverversie van Windows 2000. Dit voorkomt dat hackers misbruik kunnen maken van zaken waarvan de systeembeheerder mogelijk niet eens weet dat ze er zijn. Ook na de installatie van IIS is dit beleid van kracht, en zijn alle extensies voor dynamische content, zoals .asp (ASP) en .aspx (ASP.NET) geblokkeerd. Je kunt er als ontwikkelaar dus niet meer vanuit gaan dat je applicaties zonder meer werken als je de bestanden op de server zet. Voor zover je dit dus al niet in samenspraak met de systeembeheerder deed, moet je dit nu wel doen. Zowel ASP.NET als ASP kunnen eenvoudig geactiveerd worden via de Internet Information Services Manager, zoals te zien in afbeelding 1.

Code Access Security

Code Access Security (CAS) bepaalt wat een applicatie of component mag op basis van een trust level. Je kunt dit het beste vergelijken met de beveiligingszones die je kunt instellen in Internet Explorer (IE). Standaard bevat IE zones voor Internet, Local intranet, Trusted sites, en Restricted sites. Voor websites in de Restricted sites zone zijn Java, JavaScript, ActiveX en dergelijke zaken uitgeschakeld. Hierdoor kan een pagina bijvoorbeeld niet eens een pop-up laten verschijnen. De code daarvoor kan wel in de pagina staan, maar wordt niet uitgevoerd. Websites in Local intranet hebben juist veel rechten en kunnen al deze zaken wel gebruiken. CAS werkt met hetzelfde principe, maar definieert zones binnen de eigen computer voor applicaties. Normale desktop applicaties hebben bijvoorbeeld alle rechten (full trust), terwijl applicaties die gedownload zijn zeer beperkte rechten hebben. Dit heeft verder niets te maken met de applicatie zelf. Een applicatie mag niets in de Internet Downloads zone, maar als je dezelfde bestanden kopieert naar een locatie waar Full Trust ingesteld staat, dan heeft het alle rechten, zoals te zien in Afbeelding 2. Afbeelding 3 laat de .NET configuratie manager zien met de rechten voor de Internet zone. Zoals je kunt zien kan heeft een applicatie onder die zone wel rechten om te printen, maar niet om naar de Event Log te schrijven.

Afbeelding 3, Code Access Security instellingen van de Internet zone

In .NET Framework versie 1.0, is CAS niet beschikbaar onder ASP.NET. Alle ASP.NET applicaties werken daarom onder Full Trust, en kunnen dus in principe alles. Hieronder valt niet alleen toegang tot het bestandssyteem, maar ook tot allerlei andere systeembronnen. Ook mogen ASP.NET applicaties dus zogenaamde Unmanaged Code uitvoeren.
Unmanaged Code is code die niet door de Common Language Runtime geverifieerd wordt, en dus direct met het operating systeem en de hardware kan communiceren. De mogelijkheden van Unmanaged Code zijn dus ongekend, en is een potentiële bron van kwaad. Onder versie 1.0 kon het ontbreken van CAS redelijk ondervangen worden door gecertificeerde Assemblies apart rechten toe te kennen, maar een ASP.NET pagina wordt automatisch gecompileerd tot Assembly op het moment dat iemand de pagina opvraagt. Deze dynamische assemblies kunnen niet beveiligd worden, omdat ze veranderen als een pagina verandert.
Dit is waar CAS een zeer belangrijke rol speelt, omdat daarmee voor de hele applicatie bepaald kan worden welke rechten het heeft, door de applicatie een bepaald Trust Level te geven. De CAS instellingen van ASP.NET staan in machine.config of web.config, onder de afdeling system.web. Behalve voor Full Trust moet voor ieder Trust Level een apart bestand gemaakt worden dat beschrijft welke rechten het betreffende Trust Level heeft. In machine.config of web.config wordt naar dit bestand verwezen, zoals te zien in listing 1.

.Net Framework versie 1.0 versus 1.1

Welke versie een ASP.NET applicatie gebruikt is helaas niet in te stellen via de code in listing 2. Je kunt dit echter wel instellen in de Internet Information Services Manager, en kan voor alle applicaties in IIS of voor bepaalde applicaties. Je doet dit door een andere ISAPI filter in te stellen in het Application Configuration venster voor de bestandsextensies die uitgevoerd worden door ASP.NET. In Windows .NET Server 2003 is dit standaard het filter dat staat in C:\Windows\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll (zie afbeelding 4), maar als .NET Framework versie 1.0 ook geïnstalleerd is, kun je dit wijzigen in C:\Windows\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll. Helaas moet dit dus door de beheerder gedaan worden, en kunnen ontwikkelaars hier zelf geen invloed op uitoefenen.

Afbeelding 4: ASP.NET ISAPI filter instellen

Een belangrijke wijziging ten opzichte van versie 1.0 is dat de web controls voor mobiele applicaties nu standaard onderdeel uitmaken van het framework. In versie 1.0 waren deze controls alleen beschikbaar na installatie van de ASP.NET Mobile Internet Toolkit. Dit is dus vooral goed nieuws voor ontwikkelaars die met ASP.NET applicaties maken voor mobiele telefoons, PDA's, en andere mobiele devices.

Internet Information Server 6.0

Een van de onderdelen die in Windows .NET Server 2003 de grootste metamorfose heeft ondergaan is IIS. Hoewel dit betrekkelijk weinig invloed heeft op het ontwikkelen van ASP.NET applicaties, is het toch goed om te weten hoe IIS nu in elkaar zit. IIS is helemaal opnieuw ontworpen en geïmplementeerd, en gaat uit van een geheel nieuwe architectuur (zie afbeelding 5). Bij het maken van de nieuwe architectuur hebben veiligheid en betrouwbaarheid een centrale rol gespeeld. IIS is daardoor opgedeeld in 3 verschillende stukken die min of meer geïsoleerd van elkaar werken. Problemen in een van de delen hebben geen invloed op de andere, en mocht iemand door de beveiliging van een van de delen heen breken, dan is ook dat beperkt tot het betreffende deel. Wat dat betreft is IIS 6.0 goed te vergelijken met een boot waarin aparte compartimenten zorgen dat de boot niet zinkt als er ergens een lek ontstaat.

Afbeelding 5: architectuur van IIS 6.0

IIS 6.0 bestaat uit de HTTP Service (HTTP.SYS), de Web Administration Service (WAS), en één of meerdere Application Pools. Hierbij is de HTTP Service verantwoordelijk voor het ontvangen van de binnenkomende requests, welke vervolgens doorgegeven worden aan de juiste Application Pool, die verantwoordelijk is voor het uitvoeren van de request. WAS zorgt voor de configuratie en houdt de werkerprocessen in iedere Application Pool in de gaten. Als een van de werkerprocessen vastloopt of teveel geheugen verbruikt, dan start WAS een nieuw werkerproces om het werk van de oude over te nemen. Daarna stopt WAS het oude proces. WAS kan werkerprocessen ook stoppen als ze lang niets te doen hebben, om zo systeembronnen te sparen. Verder kan WAS er ook voor zorgen dat werkerprocessen automatisch gerecycled worden na een bepaalde hoeveelheid tijd, na een bepaalde hoeveelheid requests, of op een bepaald tijdstip. Hiermee kun je problemen aanpakken voordat ze überhaupt ontstaan.
Normaal gezien worden alle applicaties uitgevoerd door de Default Application Pool. Dit betekent dat een probleem in een applicatie van invloed kan zijn op een andere applicatie, omdat ze binnen hetzelfde proces uitgevoerd worden. Om dit te voorkomen kun je verschillende applicaties door verschillende Application Pools laten uitvoeren. Hiervoor dien je eerst een nieuwe Application Pool aan te maken met de Internet Information Services Manager. Vervolgens moet je voor iedere applicatie die je door de betreffende Application Pool wilt laten uitvoeren de betreffende Application Pool instellen via de Home Directory tab in het eigenschappenvenster van de applicatie (zie afbeelding 6).

Afbeelding 6, Application Pool instellen

Het is niet verstandig om onbeperkt Application Pools aan te maken, want iedere Application Pool vergt extra systeembronnen. Hoe minder Application Pools er zijn, hoe sneller alle applicaties werken. Die snelheid gaat wel ten koste van een stukje zekerheid, net zoals het een stuk minder veilig is om met 200 kilometer per uur over de A4 te scheuren. Ook dat doe je alleen als het niet druk is op de weg (en de politie niet toekijkt).
Per Application Pool kun je de instellingen rond de recycling van werkerprocessen en probleem detectie instellen via het eigenschappenvenster. Hierin kun je onder andere instellen wanneer werkerprocessen gerecycled moeten worden, en hoe vaak WAS moet controleren of alles nog in orde is. Ook kun je hier instellen hoeveel werkerprocessen een Application Pool minimaal moet bevatten. Deze instellingen zijn echter allemaal voornamelijk het domein van systeembeheerders en dienen voor de tuning van IIS.

Conclusie

Al met al is er met de komst van Windows .NET Server 2003 niet zo gek veel veranderd voor ontwikkelaars, behoudens de functionele wijzigingen aan het .NET Framework. Wel kunnen we rustiger slapen, omdat de algehele beveiliging en betrouwbaarheid van Windows .NET Server 2003 veel beter lijkt te zijn dan die van z’n voorgangers, waarbij er geen waarmneembare consessies zijn gedaan op het gebruiksgemak en de snelheid. Vooral voor hosting providers zullen veel voordelen hebben van een overstap. Belangrijk voor hen is ook de speciale Windows Server 2003 Web Edition, een versie die specifiek bedoeld is als webserver, tegen een gereduceerde prijs (circa 40% van de Standard Edition). Voor andere bedrijven biedt een overstap minder significante voordelen, hoewel Windows .NET Server 2003 kwalitatief een veel beter product is dan z'n voorgangers.