zondag, september 14, 2008

ISAPI filters are bad, mkay?

Ik heb een grondige hekel aan ISAPI filters. Ze zijn geschreven in een idiote programmeertaal (C++), ze zijn niet te debuggen en ik snap er geen bal van. Maar dat terzijde.

Op mijn werk heb ik een zeer interessant probleem. Ik wil een website beveiligen met windows security om zo de mogelijkheid te hebben tot single sign-on. Nu zijn er echter een paar moeilijkheden: de webserver heeft geen toegang tot het domein en de website moet ook bereikbaar voor de buitenwereld. En dat betekent dat ik in IIS niet "allow anonymous access" uit kan zetten. Nu is het zo dat de browser niet direct vanuit zichzelf de authenticatie gegevens meestuurt. Daarvoor moet hij eerst een 401 unauthorised (met www-authenticate: ntlm) voor krijgen.

Wat de browser dan probeert is de huidige credentials van de gebruiker toezenden. Pas als het dan weer een 401 krijgt, krijgt de gebruiker een popup voor username en wachtwoord. De username komt uiteindelijk in de server variabele AUTH_USER.

Om dat gedrag te faken had ik het volgende bedacht: op het moment dat de AUTH_USER niet gezet is geef ik de browser een 401 terug. De browser stuurt de credentials terug, ik lees die uit en log in mijn code deze gebruiker in. Tot zover de theorie.

In de praktijk blijkt dat de 2e request nooit bij asp.net aankomt. IIS zit dwars, het hele NTLM protocol wordt door IIS afgehandeld. Wat ik ook probeer met HTTPModules en HTTPHandlers ik kan niet in dit authenticatie proces inbreken.

Dus zit er maar 1 ding op: dichter op IIS kruipen oftwel: ISAPI filters. De rillingen lopen me al over de rug. Zeker omdat ik foutcodes krijg als: 0x80004005 & "The specified module could not be found.". De rillingen lopen al over mijn rug... Misschien heeft collega R. nog wat voorbeeldcode voor me?

Geen opmerkingen: