Wanneer SharePoint 2010 een verzoek van een gebruiker krijgt, is de eerste reactie een nieuwsgierige; wie ben jij en wat kom je doen? SharePoint wil weten wie je bent, om te kunnen bepalen welk niveau van toegang je krijgt. Op zich logisch, toch? Wanneer je die vraag beantwoordt, door je gebruikersnaam en je wachtwoord te geven, gebeurt er achter de schermen nogal wat.

Dit artikel gaat in op de diverse manieren waarop je identiteit wordt gebruikt binnen SharePoint en welke mogelijkheden en beperkingen daaruit volgen.

SharePoint gebruikt je identiteit op drie manieren:

1. Inkomend - Bij het aanmelden.
2. Intern – Diverse services gebruiken je identiteit voor autorisatie doeleinden.
3. Uitgaand – Voor connecties naar achterliggende systemen.

Aanmelden / inloggen

Er bestaan een aantal manieren om je identiteit bij SharePoint bekend te maken. Afhankelijk van de herkomst van de aanvraag bepaalt SharePoint (eigenlijk IIS) welke methode wordt gebruikt. Overigens wordt de authenticatie afgehandeld door IIS en doorgegeven aan SharePoint. De configuratie wordt gedaan op web applicatie niveau in SharePoint Central Administration. De instelling wordt vervolgens naar de metabase van IIS (IIS6) of de ApplicationHost.config (IIS7) geschreven.
We hebben de keus uit drie methodes, die in de tabel hieronder worden beschreven:


Wanneer een nieuwe web application wordt gemaakt, kan men kiezen voor Classic Mode Authentication of voor Claims Based Authentication.

Classic Mode biedt de mogelijkheid voor Windows Authenticatie. Claims Based Authentication geeft de optie voor Forms Based Authentication en Claims Authentication Types en er kunnen meerdere methodes worden gecombineerd op één web application.

Windows Authentication – NTLM. De meest gebruikte en voor de eindgebruiker makkelijkste manier is Windows Integrated Authentication. Gemakkelijk, omdat je niet wordt lastig gevallen met de vraag om in te loggen; dat gebeurt automatisch, omdat je al bent aangemeld bij Active Directory toen je inlogde op het werkstation waarop je nu werkt. Gemakkelijk voor de SharePoint administrator, want het is de standaard instelling en het werkt zonder verdere configuratie.

De beperkingen van deze methode zijn echter belangrijk. Inhoud die kan worden gepresenteerd in SharePoint is beperkt tot de lokale content databases. Wanneer data uit achterliggende systemen, zoals databases, moet worden geïntegreerd in SharePoint, loop je tegen beperkingen aan. NTLM kan de identiteit van de ingelogde gebruiker niet doorgeven aan die servers, zodat altijd met een voorgedefinieerde service account (per service) wordt gewerkt. Er is dan geen differentiatie mogelijk op basis van de ingelogde gebruiker.

Windows Authentication – Kerberos. Voor de eindgebruiker ook gemakkelijk, want ook hier wordt geen pop-up getoond, zolang de URL maar in de Trusted Sites of in de Local Intranet zone van Internet Explorer staat.

Forms Based Authentication. Wanneer je de gebruikers die je toegang wilt geven niet wilt opnemen in Active Directory, is Forms Based Authentication een goede optie. In SharePoint 2010 is deze methode afhankelijk van een web application in Claims Based mode.

Claims Based Authentication. Alles wat met claims te maken heeft is een hot item, tegenwoordig. Het biedt een groot aantal voordelen, zoals een uitbreiding op de autorisatie mogelijkheden en de mogelijkheid om authenticatie uit te besteden aan externe partijen. Maar voordat je al je nieuwe web applications uitrust met claims based authentication, is het goed te weten dat er beperkingen zijn. In het laatste deel van dit artikel worden de beperkingen en de oplossingen uitgelegd.

Identiteit binnen SharePoint

Wanneer je identiteit bekend is na het aanmelden, gaat SharePoint er mee aan de slag. Dat moet wel, want de identiteit die de login methode oplevert is voor SharePoint niet bruikbaar. Daarom wordt een proces van Identity Normalisation uitgevoerd waarin de diverse identiteiten, resp. WindowsIdentity, FormsIdentity of ClaimsIdentity, worden getransformeerd tot een SAML Token (Claims Based Identity) en vervolgens geassocieerd met een SPUser object. Dat SPUser object wordt door SharePoint gebruikt voor autorisatie doeleinden, voor Alerts, voor audiences etc.

De associatie met de originele identiteit blijft wel bestaan. Wanneer je onder de motorkap (of in de logfiles) kijkt zie je een useraccount weergegeven in de volgende formaten:

