Stel: je maakt een website maar je wilt niet dat iedereen deze website kan bezoeken. Of je wilt dat een bepaald deel van de website wordt afgeschermd. Dan wil je dus dat gebruikers van je website zich aanmelden met een inlognaam en password. Als beheerder of ontwikkelaar zul je moeten beslissen welke authenticatie je wilt gebruiken. Er zijn echter een heleboel keuzes die je kunt maken als je gebruikt maakt van IIS als webserver.

Stel: je maakt een website maar je wilt niet dat iedereen deze website kan bezoeken. Of je wilt dat een bepaald deel van de website wordt afgeschermd. Dan wil je dus dat gebruikers van je website zich aanmelden met een inlognaam en password. Als beheerder of ontwikkelaar zul je moeten beslissen welke authenticatie je wilt gebruiken. Er zijn echter een heleboel keuzes die je kunt maken als je gebruikt maakt van IIS als webserver.
IIS
Hierboven zie je de mogelijkheden die je hebt als je gebruik maakt van IISv6, het nieuwere IIS7 heeft dezelfde opties. Hieronder volgt een uitleg over keuzes die je kunt maken.
Anonymous access
Simpel, Anonymous is anoniem, de service waar je gebruik van maakt weet niet wie je bent en heeft daar ook geen behoefte aan. Echte Anonymous authenticatie bestaat echter niet in de ogen van Microsoft, alle acties die op een Windows systeem plaats vinden worden door een bepaald account gedaan, dus ook bij IIS. Als er op een IIS Server anoniem wordt ingelogd, dan kiest IIS er standaard voor het IUSR_computername account te gebruiken voor alle acties. Let er hierbij op dat de IUSR_computername lid is van de Guest groep, dus overall waar de Guest groep toegang tot heeft, heeft de IUSR ook toegang. Zoals je in de screenshot ziet heb je uiteraard de mogelijkheid om een ander account te gebruiken.
Windows Authentication
Alle andere vormen van authenticatie is, in de ogen van IIS, Windows Authenticatie. Bij Windows Authenticatie wordt de gebruiker van de website een apart scherm getoond waarin om de inloggegevens (ookwel credentials) wordt gevraagd. Voor alle vormen van Windows Authenticatie geldt dat de inloggegevens overheen moeten komen met de naam en password van een gebruiker van het betreffende Windows systeem (local logon) of het domein waar het de IIS-server lid van is (domain logon). Deze inloggegevens worden dan ook niet enkel gebruikt voor authenticatie van een website maar voor allerlei services in een Windows omgeving. Denk hierbij bijvoorbeeld aan toegang tot een bepaalde share op een netwerk. Dit zorgt voor eenvoud omdat gebruikersaccounts nu maar één keer aangemaakt dienen te worden en gebruikt kunnen worden voor meerdere services op meerdere Servers.
  • HTTP Authentication
    HTTP authenticatie wordt enkel gebruikt voor authenticatie in een browser, maar maakt zoals gezegd maakt HTTP authenticatie gebruik van de reeds aanwezige Windows accounts. Een vaak genoemd nadeel van HTTP Authenticatie is dat de gebruiker oneindig vaak kan proberen zijn naam en password in te geven. Hackers kunnen hier dus gebruik van maken door m.b.v. password-guessing methoden in te loggen.
    • Basic authentication
      Bij Basic Authenticatie wordt de gebruiker een scherm getoond waarin wordt gevraagd naar een naam en een password. Zowel de naam als het password worden niet versleuteld over het netwerk verstuurd. Hierdoor is het mogelijk dat de naam en het password door een zogenaamde sniffer-applicatie worden opgepikt. Een sniffer is een applicatie dat op een network kijkt naar pakketjes die eigenlijk niet voor hem bestemd zijn. Dit probleem door gebruik bijvoorbeeld gebruik te maken van een SSL verbinding. Hiermee wordt echter wel al het netwerkverkeer versleuteld, wat weer performance problemen kan opleveren. Encryprie is immers erg intensief rekenwerk.
    • Digest authentication
      Het verschil tussen Basic en Digest is dat passwords bij Digest authenticatie wel versleuteld worden. Hiervoor wordt gebruik gemaakt van hashing. Hashing is een bepaalde berekening die uitgevoerd wordt op een binaire reeks, in dit geval het password. Deze berekening levert een getallenreeks op. Ongeacht de lengte van het password is de uitkomst van de berekening altijd even lang. Kenmerkend aan hashing is dat de getallenreeks niet gebruikt kan worden om het password te berekenen. Een ander kenmerk is dat als in het password maar één letter verandert, de bijbehorende hash totaal anders is. Als de gebruiker zijn password heeft ingetypt wordt de bijbehorende hash berekend en deze wordt naar de server gestuurd. De server weet wat de hash van het password is (de server weet niet wat het password is). Als de verkregen en opgeslagen hash waarden overheen komen is het password correct.
  • Integrated Windows Authentication
    Het voordeel van IWA ten opzichte van HTTP authenticatie is dat een gebruiker helemaal geen inloggegevens hoeft in te typen. Er wordt namelijk gebruik gemaakt van de inloggegevens waarmee de gebruiker is ingelogd op zijn computer. Mochten deze inloggegevens niet valide zijn, dan volgt er alsnog een inlogscherm. Als een gebruiker inlogt zonder zijn inloggegevens in te typen spreek je over een non-interactive login, de interactive logon heeft immers al plaatsgevonden tijdens het inloggen op de computer. Voor het gebruik van non-interactive logon dien je echter wel Internet Explorer als browser te gebruiken. Daarnaast is inloggen met behulp van IWA een stuk veiliger. Er bestaan 2 vormen van IWA, NTLM en Kerberos.
    • NTLM (NT LAN Manager)
      NTLM deed zijn intrede met de komst van Service Pack 4 voor Windows NT. Bij NTLM wordt gebruik gemaakt van een challenge-response mechanism. Dit betekent, eenvoudig gezegd, dat de server een vraag (challenge) stelt aan de client waar de client het juiste antwoord (response) op moet geven. De volgende stappen vinden plaats bij NTLM authentication:
        • Een gebruiker logt in met zijn naam, password en een domeinkeuze. De naam en domeinkeuze worden opgeslagen. Van het password wordt een hash berekend en deze wordt ook opgeslagen. Passwords worden nimmer opgeslagen.
        • Als men vervolgens een service op een server wil gebruiken stuurt de client de inlognaam naar de server (niet versleuteld).
        • Challenge: De server stuurt een willekeurig nummer naar de client.
        • Response: De client versleuteld de challenge samen met een hash van zijn password en stuurt dit naar de server.
        • De server stuurt de challenge, de response en de username naar een Domain Controller.
        • De domain controller kan met behulp van de verkregen username de bijbehorende password-hash opzoeken in zijn database. De Domain controller weet dus de username, de password-hash en de challenge. Hiermee kan de response opnieuw worden berekend. Als de verkregen response hetzelfde is als de ontvangen response, is de authenticatie succesvol.
    Het is u misschien niet opgevallen, maar in bovenstaand voorbeeld heeft de server op geen enkel moment het password van de client geweten. Toch heeft de client zich geauthenticeerd bij de server.
    • Kerberos
      Kerberos deed zijn intrede met de komst van Active Directory (Win2000). Kerberos (Cerberus) is volgens oude geschriften een hond met drie hoofden die de ingang van het vurige hiernamaals bewaakt. In het geval van Kerberos authenticatie hebben we ook te maken met 3 systemen die een toegang bewaken. Dat zijn de client, de server en de Key Distribution Center. De KDC is een partij die door zowel de client en de server wordt vertrouwd. De domain controller neemt altijd de rol van KDC op zich. Als een client wil communiceren met een server dan zal er een communicatiekanaal moeten worden opgezet. Voor deze communicatie wordt een sleutel gegenereerd, die enkel geldig is voor de duur van de communicatie. De KDC is de verstrekker van deze sleutel en zal deze naar beide andere partijen distribueren op een manier zodat geen enkel andere partij deze sleutel kan onderscheppen. De Exacte werking van het kerberos principe is te uitgebreid voor deze blog. Voor een goede uitleg over kerberos deze link een aanrader.
