Aan het werk met WS-Federation

Nu we gewend zijn aan internet presence komen we bij de tweede generatie vraagstukken. We hebben inmiddels publieke sites en beveiligde sites. Deze laatste is voor eigen personeel of voor zakenpartners. Maar dat is aan het veranderen: steeds vaker worden we geconfronteerd met te beveiligen B2C-scenario’s. Ik wil een beveiligde site op uitdagendebaan.nu, waarop kandidaten voor een high potential job kunnen overleggen met onze PZ-mensen. Die site zal een afwijkende naam hebben, zodat die niet onder de reguliere website kan hangen e bijbehorende beveiligingsmiddelen. En dan wordt het moeilijk. Of duur. Hoogstwaarschijnlijk allebei.

Wat is nu precies het probleem. Als je gebruikers op een beveiligde site toegang wil geven, heb je twee componenten nodig: een beveiligingsmechanisme en een lijst van gebruikers. Het beveiligingsmechanisme zorgt ervoor dat alleen bekende gebruikers bij je site of delen van je site kunnen komen. Die gebruikers staan in je gebruikerslijst, vaak één of andere directory. Dat zal een systeem zijn waar mensen hun eigen accounts in kunnen aanmaken, of een al bestaand register bij een andere partij.

Nu bestaan er tal van producten die je kunt inzetten om een webserver of domein te beveiligen. In principe gebruiken ze allemaal een vergelijkbaar mechanisme. Het eerste dat het mechanisme moet kunnen is het creëren van een ‘sessie’. Webverkeer heeft van zichzelf geen sessie, dus je weet niet welke request bij welke bezoeker hoort. Daar kun je niets aan beveiligen. De meest gebruikelijke manier om het toch te kunnen, is het plaatsen van een cookie op de machine van bezoeker. Zo kun je vaststellen dat iemand zich eerder bekend heeft gemaakt op je site. Toen we dit een tijdje gebruikt hadden kwamen mensen erachter dat je met een cookie de identiteit van een gebruiker kon stelen.

Daarop bedachten we dynamische cookies, die maar één sessie geldig waren. Om ze veilig te maken werden ze versleuteld en gebonden aan het verstrekkende domein. Probleem opgelost. Het volgende probleem is dat je per domeinnaam een afzonderlijk beveiligingssysteem moet gebruiken.

Het vraagstuk

Océ werd geconfronteerd met de beperking van bovengenoemde cookie beveiliging toen het bedrijf wisselde van internet naming strategie. Voorheen viel alles onder oce.com, nu ging ze naar een domein per land. Oce.com is één domein, maar oce.de is een ander domein. Aan oce.com was de beveiliging gekoppeld, wat niet gaat werken. in de nieuwe situatie.

Ik kreeg de opdracht om een Proof of Concept (PoC) te bouwen om dit op te lossen. Dat is een leuke klus. De problematiek is natuurlijk niet uniek voor Océ. Er zijn verschillende oplossingen mogelijk. In de regel gaan de producten er van uit dat naast afzonderlijke domeinen, er ook sprake is van meerdere user directories. De kans is groot dat je een te krachtig maar daarmee ook te complex en kostbaar product neerzet. Kenmerkend voor de meeste aanbieders van oplossingen is dat er een grote toolset aangeboden wordt, die een waslijst van functies en verschillende inzetscenario’s onder- steunt. In de Gartner magic quandrant van oktober 2007 zie je alleen maar aanbieders van complete maar complexe oplossingen. Opmerkelijk afwezige in dit overzicht is Microsoft, terwijl zij de IAM/SSO-markt sinds begin 2006 weer prominent in haar roadmaps opneemt. De meeste producten zijn door hun licentiemodel niet geschikt voor B2C-scenario’s. Als je per user 0 euro moet betalen, ziet je plaatje voor een B2C-site er opeens weinig florissant uit. Een zo gangbaar vraagstuk als Identity Federatie moet inmiddels toch opgelost kunnen worden met een eenvoudige case-tool, al dan niet open source.

Gegeven de infrastructuur, de budgetten en de ondersteunbaarheid zou een oplossing uit de Microsoft-koker Océ goed uitkomen. In theorie biedt Microsoft met ADFS (sinds Windows 2008 AD FS) een WS-Federation oplossing. ADFS valt onder de licentie van Windows 2003 Enterprise R2, die al aanwezig was. En alleen de ADFS-server zélf heeft die licentie nodig, wat je op de andere servers moet installeren is gratis.

Het vervelendste wat bleek met ADFS is dat federation in de praktijk over het koppelen van gebruikersdirectories gaat, niet over ons vraagstuk met meerdere losse domeinen. Dat zie je terug in de documentatie, die ruimschoots aandacht geeft aan directory federatie. Cross domain webSSO komt er daarentegen nogal bekaaid af. Dus we moesten gaan herleiden hoe een en ander eruit zou moeten zien.

Hoe werkt het?

In principe werkt WS-Federation als volgt. Gebruiker gaat naar webserver 1. Deze controleert of de gebruiker het juiste cookie heeft. Als dit niet zo is, worden de requests doorgezonden naar de achterliggende federation server, die het aanloggen verzorgt. Na succesvol aanloggen heeft de user het juiste cookie. Zodra de user in dezelfde sessie naar webserver 2 (in een ander domein) gaat, controleert deze bij dezelfde achterliggende ADFS-server het cookie, via SAML-communicatie. Is dat aanwezig, dan hoeft de gebruiker niet opnieuw aan te loggen. En andersom: als een gebruiker uitlogt uit server 1, dan wordt de sessie ook voor server 2 afgesloten.

