Suche zur Auflistung aller Site Collections verwenden

Oft werde ich gefragt, wie man die Navigation in SharePoint einfacher gestalten kann, oder ob es nicht möglich sei, eine ganze Liste aller verfügbaren Websites anzuzeigen, auf die ein Benutzer Zugriff hat.

Personen mit Entwickler-Kenntnissen würden nun u.U. direkt zu Visual Studio greifen und ein WebPart schreiben, schließlich gibt es doch im Objektmodell alles: Ich kann auf alle Webs zugreifen und dort über die Methode DoesUserHavePermission() die Berechtigung prüfen. Damit befülle ich dann einfach eine DropDown-List.

In diesem Beitrag möchte ich jedoch zeigen, dass es auch mit Standardmitteln in Verbindung mit der Suche ganz einfach ist. Und zudem funktioniert es, denn die obige Methode hat einen großen Nachteil: Sie funktioniert nur in sehr kleinen Umgebungen zuverlässig. Sobald Sie eine große Anzahl Site Collections habe (>30-40) werden Sie sehr schnell einen Performanceeinbruch bemerken, die Auflistung dauert dann gefühlte Ewigkeiten und belastet das System enorm.

Für die Lösung benötigen wir Folgendes:

  • Ein Query zum Finden aller Site Collections
  • Das WebPart “Kernergebnisse der Suche”
  • Ein eigenes XSL-Template

Das Query

Um alle Site Collections zu finden, auf die ein Benutzer Zugriff hat, müssen wir nur auf die Site Collection Typen einschränken, die Berechtigungsprüfung ist bereits eingebaut. Hierzu verwenden wir das Managed Property “contentclass”. In diesem Artikel sind mögliche Werte beschrieben, unser Query lautet damit:

Contentclass:STS_Site

Das WebPart

Das CoreResults-WebPart wird auf einer beliebigen Page plaziert, eben dort, wo Sie das DropDown haben möchten:

In den WebPart-Properties muss dann ein Fixed Query angegeben werden (Abfrageoptionen für Ergebnisse à Feste Stichwortabfrage), hier wird unser Query von oben eingetragen. Zudem muss die Location Visualization deaktiviert werden (Eigenschaften anzeigen à Speicherortvisualisierung verwenden)

Das XSL-Template

Und nun kommt der schwierige Teil. Wir benötigen ein XSL-Template, das eine DropDown-List befüllt und zudem ein kleines JavaScript zur Weiterleitung an die URL hinterlegt. Hier steckt der größte Aufwand, ich poste den Code dafür direkt hier:

Dieser Code muss in den WebPart-Properties im XSL-Editor eingetragen werden. Den Quelltext habe ich hier zum Download zur Verfügung gestellt.

Das Ergebnis

Alles zusammen sieht dann wie gewünscht aus:

Dies kann natürlich auch Teil einer MasterPage sein, wobei man hier eventuell noch ein Caching einbauen sollte, um die Suche nicht zu überlasten.

Workflows in SharePoint Server 2013

Bei den Workflows für Endanwender gibt es einige Neuerungen: Der SharePoint Designer 2013 selbst ist weiterhin kostenlos verfügbar und ähnelt im Aussehen weiterhin der 2010er-Version. Auch dessen Workflows von SharePoint 2010 funktionieren weiterhin wie gehabt. Wer die neuen Funktionalitäten nutzen möchte, muss SharePoint 2013 Workflows erstellen können und dazu sind auf SharePoint-Seite einige Vorbereitungen zu treffen (jedenfalls bis jetzt in der Preview-Version). Wer eine Standardinstallation wie in SharePoint 2010 vorgenommen hat, wird beim Erzeugen eines neuen Workflows im SharePoint Designer nur den 2010er-Typ zur Auswahl erhalten:

Die SharePoint 2013-Workflows zu aktivieren, muss “Windows Azure Workflow 1.0” installiert, konfiguriert und anschließend mit der SharePoint-Farm verknüpft werden. Weitere Informationen zu der Konfiguration findet Ihr hier: http://msdn.microsoft.com/en-us/library/windowsazure/jj193478%28v=azure.10%29. Danach stehen die neuen Funktionen zur Verfügung:

  • Stages: Wie in Visual Studio lassen sich nun State Machine Workflows erstellen mit mehreren Status, zwischen denen beliebig gewechselt werden kann.
  • Loops: Schleifen mit einer festen Anzahl an Wiederholungen oder mit Abbruchbedingung, wie im Screenshot dargestellt

  • Neuer Task Designer mit erweiterten Optionen

  • Weitere Aktivitäten:
    • WebService-Aufrufe
    • Dictionary-Aktionen
    • Listen- und Site-Workflows starten
    • Und weitere

Wie viele Aktivitäten hiervon auch noch in die 2010er-Workflows wandern, ist derzeit unklar. Auch der Workfloweditor selbst hat dazugelernt. Wen Visio 2013 auf dem lokalen Computer installiert ist, ist auch ein visueller Editor verfügbar, ein manueller Import/Export über eine Datei ist nicht mehr notwendig:

On Breaking SAML: Single-Sign-On Systeme anfällig

Die Ruhr-Universität Bochum hat vor kurzem eine Untersuchung veröffentlicht, in der verschiedene auf SAML basierende Single-Sign-On-Systeme auf Sicherheitslücken untersucht wurden.

Von den 14 untersuchten Frameworks waren danach 12 anfällig für eine XML Signature Wrapping Attacke. Untersucht wurden unter anderem:

  • Apache Axis 2
  • Windows Identity Framework
  • OpenSAML
  • Salesforce
  • SimpleSAMLphp
  • WSO2
  • OneLogin

Bei einer XML Signature Wrapping Attack wird das XML-Dokument mit den SAML Assertions (die Identifikation des Benutzers) mit weiteren Assertions angereichert. Das Dokument ist in der Regel signiert, jedoch lassen sich die anfälligen Systeme austricksen, in dem die zusätzlichen Assertions in einem nicht signierten Bereich des Dokuments untergebracht werden. Bei den anfälligen Systemen sind die Signaturverifikation und die Regelverarbeitung getrennt, sodass die zusätzliche Assertions akzeptiert und verarbeitet werden, auch wenn sie nicht signiert sind.

Die beiden nicht anfälligen Systeme waren SimpleSAMLphp und das Windows Identitiy Framework, das auch das SAML-Framework für SharePoint 2010 und Active Directory Federation Services 2.0 darstellt.

Die anfälligen Frameworks werden beispielsweise in Shibboleth, Joomla, WordPress, SugarCRM, Drupal und von Salesforce verwendet.