Nintex Workflow – In welchem Userkon­text wird die Workflow Action ausgeführt?

Mit Nintex Workflow und Nintex Forms lassen sich relativ schnell prozess­ge­steu­erte Anwen­dungen in Micro­soft Share­Point imple­men­tieren. Schnell werden verschie­dene Workflow Actions und Bedin­gungen zusammen geklickt: hier mal eine Create Item Action, dort Execute SQL, da mal ein Call Web Service, dann noch kurz Creden­tials eintragen und — damit es übersicht­lich bleibt — noch schnell einige Actions in ein Action Set gruppieren. Schnell entsteht ein Workflow Prototyp, noch kurz veröf­fent­li­chen und fertig? Nein!

Wie bei jeder anderen Anwen­dung ist es wichtig, zu wissen, in welchem Sicher­heits­kon­text die Anwen­dung bzw. die Nintex Workflow Action ausge­führt wird/werden kann – und welchen Einfluss das auf das Lösungs­de­sign des Workflows hat. In diesem Blog beschreibe ich, in welchen verschie­denen Kontexten eine Nintex Action ausge­führt werden kann, und welche Vor- und Nachteile das haben kann.

 

Option 1: Kontext des Anwen­ders, der den Workflow startet

Wird nichts weiter konfi­gu­riert, so laufen Workflows im Kontext der Person, die den Workflow startet. Gerade bei Workflows in Webs mit komplexer Rechte­struktur und gebro­chener Berech­ti­gungs­ver­er­bung 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 Anwen­ders ausge­führt werden, der den Workflow veröf­fent­licht hat. Dazu gibt es in den Einstel­lungen der Action > Common folgende Einstellungsmöglichkeit:

In der Regel hat der Workflow Owner auch Owner-Rechte in dem Web, d.h. Zugriff auf Listen & Biblio­theken sollten berech­ti­gungs­tech­nisch möglich sein. Aber was passiert eigent­lich, wenn:

• … der Anwender, in dessen Kontext der Workflow veröf­fent­licht wurde, sein Windows Kennwort ändert? à nichts, die Workflow Funktio­na­lität ist nicht eingeschränkt
• … der Account des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory deakti­viert wird à nichts, die Workflow Funktio­na­lität ist nicht eingeschränkt
• … der samAc­count­Name des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory umbenannt wird à der Workflow funktio­niert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!
• … der Account des Anwen­ders, in dessen Kontext der Workflow veröf­fent­licht wurde, im Active Direc­tory gelöscht wird à der Workflow funktio­niert nicht mehr – Actions in diesem Action Set laufen auf einen Fehler!

 

Option 3: Nintex Creden­tial Picker

Die folgenden Nintex Workflow Actions aus der Kategorie Integra­tion nutzen den Nintex Creden­tial 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 Creden­tial Picker kann in drei verschie­denen Arten genutzt werden:

1.      Creden­tials in der Action

Die Creden­tials 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öf­fent­licht werden – auf in Ausfüh­rung befind­liche 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 verschie­dene Umgebungen aufwändig sein kann.

 

2.      Stored Creden­tials — Nintex

Über die Nintex Settings können die Creden­tials als Nintex Konstante auf Site, Site Collec­tion oder Farm Ebene konfi­gu­riert werden; Optional kann definiert werden, wer dieses Creden­tial nutzen darf:

Danach kann die Nintex Konstante im Creden­tial Picker ausge­wählt werden:

Vorteile:

• Das Creden­tial kann in Nintex an zentraler Stelle geändert werden.
• Die Konfi­gu­ra­tion ist einfach und gut nachvollziehbar.
• Es reichen Site oder Site Collec­tion Owner Berech­ti­gungen aus, um die Creden­tials zu definieren (Ausnahme: Farm Level Credential).

Nachteile:

