Claims-based authenticatie in SharePoint 2010 MAAKT HET REALISEREN VAN DIVERSE SCENARIO’S MAKKELIJKER Mirjam van Olst
SharePoint 2010 maakt gebruik van claims-based authenticatie. Omdat claims-based authenticatie voor de meeste SharePoint developers en beheerders een nieuw concept is, volgt eerst een algemene uitleg over wat een claims-based identiteit is en hoe claims-based authenticatie werkt. Vervolgens zal de rol van Microsoft’s Geneva bij claims-based authenticatie aan bod komen. Hierna wordt ingezoomd op de werking van claims-based authenticatie in SharePoint 2010 en een aantal SharePoint scenario’s waarin de meerwaarde van claims-based authenticatie duidelijk naar voren komt.
Om uit te kunnen leggen wat claims-based identiteit is,
is het handig om eerst vast te stellen wat we eigenlijk verstaan onder ‘identiteit’. Omdat het niet de bedoeling is om van dit artikel een filosofisch artikel te maken, zal ik me beperken tot de digitale wereld. Een digitale identiteit is een hoeveelheid informatie over iemand of iets. Hoewel een identiteit ook kan slaan op een computer of een applicatie zal het in de meeste gevallen betrekking hebben op een persoon. Een digitale identiteit die over een netwerk verstuurd wordt, heet meestal een token. In het geval van een claims-based identiteit zal dit token één of meer claims bevatten. Een claim is een stukje informatie over de persoon waar de identiteit bij hoort. Een claim kan bijvoorbeeld zijn dat de naam van de persoon Justin is, dat hij in Amsterdam woont of dat hij 36 jaar oud is. Een claim kan echter ook zijn dat de persoon een manager is, of dat hij tot de groep systeembeheerders behoort. Om vast te stellen wie de token heeft uitgedeeld bevat deze naast claims ook een digitale ondertekening. Elk token wordt opgebouwd met behulp van SAML. SAML is een op XML gebaseerde
FIGUUR 1: SCHEMATISCHE WEERGAVE VAN EEN TOKEN.
standaard voor het beschrijven van authenticatie en authorisatie informatie. Figuur 1 is een schematische weergave van een token.
Security Token Service Tokens worden uitgedeeld en ondertekend door een Security Token Service, of STS. Dit werkt als volgt: 1.
Een clientapplicatie (vaak een web browser) vraagt een STS om een token met claims voor een gebruiker. Om een token te kunnen krijgen moet de aanvraag geauthenticeerd worden. Dit kan bijvoorbeeld met behulp van een kerberos ticket of door een wachtwoord aan de gebruiker te vragen. De aanvraag bevat meestal de gebruikersnaam van de persoon waar het token voor aangevraagd wordt en de url van de applicatie waar de persoon gebruik van wil maken.
FIGUUR 2: DE WERKING VAN DE STS
SharePoint special | december 2009
9
Als het een ICT-er is, zit hij bij Sogeti.
Wat kun je? Die vraag stelt ieder bedrijf met een vacature. Wie ben je? Die vraag stelt Sogeti
De projecten die je voor klanten uitvoert, variëren
meteen daarna. We vinden het belangrijk dat je bij ons past. Want een ICT-er van Sogeti is
enorm. Van portal realisaties tot het neerzetten
geen gemiddelde ICT-er. Het is er een met uitgesproken eigenschappen. Gedreven. Resultaatgericht. En niet snel tevreden. Natuurlijk: plezier hoort erbij. Maar we gaan op de eerste plaats voor de inhoud. Zo kennen klanten ons. Zo kennen we elkaar.
SharePoint-specialisten Stel, je hebt je gespecialiseerd in SharePoint.
van een collaboration omgeving voor 140.000 gebruikers. Ander voorbeeld: momenteel werken we aan de omvangrijkste integratie ooit van SharePoint in Dynamics CRM.
over SharePoint. We streven naar innovatie en
Interesse? Bel Lijnske Boogaarts of stuur haar je
doen mee met het SharePoint 2010 Evidence-
cv: (088) 660 66 00 (nakiesnummer 0954), lijnske.
programma van Microsoft.
[email protected]. Meer informatie vind je op werkenbijsogeti.nl.
En je weet dat er met jouw kennis en ervaring veel meer mogelijk is. Dan ben je bij Sogeti aan
Kortom, als je ergens kunt doorgroeien, dan is
het juiste adres. Van de 700 collega’s die zich
het wel bij ons. We bieden je masterclasses.
bezighouden met Microsoft-infrastructuur en
De keuze uit heel veel SharePoint-opleidingen.
–applicatieontwikkeling, weten er zeventig alles
En daar horen uiteraard ook certificeringen bij.
2.
3.
De STS zoekt de informatie voor opgegeven gebruiker en applicatie op in een account store (dit kan LiveID, Active Directory of een andere account store zijn) die informatie over gebruikers en applicaties bevat. De STS genereert een token en stuurt dit terug naar de aanvrager.
Identity Provider De combinatie van de STS en de account store is de identity provider, in figuur 2 is dit het hele gedeelte binnen de stippellijnen. De identity provider zorgt ervoor dat de juiste claims voor de geauthenticeerde gebruiker voor de opgegeven applicatie in het door de STS gegenereerde token terechtkomen. Dit is ook de reden dat een claim een claim (een bewering) heet. De identity provider beweert dat de opgegeven informatie over de gebruiker juist is. Het is aan de applicatie om te bepalen of deze de identity provider vertrouwt. Er moet dus vertrouwen, oftewel een “trust” zijn tussen de applicatie en de identity provider.
Het gebruik van claims Tot dusver is het allemaal relatief simpel. Helaas is bovenstaande geen volledige weergave van de werkelijk. De kans is groot dat de gebruiker diverse applicaties gebruikt en dat voor het gebruik van de verschillende applicaties ook verschillende identiteiten nodig zijn. Het kan daarbij zijn dat claims voor deze identiteiten uitgegeven worden door meer dan één identity provider. De vraag wordt dan, hoe weet de client (bijvoorbeeld de web browser) dan bij welke identity provider het benodigde token aangevraagd kan worden. Het antwoord is simpel. Dat weet de browser niet. Figuur 3 geeft een vollediger beeld van het proces. 1.
2.
Een client applicatie (vaak een web browser) gaat naar de door de gebruiker opgevraagde applicatie en vraagt aan de applicatie wat voor soort token en wat voor claims deze verwacht en welke identity providers door de applicatie vertrouwt. De browser weet nu welke mogelijke identiteiten de gebruiker zou kunnen gebruiken om toegang tot de applicatie te verkrijgen. De gebruiker zal op zijn of haar computer gevraagd worden om de identiteit die hij of zij wil gebruiken te
FIGUUR 4: DE ROL VAN GENEVA BIJ HET GEBRUIK VAN CLAIMS-BASED AUTHENTICATIE.
3.
4. 5.
selecteren. De applicatie waarin de juiste identiteit geselecteerd kan worden is de identity selector. Deze toont een lijst(je) van de identiteiten van de gebruiker die voldoen aan de eisen die de applicatie aan een identiteit stelt. De gebruiker kiest welke hij of zij wil gebruiken. De browser vraagt aan de identity provider die behoort bij de door de gebruiker geselecteerde identiteit om een token. De identity provider controleert de authenticiteit van de aanvraag, genereert een token en stuurt het gevraagde token terug naar de browser. De browser stuurt het token door naar de applicatie. De applicatie kijkt naar de claims in het token en gebruikt deze.
De rol van Geneva In bovenstaand verhaal is Geneva niet één keer genoemd. Dit is omdat claims-based authenticatie veel breder is dan Geneva, of dan Microsoft. Je kunt dus gebruik maken van claims-based authenticatie zonder gebruik te maken van Geneva. Wat is Geneva dan wel? Geneva bestaat eigenlijk uit drie onderdelen, Geneva Server, CardSpace Geneva en het Geneva Framework. • Geneva Server is een op Windows gebaseerde STS • Geneva CardSpace is een identity selector voor Windows clients • Geneva Framework is een uitbreiding op het .Net Framework. Het Geneva Framework kan gebruikt worden om applicaties te bouwen die gebruik maken van claims-based authenticatie. Figuur 4 is een weergave van de werking van claims-based authenticatie, waarbij gebruik gemaakt wordt van de verschillende Geneva componenten.
Identity architecture in SharePoint 2010
FIGUUR 3: EEN COMPLETERE WEERGAVE VAN DE WERKING VAN CLAIMS-BASED AUTHENTICATIE.
In SharePoint vindt alle authenticatie plaats op basis van SPUser objecten. Dit betekent dat hoe een gebruiker ook initieel geauthenticeerd is, op basis van een Windows account, of op basis van een forms-based account, de ingelogde gebruiker moet door SharePoint altijd gekoppeld worden aan een SPUser object. In
SharePoint special | december 2009
11
SharePoint 2007 verschilt de manier waarop een gebruiker die met een Windows account is ingelogd gekoppeld wordt aan een SPUser object van de manier waarop een gebruiker die met een forms-based account is ingelogd gekoppeld wordt aan een SPUser object. Dit kan betekenen dat als je in SharePoint 2007 een applicatie bouwt die geschikt moet zijn voor alle authenticatie mechanismen, dat de kans groot is dat je de logica van je applicatie moet aanpassen aan het authenticatie mechanisme dat gebruikt wordt in de web applicatie waar je applicatie in draait. Met SharePoint 2010 wordt het concept van identiteit normalisatie geïntroduceerd. In de praktijk betekent dit dat op wat voor manier een gebruiker ook authenticeert, SharePoint het Windows account token, of het FBA account token, of zelfs een anoniem token vertaalt naar een SAML token. Het SAML token bevat de claims over de gebruiker. Aan de hand van dit claims token wordt vervolgens het SPUser object aangemaakt. In verband met backwards compatibility heeft SharePoint 2010 ook een classic mode. In classic mode werkt het omzetten van een Windows account token naar een SPUser object hetzelfde als dat het in SharePoint 2007 werkt. Forms-based authenticatie werkt niet in classic mode, dat werkt alleen met claims-based authenticatie. In figuur 5 staat ook SAML 1.1 als query authenticatie mechanisme. Dit betekent het mogelijk is om een willekeurige authenticatie provider te gebruiken, zolang deze maar SAML token genereert. De authenticatie provider kan LiveID of ADFS zijn, maar je kunt ook je eigen authenticatie provider bouwen, zolang deze maar SAML token genereert. Hiermee is authenticatie voor SharePoint dus vele malen flexibeler geworden.
Nog even geduld Een ander groot voordeel van het nieuwe claims mechanisme in SharePoint 2010 is dat het mogelijk is om meerdere authenticatie mechanismen te gebruiken in één enkele web applicatie. Het is dus niet meer nodig om een web applicatie te extenden om bijvoorbeeld voor een extranet dezelfde content met behulp van windows authenticatie en forms-based authenticatie te kunnen benaderen.
FIGUUR 6: CLAIMS-BASED AUTHENTICATIE IN SHAREPOINT.
• Windows claims • SAML claims • Windows-claims + FBA claims Dit betekent claims-based authenticatie in beta2 alleen met forms-based authenticatie werkt, het is dus nog even wachten totdat we in SharePoint op grote schaal van de voordelen van claimsbased authenticatie kunnen profiteren. In voorgaande paragrafen is de werking van claims-based authenticatie uitgelegd. De werking van claims-based authenticatie in SharePoint lijkt erg op de werking voor andere systemen. Maar SharePoint zou SharePoint niet zijn als het voor SharePoint niet net een beetje anders zou werken. Figuur 6 is een weergave van het authenticatie proces met behulp van claims voor SharePoint 2010. 1.
2.
Bij de release van beta2 zal de volgende functionaliteit helaas nog niet gerealiseerd zijn:
3. 4.
5.
FIGUUR 5: AUTHENTICATIE MECHANISMEN IN SHAREPOINT 2007 EN 2010
12
SharePoint special | december 2009
Een clientapplicatie (een web browser, Office 2007 SP2, of Office 2010 applicatie) gaat naar de door de gebruiker opgevraagde SharePoint applicatie en vraagt een site of een pagina op. De SharePoint applicatie antwoord de client dat deze zich moet authenticeren en geeft de url van de STS terug waar de gebruiker zich kan authenticeren. Bij het gebruik van claims authenticatie voor SharePoint is dus geen identity selector zoals Cardspace Geneva nodig, SharePoint geeft zelf aan welke STS gebruikt moet worden voor authenticatie. Tussen de SharePoint farm en de STS bestaat altijd een wederzijdse “trust”. De client vraagt aan de identity provider die behoort bij de door SharePoint aangewezen STS om een token. De identity provider controleert de authenticiteit van de aanvraag, genereert een token en stuurt het gevraagde token terug naar de client. De client stuurt het token door naar SharePoint. SharePoint heeft een eigen STS die controleert of er inderdaad een trust is tussen de SharePoint farm en de STS die het token uitgegeven heeft. Vervolgens gaat de SharePoint STS langs bij in SharePoint ingebouwde claims providers. Aan deze providers wordt gevraagd of zij nog additionele informatie over de gebruiker die het token heeft aangevraagd toe willen voegen. Dit kan informatie uit het user profile zijn, maar het kan ook informatie zijn over een SharePoint groep waar de gebruiker toe behoort.
gerealiseerd worden. • Eén van de grootste problemen bij het gebruik van forms based authenticatie is dat er geen integratie mogelijk is met de Office client applicaties. Met behulp van claims-based authenticatie is een naadloze integratie tussen SharePoint 2010 en Office 2007 SP2 of Office 2010 mogelijk. • Voor het tonen van een SharePoint RSS feed in een SharePoint site is het in SharePoint 2007 noodzakelijk om gebruik te maken van Kerberos, omdat de rechten gedelegeerd moeten worden. Met behulp van claims-based authenticatie kan een SharePoint RSS webpart ook werken met NTLM of forms based authenticatie. • Ook als er gebruik gemaakt wordt van een externe databron met Excel Services in SharePoint 2007 is delegation van de credentials noodzakelijk. Met behulp van claims kan dit gemakkelijker. • Tenslotte is het bij integratie van business data uit andere applicaties in SharePoint vaak nodig om aparte maatregelen te nemen om een gebruiker te kunnen authenticeren. Soms wordt een vast account gedefinieerd waaronder alle gebruikers toegang tot de data krijgen, maar dan hebben alle gebruiker dus evenveel rechten op de data. Dit is niet altijd gewenst. In andere gevallen wordt ook voor het ontsluiten van business data via SharePoint Kerberos en delegation van rechten gebruikt. FIGUUR 7: HET AANMAKEN VAN EEN NIEUWE WEB APPLICATIE IN SHAREPOINT 2010.
6.
7.
SharePoint maakt een nieuw token (dit is het SAML token uit figuur 5) aan en zorgt ervoor dat alle informatie uit het oorspronkelijke token en alle SharePoint specifieke informatie in het nieuwe token aanwezig zijn. Dit nieuwe token wordt wederom teruggestuurd naar de client. De client vraagt opnieuw de site of pagina op die de gebruiker wilde bekijken op. SharePoint weet nu aan de hand van het nieuwe SharePoint specifieke token wie de gebruiker is en zet het SAML token om in een SPUser object. Aan de hand van dit SPUser object weet SharePoint of de gebruiker rechten heeft op de site of pagina die hij opvraagt.
Nu je een idee hebt over hoe claims-based authenticatie werkt is het tijd om te kijken naar hoe je het kunt configureren in SharePoint 2010. Het configureren van claims-based authenticatie in SharePoint begint in Central Administration. Bij het aanmaken van een nieuwe web applicatie kan de keuze gemaakt worden tussen “Claims Based Authentication” en “Classic Mode Authentication”. Als je kiest voor Classic Mode kun je alleen Windows authenticatie gebruiken. Als je echter kiest voor Claims Based dan is het ook mogelijk om forms based authenticatie en Federated identities te gebruiken. In figuur 7 is te zien dat het mogelijk is om voor één web applicatie zowel Windows authenticatie als forms based authenticatie als federated identity te selecteren.
De voordelen van claims-based authenticatie in SharePoint Claims-based authenticatie is ontwikkeld om het managen van de identiteit van gebruikers in applicaties eenvoudiger te maken. Dit geldt ook voor claims-based authenticatie in SharePoint. Door gebruik te maken van claims-based authenticatie worden verschillende scenario’s gemakkelijker te realiseren. De vier onderstaande scenario’s komen relatief veel voor en kunnen in SharePoint 2007 niet zonder delegation van credentials
Zelf ervaren Dat deze vier scenario’s nu zonder Kerberos gerealiseerd kunnen worden betekent niet dat we Kerberos niet meer nodig hebben, of dat Kerberos zal verdwijnen. Kerberos heeft nog steeds grote voordelen bij sommige scenario’s en is ook nog steeds noodzakelijk in andere scenario’s. Claims-based authenticatie zal echter wel het realiseren van diverse scenario’s gemakkelijker maken. Als je zelf een applicatie bouwt voor SharePoint hoef je geen rekening meer te houden met het authenticatie mechanisme dat de web applicatie gebruikt. We zullen nog tot de RTM versie van SharePoint 2010 moeten wachten totdat we alle voordelen van claims-based authenticatie voor SharePoint kunnen ervaren. Mijn advies zou zijn om voor die tijd de nieuwe forms based authenticatie op basis van claims uit te proberen en de voordelen met eigen ogen te zien.
Mirjam van Olst, is Microsoft Certified Master (MCM) SharePoint en SharePoint architect bij het Information Worker Solutions Center van Macaw. Mirjam is ook één van de organisatoren van de Dutch Information Worker User Group (DIWUG) en is mede-track owner van de Information Worker track van het Software Development Network (SDN). Mirjam’s blog is te vinden op http://sharepointchick.com.
SharePoint special | december 2009
13
