SharePoint 2013 – Custom Claim Based Permissions Teil 2

17. Dezember 2015

Im ersten Teil wurde bereits darauf eingegangen wozu dieser Blogpost existiert, und was erreicht werden soll. Außerdem wurde der Zweck und Aufbau von Claims erklärt. Des Weiteren wurden die wichtigsten Punkte im Bezug auf den Connector, welcher die Claims erstellt veranschaulicht.

Falls Sie, liebe Leser, sich jetzt Fragen wovon ich schreibe, hier können Sie es nachlesen.

 

Implementierung Pre-Security Trimmer

Die Implementierung des Pre-Security Trimmers gestaltet sich einfacher als die des Connectors. Alles, was zu tun war, war eine Ausimplementierung des SharePoint Interfaces. Auch hier habe ich die hervorragenden Blogposts von Sveinar Rasmussen als Vorlage genutzt und das passende Pendant zum Connector erstellt. Ich habe auch so gut wie keine Anmerkungen, bis auf zwei Kleinigkeiten.

Beim Ausrollen des Trimmers wird auf das Command

New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application"
​-typeName "CstSearchPreTrimmer.SearchPreTrimmer, CstSearchPreTrimmer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=token" 

Mit dem Parameter Id = 2 verwiesen. Hier möchte ich lediglich auf die TechNet beschreibung verweisen, welche sagt:

ID: „Gibt die Identität des Security Trimmers an, der für die angegebene Suchanwendung verwendet werden soll. Wenn dieser Parameter einen vorhandenen benutzerdefinierten Security Trimmer angibt, wird der Trimmer entfernt und durch den benutzerdefinierten Trimmer ersetzt. Entfernen Sie den vorhandenen Trimmer, bevor Sie einen neuen hinzufügen.“

Hat man also vor weitere Trimmer zu registrieren, sollte man dies auf jeden Fall berücksichtigen!

Im Vergleich zum Connector ist schon beschrieben, wie man einen User auf mehrere Claims berechtigt. Hier war also keine weitere Anpassung nötig.

Hier ist noch der Inhalt des verwendeten Konfigurationsfiles:

b-s-s\sebastian.graeser:gruppe10;gruppe1; 

Resultat

Nachdem nun der Connector und der Pre-Security Trimmer implementiert wurden, war es so weit das Gesamtkonstrukt zu testen. Ich gehe dabei noch einmal kurz auf den Aufbau, die Konfiguration und natürlich auch auf die Ergebnisse ein.

Der Aufbau:

Ein SharePoint 2013 Server liegt als Basis zu Grund, darauf ist eine SearchService Applikation eingerichtet. Der Connector sowie der Security Trimmer sind am SharePoint 2013 registriert, die Konfigurationen sind geprüft und hinterlet.

Die Konfiguration:

 

In diesem Bild sieht man die Konfiguration bzw. Inputdatei vom Connector(example.xml) als auch vom Pre-Security Trimmer(userMappig.txt). Meine Erwartungshaltung an dieser Stelle wäre es, dass 3 Dokumente im Index landen, die mit entsprechenden Claims ausgestattet sind. Ein User in der Domain „b-s-s“ mit dem AccountNamen „sebastian.graeser“, das bin Ich, müsste in der Lage sein 2 der 3 Dokumente zu finden.

Der Crawl:

Wie man unschwer erkennen kann, wurden die 3 Dokumente indexiert, jetzt muss nur noch die Suche und das Auflösen der Claims funktionieren!

Die Suche:

Kommen wir nun zum großen Finale, der Teil, in dem das Zusammenspiel aller Komponenten auf die Probe gestellt wird.

Wurden die Daten korrekt ausgelesen und die darauf erstellten Dokumente richtig an den Index übergeben?
Hat der Connector die Claims nicht richtig erstellt?
Löst der Pre-Security Trimmer die Claims nicht richtig auf?

Sollte auch nur eine Antwort „Nein“ lauten, sollte in dieser letzten Kontrolle reichlich wenig passieren.

Hier kommt die Auswertung… Suche nach „exSec_Title0“, dem ersten Dokument:

Gut, es wird etwas gefunden, ein guter Start, in kurzer Blick in die Konfiguration verrät mir, dass Grupp1 und 2 darauf berechtig sind, welche ein Glück, dass mein Nutzer in Gruppe 1. Das Verhalten ist absolut erwartungskonform.

Weiter geht’s, was wird die Suche nach „exSec_Title1“ wohl liefern?

Auch dieses finde ich, na dass sieht doch schon mal gut aus. Ein Blick in die Konfiguration sagt, dass alles nach Plan verläuft, denn ich bin auch in Gruppe 10!

Kommen wir zur letzten Suche:

Nichts gefunden… Sehr gut! Denn wie der Aufmerksame Leser sicher bereits festgestellt hat, dürfen nur Gruppe 2 und 100 darauf zugreifen, dafür habe ich leider keine Berechtigung. Die Umsetzung war also ein voller Erfolg, alles hat genauso funktioniert, wie erwartet, bzw. erhofft.

Resümee:

Der dabei entstandene Connector und Pre-Security Trimmer sind eine super Ausgangssituation um viele Anwendungsfälle abdecken zu können! Alles lässt sich relativ einfach aufsetzten und ist schon mit wenig Entwicklungsarbeit schnell angebunden. Dabei stellen sich die selber erstellten Claims als unglaublich mächtiges Werkzeug heraus, auf das man auf keinen Fall verzichten sollte, wenn man mit so einer Ausgangssituation konfrontiert wird wie im Eröffnungspost erläutert.

Neuen Kommentar schreiben