• Creden­tials sind nicht im Secure Store Service gespei­chert, sondern in Nintex. Die in Nintex gespei­cherten Creden­tials können nicht für andere Anwen­dungen außer­halb von Nintex wie zum Beispiel BCS oder Excel Services genutzt werden.
• Standard­mäßig darf jeder Workflow Ersteller auf die hinter­legten Creden­tials im jewei­ligen Scope (Site, Site Collec­tion, Farm zugreifen. Es besteht das Risiko, dass das Creden­tial von anderen Workflow Erstel­lern für andere Zwecke verwendet werden.

 

3.      Stored Creden­tials — Secure Store

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

Bei Verwen­dung der Option Secure Store Creden­tial wird auf eine Target Appli­ca­tion ID referen­ziert. Die Target Appli­ca­tion muss im jewei­ligen Secure Store Service existieren.

Die Verwal­tung von Creden­tials im Secure Store Service ist aus Anwen­der­sicht komplexer als in Nintex und setzt einiges an Wissen voraus:

• Der Anwender benötigt im Secure Store spezi­elle Rechte, um eigene Creden­tials (sogenannte Target Appli­ca­tion IDs) im Secure Store anzulegen und zu verwalten. Diese Rechte müssen initial durch den Farm Admin konfi­gu­riert werden. Unabhängig davon ist die Central Adminis­tra­tion von Share­Point auf SSL / https umzustellen, damit die hinter­legten Creden­tials 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 commu­ni­ca­tion. User names, passwords, and any other infor­ma­tion will be sent in clear text. For more infor­ma­tion, contact your administrator.
• Im Secure Store Service sind verschie­dene Target Appli­ca­tion Types möglich. Im Falle von Creden­tials, die in Nintex genutzt werden, ist der Target Appli­ca­tion Type = Indivi­dual ausrei­chend, da Nintex mit der Identität der Weban­wen­dung auf den Secure Store Service zugreift. Dies stellt aber auch ein Risiko dar, da jeder Code, der als Farm Solution bereit­ge­stellt ist, poten­tiell durch Nutzung von RunWi­thE­le­va­ted­Pri­vi­leges auf dieses Creden­tial zugreifen kann.

Vorteile:

• Sofern vorhanden kann eine bestehende und gesicherte Secure Store Service Imple­men­tie­rung genutzt werden – die Creden­tials werden an zentraler Stelle verwaltet.

Nachteile:

• Die Komple­xität bei Nutzung der Nintex Konstanten und des Secure Stores ist nicht zu unter­schätzen – es ist mit Schulungs­auf­wand zu rechnen. Durch die verteile Konfi­gu­ra­tion in Nintex und im Secure Store wird zudem das Trouble­shoo­ting erschwert.
• Creden­tials im Secure Store sind global und können – je nach Berech­ti­gung – in der Farm genutzt werden. Defini­tion von Creden­tials auf Site oder Site Collec­tion Level ist nicht möglich.

 

Zusam­men­fas­sung / Best Practices

1. Wird ein Action Set mit der Option Run as workflow owner verwendet, so sollte der Workflow im Kontext eines Workflow-Anwen­dungs­ac­count veröf­fent­licht werden, nicht mit einem perso­na­li­sierten Account. Bei Verwen­dung eines perso­na­li­sierten Accounts wird der Workflow nicht mehr funktio­nieren, wenn der perso­na­li­sierte Account im Active Direc­tory gelöscht wurde.
2. Bei Verwen­dung von Actions mit dem Creden­tial Pickers sollten die Creden­tials nicht fest in der Workflow Action hinter­legt werden, sondern referen­ziert werden. Ob diese Nintex, oder im Secure Store verwaltet werden, hängt von den unter­neh­mens­spe­zi­fi­schen Voraus­set­zungen, bzw. Richt­li­nien ab. In jedem Fall ist aber sicher­zu­stellen, dass die Zugriffs­rechte auf das Creden­tial nach dem Minimal-Rechte-Prinzip konfi­gu­riert sind, andern­falls besteht das Risiko, dass Creden­tials missbraucht werden.