Nintex Workflow – In welchem Userkontext wird die Workflow Action ausgeführt?

Intro

Mit Nintex Workflow und Nintex Forms lassen sich relativ schnell prozessgesteuerte Anwendungen in Microsoft SharePoint implementieren. Schnell werden verschiedene Workflow Actions und Bedingungen zusammen geklickt: hier mal eine Create Item Action, dort Execute SQL, da mal ein Call Web Service, dann noch kurz Credentials eintragen und – damit es übersichtlich bleibt – noch schnell einige Actions in ein Action Set gruppieren. Schnell entsteht ein Workflow Prototyp, noch kurz veröffentlichen und fertig? Nein!

Wie bei jeder anderen Anwendung ist es wichtig, zu wissen, in welchem Sicherheitskontext die Anwendung bzw. die Nintex Workflow Action ausgeführt wird/werden kann – und welchen Einfluss das auf das Lösungsdesign des Workflows hat. In diesem Blog beschreibe ich, in welchen verschiedenen Kontexten eine Nintex Action ausgeführt werden kann, und welche Vor- und Nachteile das haben kann.

Option 1: Kontext des Anwenders, der den Workflow startet

Wird nichts weiter konfiguriert, so laufen Workflows im Kontext der Person, die den Workflow startet. Gerade bei Workflows in Webs mit komplexer Rechtestruktur und gebrochener Berechtigungsvererbung kann es zu Fehlern kommen, wenn die Person, die einen Workflow startet, nicht auf Listen Zugriff hat, auf die der Workflow zugreifen soll.

Option 2: Kontext des Workflow Owners

Workflow Aktionen, die in einem Action Set, einer Loop-Action oder in einer State-Machine enthalten sind, können im Kontext des Anwenders ausgeführt werden, der den Workflow veröffentlicht hat. Dazu gibt es in den Einstellungen der Action > Common folgende Einstellungsmöglichkeit:

In der Regel hat der Workflow Owner auch Owner-Rechte in dem Web, d.h. Zugriff auf Listen & Bibliotheken sollten berechtigungstechnisch möglich sein. Aber was passiert eigentlich, wenn:

• … der Anwender, in dessen Kontext der Workflow veröffentlicht wurde, sein Windows Kennwort ändert? à nichts, die Workflow Funktionalität ist nicht eingeschränkt
• … der Account des Anwenders, in dessen Kontext der Workflow veröffentlicht wurde, im Active Directory deaktiviert wird à nichts, die Workflow Funktionalität ist nicht eingeschränkt
• … der samAccountName des Anwenders, in dessen Kontext der Workflow veröffentlicht wurde, im Active Directory umbenannt wird à der Workflow funktioniert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!
• … der Account des Anwenders, in dessen Kontext der Workflow veröffentlicht wurde, im Active Directory gelöscht wird à der Workflow funktioniert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!

Option 3: Nintex Credential Picker

Die folgenden Nintex Workflow Actions aus der Kategorie Integration nutzen den Nintex Credential Picker, um auf externe Services zuzugreifen:

• Call web service
• Create CRM record
• Delete/Disable CRM record
• Execute SQL
• Find users by status
• Get user status
• Query BCS
• Query CRM
• Query Excel Services
• Query LDAP
• Query XML
• Send / receive BizTalk
• Update CRM record
• Update XML
• Web request

Der Nintex Credential Picker kann in drei verschiedenen Arten genutzt werden:

1.      Credentials in der Action

Die Credentials können direkt in der Action angegeben werden, Beispiel:

Vorteile:

• Es ist gleich zu erkennen, welcher Account genutzt wird.

Nachteile:

• Um den Account zu ändern, muss der Workflow geändert und neu veröffentlicht werden – auf in Ausführung befindliche Workflow Instanzen hat das keinen Einfluss.
• Verwenden mehrere Actions im Workflow den gleichen Account, so muss dieser mehrfach im Workflow geändert werden, was z.B. beim Export & Import des Workflows auf verschiedene Umgebungen aufwändig sein kann.

2.      Stored Credentials – Nintex

Über die Nintex Settings können die Credentials als Nintex Konstante auf Site, Site Collection oder Farm Ebene konfiguriert werden; Optional kann definiert werden, wer dieses Credential nutzen darf:

Danach kann die Nintex Konstante im Credential Picker ausgewählt werden:

Vorteile:

• Das Credential kann in Nintex an zentraler Stelle geändert werden.
• Die Konfiguration ist einfach und gut nachvollziehbar.
• Es reichen Site oder Site Collection Owner Berechtigungen aus, um die Credentials zu definieren (Ausnahme: Farm Level Credential).

Nachteile:

• Credentials sind nicht im Secure Store Service gespeichert, sondern in Nintex. Die in Nintex gespeicherten Credentials können nicht für andere Anwendungen außerhalb von Nintex wie zum Beispiel BCS oder Excel Services genutzt werden.
• Standardmäßig darf jeder Workflow Ersteller auf die hinterlegten Credentials im jeweiligen Scope (Site, Site Collection, Farm zugreifen. Es besteht das Risiko, dass das Credential von anderen Workflow Erstellern für andere Zwecke verwendet werden.

3.      Stored Credentials – Secure Store

Ähnlich zur Option 2, Unterschied ist, dass die Credentials im Secure Store Service abgelegt werden. Diese Funktion ist seit dem Release 3.1.3.0 (April 2015) verfügbar.

Bei Verwendung der Option Secure Store Credential wird auf eine Target Application ID referenziert. Die Target Application muss im jeweiligen Secure Store Service existieren.

Die Verwaltung von Credentials im Secure Store Service ist aus Anwendersicht komplexer als in Nintex und setzt einiges an Wissen voraus:

• Der Anwender benötigt im Secure Store spezielle Rechte, um eigene Credentials (sogenannte Target Application IDs) im Secure Store anzulegen und zu verwalten. Diese Rechte müssen initial durch den Farm Admin konfiguriert werden. Unabhängig davon ist die Central Administration von SharePoint auf SSL / https umzustellen, damit die hinterlegten Credentials nicht im Klartext durch das Netzwerk geschickt werden. Wird der Secure Store ohne SSL verwendet, so erscheint die Warnung: Warning: this page is not encrypted for secure communication. User names, passwords, and any other information will be sent in clear text. For more information, contact your administrator.
• Im Secure Store Service sind verschiedene Target Application Types möglich. Im Falle von Credentials, die in Nintex genutzt werden, ist der Target Application Type = Individual ausreichend, da Nintex mit der Identität der Webanwendung auf den Secure Store Service zugreift. Dies stellt aber auch ein Risiko dar, da jeder Code, der als Farm Solution bereitgestellt ist, potentiell durch Nutzung von RunWithElevatedPrivileges auf dieses Credential zugreifen kann.

Vorteile:

• Sofern vorhanden kann eine bestehende und gesicherte Secure Store Service Implementierung genutzt werden – die Credentials werden an zentraler Stelle verwaltet.

Nachteile:

• Die Komplexität bei Nutzung der Nintex Konstanten und des Secure Stores ist nicht zu unterschätzen – es ist mit Schulungsaufwand zu rechnen. Durch die verteile Konfiguration in Nintex und im Secure Store wird zudem das Troubleshooting erschwert.
• Credentials im Secure Store sind global und können – je nach Berechtigung – in der Farm genutzt werden. Definition von Credentials auf Site oder Site Collection Level ist nicht möglich.

Zusammenfassung / Best Practices

1. Wird ein Action Set mit der Option Run as workflow owner verwendet, so sollte der Workflow im Kontext eines Workflow-Anwendungsaccount veröffentlicht werden, nicht mit einem personalisierten Account. Bei Verwendung eines personalisierten Accounts wird der Workflow nicht mehr funktionieren, wenn der personalisierte Account im Active Directory gelöscht wurde.
2. Bei Verwendung von Actions mit dem Credential Pickers sollten die Credentials nicht fest in der Workflow Action hinterlegt werden, sondern referenziert werden. Ob diese Nintex, oder im Secure Store verwaltet werden, hängt von den unternehmensspezifischen Voraussetzungen, bzw. Richtlinien ab. In jedem Fall ist aber sicherzustellen, dass die Zugriffsrechte auf das Credential nach dem Minimal-Rechte-Prinzip konfiguriert sind, andernfalls besteht das Risiko, dass Credentials missbraucht werden.