In deze Proof of Concept besloten we de omgeving gefaseerd op te bouwen. Daarvoor maakten we eerst kopieën van de live omgeving voor webhosting. Daarin zetten we een ADFS-server en een geclusterde IIS-webserver, met twee sites in verschillende domeinen. De omgeving had verder een eigen DNS en een eigen user directory, een ADAM-server, ook van Microsoft. In een latere stap zouden we dan de ISA-servers in een load balancing rol neerzetten.

Voor de PoC besloten we als testapplicatie de zogenaamde Claimapp uit de labs van Microsoft te gebruiken. Deze toont de sessie informatie, zodat je kunt zien hoe de gebruiker ingelogd is.Voor het uitvogelen van de puzzel kregen we onverwacht veel hulp van de uitbater van een identity federation-blog, Joe Kaplan, die klokje rond onze moeilijke vragen beantwoordde, als we het antwoord al niet op zijn site konden vinden.

Hobbels

Het meeste werk (en ook het meest foutgevoelige deel) bleek het inrichten van de certificaten en de URL’s van de webapplicaties te zijn. ADFS gebruikt request forwarding om te zorgen dat de user de juiste cookies heeft en alle communicatie wordt versleuteld met dual side SSL. Dus als er ergens een referentie verkeerd staat, breekt het geheel direct. De certificaten moeten de exacte paden naar de testapplicatie bevatten voor het https-verkeer. De certificaten waarmee het interne (SAML-)verkeer naar de Federation server wordt beveiligd zijn iets minder kritisch. Het inrichten was na deze hobbels verder rechttoe rechtaan. Binnen anderhalve dag draaide de basisvoorziening en was aangetoond dat WS-Federation in een praktijk omgeving werkt. Het toevoegen van ISA2006 was eveneens erg simpel, een gevreesd conflict met cookies bleek denkbeeldig.

Wat is SAML

SAML staat voor Security Markup Language, een op XML gebaseerde protocol voor de beveiligde uitwisseling van authenticatie- en autorisatiegegevens tussen verschillende domeinen. Op dit moment ondersteunen de meeste webserverproducten SAML 1.1, dat in 2003 geformaliseerd is. Ondersteuning voor het uitgebreidere SAML 2.0 is nog beperkt. SAML 2.0 is niet backwards compatible.

Om er echt gebruik van te kunnen maken, is er natuurlijk nog een waslijst aan vragen. Zo is er de omgang met een beveiligd en een onbeveiligd deel van de site. Deze vraag was eenvoudig: zo lang de user niet uitlogt danwel de browser afsluit, blijft de sessie in stand. Ook als de gebruiker naar een onbeveiligd deel gaat. Andersom kan lastiger zijn: als een gebruiker eerst anoniem toch een zekere identiteit krijgt en dan pas aanlogt op het beveiligde deel, dan kan de eerste identiteit verloren gaan. Dat hoeft echter niet, als je zorgt dat de cookies naast elkaar kunnen bestaan. Als je van de standaardinstellingen afblijft, gaat dat prima.

De tweede vraag was of het een Microsoft only oplossing is. In principe is dit zo, maar omdat WS-Federation een open standaard is zou dit niet zo mogen zijn. In ieder geval zijn er loadable modules voor Apache webservers beschikbaar, dus je moet een eind kunnen komen.

De derde vraag is in hoeverre het geheel samen kan werken met bestaande beveiligingsarchitecturen, in het bijzonder met op URL gebaseerde toegangsbeveiliging. Nu zijn de URL’s van ADFS zelf statisch, dus deze kunnen onder de oudere technologie beveiligd worden. Bovendien kun je ook dezelfde achterliggende directory, al dan niet Active, gebruiken. Dus een zekere mate van vermenging is denkbaar. Het primaire mechanisme, de login-applicatie, zal echter specifiek voor ADFS blijven. En ADFS is vanwege de claims based architecuur in essentie een geheel andere benadering, waardoor het mengen altijd kunstmatig zal aanvoelen.

Claim based beveiliging

De noodzaak van claimbased beveiliging is gelegen in de behoefte aan universeler beveiliging in de webapplicatie dan wat het traditionele model van rollen aan mogelijkheden biedt. Rollen zijn persoonsgebonden terwijl claims ook aan groepen of andere domeinen gekoppeld kunnen worden. Zo kun je iedereen die werkt bij firma X een bepaalde reeks rechten geven, en iedereen met een identiteit van onfhankelijke Identity provider Y een andere reeks. Daarmee vormt de claims based benadering een cruciaal onderdeel van de federatieve wereld van Internet 2.0.

Nu zal niet iedere organisatie toe zijn aan Internet 2.0. In de praktijk zul je dan ook een tijdje met een gemêleerd systeem werken. Maar als de onderliggende laag zo eenvoudig is als met ADFS, dan is de basis daadwerkelijk te leggen en kun je de noodzakelijke kennis en ervaring opdoen voor een succesvolle overgang naar de nieuwe ronde. En daar is het een goed moment voor, want het kunnen aanbieden van een meer persoonlijk internet met bijpassende veiligheid is de stap die je nu moet maken.

Auteur: Peter Rietveld

Peter Rietveld werkt als security consultant bij Traxion, specialist in identity management. Hij studeerde Veiligheidsproblematiek en Internationaal Recht in Utrecht. Op dit moment is hij ingezet als projectmanager bij de implementatie van SUN IdM bij Air France/KLM en als business consultant voor CapGemini Outsourcing. Eerder werkte hij onder meer voor Defensie, Justitie, het Radboud ziekenhuis, de Belastingdienst, ABN/AMRO, Fokker en Fortis.

Be Sociable, Share!

• 
•