Wanneer je een zoekactie uitvoert, worden alleen de objecten waar jij minimaal leesrechten hebt, aan je getoond. Security trimming gebeurde in SharePoint 2007 op de Web Front End server, waar eerst alle zoekresultaten heen werden gestuurd en vervolgens gefilterd. SharePoint 2010 voert dit proces uit op de Search server en stuurt alleen de getrimde resultaten set door naar de Web Front End. Veel efficienter, dus.

Identiteit uitgaand

SharePoint biedt diverse mogelijkheden om informatie die in externe systemen zit, binnen de context van de site te presenteren. Data uit bijvoorbeeld SQL Server databases kan rechtstreeks of via een Windows Communication Foundation (WCF) webservice worden opgehaald en in een external list of een webpart worden getoond. Andere voorbeelden zijn Excel Calculation Service en Performance Point.
In veel gevallen is het wenselijk de identiteit van de ingelogde gebruiker in het verzoek mee te sturen, zodat alleen die informatie terugkomt, waarvoor de gebruiker geautoriseerd is. De authenticatiemethode die werd gebruikt bij het aanmelden is hierbij bepalend voor het resultaat.

NTLM
NTLM kent het principe van forwarding van gebruikersgegevens niet en in dat geval wordt een service account of de identiteit van de Application Pool Identity gebruikt voor de connectie.

Kerberos
Kerberos kent deze beperking niet. Sterker nog, het is er voor gemaakt! Wanneer de SharePoint web application is geconfigureerd met WIA-Kerberos, wordt bij het inloggen een Kerberos session ticket gemaakt. Dit ticket bevat jouw gebruikersnaam en een levensduur van een aantal uren, zodat je bij een volgend bezoek niet opnieuw hoeft in te loggen. Een belangrijke eigenschap van zo’n ticket is dat het Forwardable is, zodat de ontvangende partij (SharePoint) dit ticket kan doorsturen naar een achterliggend systeem (SQL) en daarbij een request kan doen op basis van Impersonation. Omdat SharePoint het ticket doorstuurt, wordt het request uit naam van de ingelogde gebruiker gedaan.
Voorwaarde is dat voor de Application Pool Identity van de web application een Service Principal Name is geregistreerd. Dat doe je met een setspn.exe en de syntax is setspn.exe http/url domain\username. Wanneer de AppPool Identity van http://intranet.trainsbydave.com bijvoorbeeld TRAINSBYDAVE\Intranet is, luidt de opdracht

setspn.exe http/intranet.trainsbydave.com TRAINSBYDAVE\Intranet

Wanneer de SPN is geregistreerd, verschijnt op een nieuw tabblad, Delegation, wanneer je de eigenschappen van de service account opvraagt. Daarin kun je aangeven naar welke andere service account deze account credentials mag doorsturen. In het geval van SharePoint is dat dan de service account van SQL.


Claims
Claims zijn er ook voor gemaakt om doorgestuurd te worden, dat is het hele principe. Een Identity Provider authenticeert de gebruiker, genereert een token met claims over die gebruiker. De gebruiker stuurt deze claims naar de applicatie, die op basis van de waarde van de claims een autorisatiebeslissing neemt. Voorwaarde is wel dat de ontvangende partij de claims kan interpreteren. Wanneer de applicatie, ook wel Relying Party genoemd, gebaseerd is op bijvoorbeeld Windows Identity Foundation is dat geen probleem. Echter, op dit moment is SharePoint 2010 de enige Microsoft applicatie die op basis van WIF is gebouwd. Andere applicaties in de Microsoft wereld, zoals SQL Reporting Services of SQL Analysis Services zijn nog niet claims aware.

De oplossing hiervoor is de Claims to Windows Token Service (C2WTS). Deze service bestaat al langer en werd door Microsoft in de BPOS omgeving gebruikt om de claims tokens van gebruikers te converteren naar Windows/NT tokens. Immers, BPOS authenticatie is op basis van LiveID (claims based) en Exchange 2007 is niet claims aware.
Excel Calculation Services gebruikt de C2WTS service, mits die op de ECS server draait, wanneer data uit externe databases in Excel worksheets wordt getoond (specifiek bij een Refresh actie). De service is standaard niet gestart, wordt bij voorkeur gedraaid onder een domain account en is afhankelijk van de Cryptographic Services service. Voeg deze service toe aan de Dependencies tab, als die er nog niet staat.

Een andere oplossing is het gebruik van een WCF layer tussen SharePoint en SQL, waarin WIF code is verwerkt die de claims afhandeling doet.

Conclusie

SharePoint ondersteunt diverse manieren van authenticeren, maar de gekozen methode bepaalt in hoeverre de functionaliteit van SharePoint te gebruiken is. Bij claims based AuthN moeten extra maatregelen worden genomen.