Forms Based authentication
Bij FBA wordt geen gebruik gemaakt van inloggegevens opgeslagen door Windows. Binnen IIS hoeft daar dus ook niets geregeld te worden. Het is in deze aan te raden om IIS authentication op Anonymous te laten staan. De inloggegevens, oftewel credentials, van FBA worden opgeslagen een aparte database. FBA wordt dan ook enkel gebruikt voor web-services. Het inlogscherm is dan ook geen apart venster zoals bij Windows Authentication maar gewoon een onderdeel van de HTML code die je browser laat zien. Voor de werking van FBA is ASP nodig, dat is een onderdeel van het Microsoft .Net Framework en is bedoeld voor het ontwikkelen van web-based services. Twee bekende services die gebruik kunnen maken van FBA zijn Outlook Web Access (een onderdeel van Exchange) en Sharepoint. Mogelijke databases voor het opslaan van de credentials zijn SQL Server en XML. Tegenwoordig is het ook mogelijk je Microsoft Live-ID hiervoor te gebruiken. Dus één account voor services van verschillende partijen.
Forms Based authentication
De toekomst
Hoe je het ook went of keert, in alle bovengenoemde mogelijkheden zal de gebruiker een inlognaam en password moeten intypen. Helaas kiezen veel gebruikers voor passwords die gemakkelijk te raden zijn, zeker als de gebruiker een bekende is van de hacker. Ook kiezen gebruikers ervoor om passwords op te schrijven om ze niet te vergeten. Ook dit is een mooie kans voor een hacker om een password te achterhalen.Het beste password is dus geen password maar een andere methode om te achterhalen wie er gebruik wil maken van een bepaalde service. In de toekomst zullen gebruikers zich waarschijnlijk authenticeren met behulp van biometrie, zoals een irisscan of een vingerafdruk. Er zijn reeds laptops te koop waarbij een vingerafdruk gelezen kan worden.