SharePoint und die Claims Based Authentication

Manche die SharePoint 2010 einsetzen haben sich vielleicht schon gefragt, was es mit dieser „Claims Based Authentication“ auf sich hat. In diesem und weiteren Artikeln möchte ich eine kleine Einführung in diese Technologie geben.

Was ist Claims Based Authentication in SharePoint 2010?

In SharePoint 2010 gibt es für den Authentication Provider einer WebApplication zwei mögliche Modi:

  • Classic Mode Authentication
  • Claims Based Authentication

Der klassische Modus unterstützt im Gegensatz zu SharePoint 2007 (denn da gab es keinen Claims Based Mode Out-Of-The-Box) nur noch Windows Authentication, also auch keine formularbasierte Authentifizierung. Für selbige muss man nun in den „Claims Based Mode“ wechseln.

Im „Claims Based Mode“ hat man dagegen mehr Möglichkeiten zur Authentifizierung. Neben Windows Authentifizierung (WA) und formularbasierter Authentifizierung (FBA) kann man hier nun auch einen „Trusted Identity Provider“ einbinden und aktivieren. Und nicht nur das, hier ist es auch möglich, gleichzeitig mehrere dieser Authentifizierungsmöglichkeiten zu aktivieren, sodass z.B. sowohl WA und FBA möglich sind. Aber dazu später mehr.

Wie wechselt man in den „Claims Based Mode“?

Wenn man nicht von vornherein die WebApplication in diesem Modus erstellt hat, ist der Wechsel ein wenig aufwändiger, weil die Benutzernamen migriert werden müssen. Denn diese ändern sich, aufgrund der vorher beschriebenen Möglichkeit, mehrere Authentifizierungsformen gleichzeitig aktivieren zu können. Hier muss natürlich für eine Eindeutigkeit der Benutzernamen gesorgt werden.

Um eine WebApplication  umstellen zu können, muss man die PowerShell bemühen. Zuerst holt man sich die entsprechende WebApplication. Danach muss das Attribute UseClaimsAuthentication aktiviert werden, danach müssen noch die Benutzer migriert werden:

$wa = Get-SPWebApplication  http://meineurl/
$wa.UseClaimsAuthentication = $true
$wa.MigrateUsers($true) $wa.Update()

Danach sehen die Benutzernamen ein wenig anders aus:

i:0#.w|grohne\sps.contentaccess
i:0#.w|grohne\sps.superreader
i:0#.w|grohne\sps.superuser
SHAREPOINT\system
i:0#.w|grohne\testbenutzer
i:0#.w|grohne\ugrohne

Zusätzlich zum Benutzernamen enthalten Sie Informationen zum Identity Provider und dessen Index, in diesem Fall ist mit einem w die WA gekennzeichnet.

Danach kann man zusätzliche Authentifizierungsformen einbinden, für FBA z.B. durch Änderung einiger web.config-Dateien, die hier nicht beschrieben werden sollen, oder durch Einrichtung eines „Trusted Identity Provider“. Im Authentication Provider der jeweiligen WebApplication kann man diese dann alle aktivieren, wenn man möchte:

Was ändert sich in der Oberfläche?

Hat man mehrere Authenfizierungsformen aktiviert, erhält der Benutzer standardmäßig beim Authentifizieren einen Auswahldialog, wo er sich denn gerne authentifizieren möchte:

Nach der Auswahl wird er entweder entsprechend weitergeleitet oder ein Formular wird angezeigt.

Dies ist aber nicht das Einzige, denn auch der People Picker wird geändert. Sah dieser früher noch sehr fad und einfach aus, wird aus ihm der neue Principal Picker, da er sehr viel mehr Funktionalitäten hat:

Der Screenshot zeigt jetzt schon sehr viel mehr Informationen, da in meinem Beispiel bereits mehrere Authentifizierungsformen und Detaildaten aktiviert sind, lassen Sie sich hiervon nicht verwirren. ;)

Mehr Informationen in einem der nächsten Artikel …